Contents

Exchange Server 2013

What's new in Exchange 2013
What's discontinued in Exchange 2013
What's new for Outlook Web App in Exchange 2013
What's new for Unified Messaging in Exchange 2013
What's new for transport rules
Release notes for Exchange 2013
Updates for Exchange 2013
Planning and deployment
Exchange Server Deployment Assistant
Active Directory
Access to Active Directory
Exchange 2013 Active Directory schema changes
Disjoint namespace scenarios
Configure the DNS suffix search list for a disjoint namespace
Exchange 2013 system requirements
Exchange 2013 prerequisites
Prepare Active Directory and domains
Deploy a new installation of Exchange 2013
Checklist: Perform a new installation of Exchange 2013
Install Exchange 2013 using the Setup wizard
Install Exchange 2013 using unattended mode
Install the Exchange 2013 Edge Transport role using the Setup wizard
Delegate the installation of an Exchange 2013 server
Upgrade Exchange 2013 to the latest cumulative update or service pack
Upgrade from Exchange 2010 to Exchange 2013
Checklist: Upgrade from Exchange 2010
Upgrade from Exchange 2007 to Exchange 2013
Checklist: Upgrade from Exchange 2007
Deploy multiple forest topologies for Exchange 2013
Deploy Exchange 2013 in a cross-forest topology
Deploy Exchange 2013 in an Exchange resource forest topology
Exchange 2013 post-Installation tasks
Enter your Exchange 2013 product key
Configure mail flow and client access
Verify an Exchange 2013 installation
Install the Exchange 2013 management tools
Exchange 2013 virtualization
Integration with SharePoint and Lync
Configure OAuth authentication with SharePoint 2013 and Lync 2013
Deployment reference
What changes in Active Directory when Exchange 2013 is installed?
Exchange 2013: editions and versions
Exchange Server Supportability Matrix
Exchange 2013 deployment permissions reference
Deployment security checklist
Exchange 2013 sizing and capacity planning
Exchange 2013 storage configuration options
IPv6 support in Exchange 2013
Exchange 2013 language support
Exchange 2013 readiness checks
AD LDS directory exists in default location
Duplicate Microsoft Exchange System Objects container exists in Active Directory
Failover Cluster Command Interface Windows feature not installed
Client Access server role is already installed
Active Directory does not exist or cannot be contacted
The local computer isn't joined to an Active Directory domain
Installation of the first Exchange server in the organization can't be delegated
Installation of the first Exchange server in the organization can't be delegated
Installation of the first Exchange server in the organization can't be delegated
Installation of the first Exchange server in the organization can't be delegated
 Installation of the first Exchange server in the organization can't be delegated
Active Directory functional level isn't Windows Server 2003 or later
Cannot write to the Exchange organization container
Global updates required
The Host record for the local computer cannot be found in the DNS database
Installation on domain controllers is not supported with Active Directory split
permissions
The current account isn't logged into an Active Directory domain
The computer needs to be restarted before Setup can continue
The logged-on user is not a member of the Schema Admins group
UCMA 4.0, Core Runtime not installed
Cannot remove mailbox database
Installing Exchange on a domain controller is not recommended
KB2619234 update not installed
Installation of the first Exchange server in the organization can't be delegated
No Exchange 2010 or Exchange 2007 servers detected
The computer needs to be restarted before Setup can continue
Exchange 2007 servers must be upgraded to Service Pack 3, Update Rollup 10
Exchange 2010 servers must be upgraded to Service Pack 3
Office 2010 Filter Pack not installed
Office 2010 Filter Pack SP1 not installed
Can't install Exchange 2013 in a forest containing Exchange 2000 or Exchange
2003 servers.
An incompatible operating system was found
Exchange 2010 servers must be upgraded to Service Pack 3
ExecutionPolicy GPO is defined
Primary DNS Suffix is missing
The Simple Mail Transport Protocol is currently installed_SMTPSvcInstalled
SMTP Addressing Format Not Supported_SMTPAddressLiteral
The World Wide Web Publishing Service is disabled or
missing_ShouldReRunSetupForW3SVC
This Server is the Source for a Send
Connector_ServerIsSourceForSendConnector
 The local computer is responsible for expanding group
membership_ServerIsGroupExpansionServer
The local computer is responsible for expanding group
membership_ServerIsDynamicGroupExpansionServer
The fully-qualified domain name of the computer matches a recipient
policy_ServerFQDNMatchesSMTPPolicy
Older database files present_SecondSGFilesExist
The schema master is not running Windows Server 2003 Service Pack 1 or
later_SchemaFSMONotWin2003SPn
Cannot find a recipient update service_RUSMissing
Active Directory domain is mixed mode_RootDomainModeMixed
The primary DNS server cannot be contacted_PrimaryDNSTestFailed
Insufficient permissions to run /PrepareDomain_PrepareDomainNotAdmin
Active Directory domain is mixed mode_PrepareDomainModeMixed
The operating system is in debug mode_OSCheckedBuild
The logged-on user is not a member of the local Administrators
group_NotLocalAdmin
Not in schema master site/domain_NotInSchemaMasterSite
Not in schema master site/domain_NotInSchemaMasterDomain
Cannot install Exchange 2007 roles after you prepare Active Directory for
Exchange 2010_NoE12ServerWarning
The Distributed Transaction Coordinator Service must be started before setup
can continue_MSDTCStopped
Messages currently exist in one or more queues_MessagesInQueue
Storage group drive specification is missing_MailboxLogDriveDoesNotExist
Mailbox database drive specification is missing_MailboxEDBDriveDoesNotExist
The Windows Process Activation Service - Process Model component is
required_LonghornWASProcessModelInstalled
IIS 7 component not installed_LonghornIIS7WindowsAuthNotInstalled
IIS 7 .NET Extensibility component is required_LonghornIIS7NetExt
Uninstall Unified Messaging Language Packs_AdditionalUMLangPackExists
Insufficient permissions to prepare Active Directory_ADUpdateRequired
Hub Transport role not detected in local site_BridgeheadRoleNotPresentInSite
Insufficient permissions to remove all server
roles_CannotUninstallDelegatedServer
 Client Access role not detected in local site_ClientAccessRoleNotPresentInSite
Only the Mailbox role can be installed on a cluster
server_ClusSvcInstalledRoleBlock
Setup cannot install Exchange to a read-only domain controller_ComputerRODC
Domain Controller Override is set in the Registry_ConfigDCHostNameMismatch
Insufficient permissions to prepare Active
Directory_DomainPrepWithoutADUpdate
The local computer is already running Exchange
Server_ExchangeAlreadyInstalled
Older database files present_FirstSGFilesExist
One or more Active Directory Connector servers were found_ADCFound
The schema master is not running Windows Server 2003 Service Pack 1 or
later_DomainControllerIsOutOfSite
Domain preparation required_DomainPrepRequired
The COM+ Event System Service must be started before setup can
continue_EventSystemStopped
IIS is in 32-bit compatibility mode_IIS32BitMode
Access control list (ACL) inheritance is blocked_InhBlockPublicFolderTree
Setup failure occurred while installing a server role_InstallWatermark
Setup failure occurred while uninstalling a server
role_InterruptedUninstallNotContinued
Cannot determine the name of the Active Directory site_InvalidADSite
The local computer is a domain controller of a child
domain_LocalComputerIsDCInChildDomain
Active Directory domain is mixed mode_LocalDomainModeMixed
The local domain needs to be updated_LocalDomainPrep
IIS 6 Compatibility components not installed_LonghornIIS6MetabaseNotInstalled
IIS 6 Compatibility components not
installed_LonghornIIS6MgmtConsoleNotInstalled
IIS 7 component not installed_LonghornIIS7BasicAuthNotInstalled
IIS 7 component not installed_LonghornIIS7DigestAuthNotInstalled
IIS 7 component not
installed_LonghornIIS7HttpCompressionDynamicNotInstalled
IIS 7 component not installed_LonghornIIS7HttpCompressionStaticNotInstalled
The World Wide Web Publishing Service is disabled or
 missing_W3SVCDisabledOrNotInstalled
OAB server has been deleted_OffLineABServerDeleted
Network ports for clients and mail flow in Exchange 2013
Overview of Exchange 2013 services
Basic concepts in Exchange Management Shell
Cmdlets
Identity
Import and export files in the Exchange Management Shell
Modifying multivalued properties
WhatIf, Confirm, and ValidateOnly switches
Working with command output
Cmdlet extension agents
Manage cmdlet extension agents
Exchange Management Shell quick reference for Exchange 2013
Filterable properties for the -ContentFilter parameter
Multi-tenancy in Exchange 2013
Update your Exchange organization when Daylight Saving Time or the time zone
changes
Permissions
Understanding Role Based Access Control
Understanding management role groups
Understanding management role assignment policies
Understanding management roles
Understanding management role scopes
Understanding management role scope filters
Understanding exclusive scopes
Understanding management role assignments
Built-in role groups
Organization Management
View-only Organization Management
Recipient Management
UM Management
Help Desk
 Hygiene Management
Compliance Management
Records Management
Discovery Management
Public Folder Management
Server Management
Delegated Setup
Built-in management roles
Active Directory Permissions role
Address Lists role
ApplicationImpersonation role
ArchiveApplication role
Audit Logs role
Cmdlet Extension Agents role
Data Loss Prevention role
Database Availability Groups role
Database Copies role
Databases role
Disaster Recovery role
Distribution Groups role
Edge Subscriptions role
E-Mail Address Policies role
Exchange Connectors role
Exchange Server Certificates role
Exchange Servers role
Exchange Virtual Directories role
Federated Sharing role
Information Rights Management role
Journaling role
Legal Hold role
LegalHoldApplication role
Mail Enabled Public Folders role
Mail Recipient Creation role
Mail Recipients role
Mail Tips role
Mailbox Import Export role
Mailbox Search role
MailboxSearchApplication role
Message Tracking role
Migration role
Monitoring role
Move Mailboxes role
My Custom Apps role
My Marketplace Apps role
MyAddressInformation role
MyBaseOptions role
MyContactInformation role
MyDiagnostics role
MyDisplayName role
MyDistributionGroupMembership role
MyDistributionGroups role
MyMobileInformation role
MyName role
MyPersonalInformation role
MyProfileInformation role
My ReadWriteMailbox Apps role
MyRetentionPolicies role
MyTeamMailboxes role
MyTextMessaging role
MyVoiceMail role
OfficeExtensionApplication role
Org Custom Apps role
Org Marketplace Apps role
Organization Client Access role
 Organization Configuration role
Organization Transport Settings role
POP3 and IMAP4 Protocols role
Public Folders role
Receive Connectors role
Recipient Policies role
Remote and Accepted Domains role
Reset Password role
Retention Management role
Role Management role
Security Group Creation and Membership role
Send Connectors role
Support Diagnostics role
Team Mailboxes role
TeamMailboxLifecycleApplication role
Transport Agents role
Transport Hygiene role
Transport Queues role
Transport Rules role
UM Mailboxes role
UM Prompts role
Unified Messaging role
Unscoped Role Management role
User Options role
UserApplication role
View-Only Audit Logs role
View-Only Configuration role
View-Only Recipients role
WorkloadManagement role
Understanding multiple-forest permissions
Understanding split permissions
Understanding permissions coexistence with Exchange 2007 and Exchange 2010
Manage role groups
Manage role group members
Manage linked role groups
Manage role assignment policies
Change the assignment policy on a mailbox
Create linked role groups that mirror built-in role groups
View effective permissions
Feature permissions
Role management permissions
Messaging policy and compliance permissions
Anti-spam and anti-malware permissions
Mail flow permissions
Recipients Permissions
Email address and address book permissions
Sharing and collaboration permissions
Clients and mobile devices permissions
Unified Messaging permissions
High availability and site resilience permissions
Exchange and Shell infrastructure permissions
Server health and performance permissions
Advanced permissions
Management roles and role entries
Create a role
View a role
Remove a role
Add a role entry to a role
Change a role entry
View role entries
Remove a role entry from a role
Create an unscoped role
Change a role entry on an unscoped top-level role
Add a role entry to an unscoped top-level role
 Management role scopes
Create a regular or exclusive scope
Change a role scope
View role scopes
Remove a role scope
Control automatic mailbox distribution using database scopes
Management role assignments
Add a role to a user or USG
Change a role assignment
View role assignments
Remove a role from a user or USG
Delegate role assignments
Managing split permissions
Configure Exchange 2013 for split permissions
Configure Exchange 2013 for shared permissions
Messaging policy and compliance
In-Place Archiving in Exchange 2013
Manage In-Place Archives in Exchange 2013
Modify archive policies
Configure archive quotas for an In-Place Archive in Exchange 2013
Archive Lync conversations and meeting content to Exchange
Using OAuth authentication to support Archiving in an Exchange hybrid
deployment
In-Place Hold and Litigation Hold
Create or remove an In-Place Hold
Place a mailbox on Litigation Hold
Place all mailboxes on hold
Preserve Bcc and expanded distribution group recipients for eDiscovery
In-Place eDiscovery
Assign eDiscovery permissions in Exchange
Create an In-Place eDiscovery search
Copy eDiscovery search results to a discovery mailbox
Export eDiscovery search results to a PST file
 Message properties and search operators for In-Place eDiscovery
Create a discovery mailbox
Start or stop an In-Place eDiscovery search
Modify an In-Place eDiscovery search
Create a custom management scope for In-Place eDiscovery searches
Remove an In-Place eDiscovery search
Search for and delete messages in Exchange 2013
Reduce the size of a discovery mailbox in Exchange
Delete and re-create the default discovery mailbox in Exchange
Re-create the Discovery system mailbox
Using OAuth authentication to support eDiscovery in an Exchange hybrid
deployment
Configure Exchange for SharePoint eDiscovery Center
Unsearchable items in Exchange eDiscovery
Messaging records management
Messaging records management terminology in Exchange 2013
Retention tags and retention policies
Default Retention Policy
Default folders that support Retention Policy Tags
How retention age is calculated
Checklist: Deploying retention policies
Messaging Records Management Procedures
Create a Retention Policy
Add retention tags to or remove retention tags from a retention policy
Apply a retention policy to mailboxes
Configure the Managed Folder Assistant
Place a mailbox on retention hold
Export and import retention tags
Configure Outlook client blocking
Migrate from managed folders
Turn off or suspend messaging records management
Monitoring messaging records management
View performance counters for messaging records management
 Performance counters for messaging records management
Messaging records management errors and events
Journaling
Manage journaling
Disable or enable journaling of voice mail and missed call notifications
Transport rules
Transport rule conditions and exceptions (predicates)
Transport rule actions
Best practices for configuring transport rules
Use transport rules to inspect message attachments
Common attachment blocking scenarios for transport rules
Organization-wide disclaimers, signatures, footers, or headers
Transport rule procedures
Manage transport rules
Test a transport rule
Use transport rules to route email based on a list of words, phrases, or patterns
Register Filter Pack IFilters with Exchange 2013
Manage message approval
Common message approval scenarios
Manage and troubleshoot message approval
Data loss prevention
How DLP rules are applied to evaluate messages
Integrating sensitive information rules with transport rules
What the sensitive information types look for
DLP policy templates
DLP policy templates supplied in Exchange
Policy templates from Microsoft partners
DLP procedures
Manage DLP policies
Create a DLP policy from a template
Create a custom DLP policy
Import a custom DLP policy template from a file
 View DLP policy detection reports
Create incident reports for DLP policy detections
Define your own DLP templates and information types
Developing DLP policy template files
Developing sensitive information rule packages
Matching methods and techniques for rule packages
Customize the built-in DLP sensitive information types
Export DLP sensitive information types from Exchange
Policy Tips
Manage policy tips
Document Fingerprinting
Protect form data with document fingerprinting
Information Rights Management
Transport protection rules
Outlook protection rules
Transport decryption
Journal report decryption
Information Rights Management in Outlook Web App
Information Rights Management in Exchange ActiveSync
Information Rights Management logging
Information Rights Management procedures
Enable or Disable IRM for Internal Messages
Create a Transport Protection Rule
Create an Outlook Protection Rule
Remove an Outlook Protection Rule
Add the Federation Mailbox to the AD RMS Super Users Group
Enable or Disable Transport Decryption
Configure IRM for Exchange Search and In-Place eDiscovery
Enable or Disable Journal Report Decryption
Enable or Disable Information Rights Management on Client Access Servers
Enable or Disable Information Rights Management Logging
S/MIME for message signing and encryption
Configure S/MIME settings for Outlook Web App
 Configure S/MIME settings for Outlook Web App
Set up a virtual certificate collection to validate S/MIME
Send and receive S/MIME signed and encrypted email
Mailbox audit logging
Mailbox audit logging procedures
Enable or disable mailbox audit logging for a mailbox
Bypass a user account from mailbox audit logging
Search the mailbox audit log for a mailbox
Create a mailbox audit log search
Administrator audit logging
Administrator audit log structure
Manage administrator audit logging
Exchange auditing reports
Export mailbox audit logs
Run a non-owner mailbox access report
Run a per-mailbox litigation hold report
Search the role group changes or administrator audit logs
View the administrator audit log
Anti-spam and anti-malware protection
Anti-spam protection
Benefits of anti-spam features in Exchange Online Protection over Exchange
Server 2013
Enable anti-spam functionality on Mailbox servers
Sender filtering
Manage sender filtering
Sender ID
Manage Sender ID
Content filtering
Manage content filtering
Safelist Aggregation
Manage safelist aggregation
Configure Content Filtering to Use Safe Domain Data
Spam Confidence Level Threshold
 Configure Anti-Spam Settings on Mailboxes
Sender reputation and the Protocol Analysis agent
Manage sender reputation
Connection Filtering on Edge Transport Servers
Manage Connection Filtering on Edge Transport Servers
Recipient filtering on Edge Transport servers
Manage recipient filtering on Edge Transport servers
Attachment filtering on Edge Transport servers
Manage attachment filtering on Edge Transport servers
Spam quarantine
Configure a spam quarantine mailbox
Configure Outlook to show the original sender in the quarantine mailbox
Release quarantined messages from the spam quarantine mailbox
Anti-spam stamps
View anti-spam stamps in Outlook
Anti-malware protection
Anti-malware FAQ
Download engine and definition updates
Configure anti-malware policies
Rescan messages already malware scanned by the hosted filtering service
Disable or bypass anti-malware scanning
Anti-Virus Software in the Operating System on Exchange Servers
Mail flow
Mail routing
Planning to use Active Directory sites for routing mail
Configure Exchange mail routing settings in Active Directory
Route mail between Active Directory sites
Recipient resolution
DNS query failure sensitivity
Use Telnet to test SMTP communication
Configure the external postmaster address
Connectors
 Send connectors
Create a Send connector for email sent to the Internet
Create a Send connector to route outbound email through a smart host
Create a Send connector to send email to a partner, with Transport Layer
Security (TLS) applied
Configure a cross-forest Send connector
Receive connectors
Receive connector permissions
Receive connector authentication mechanisms
Receive connector procedures
Create a Receive connector to receive email from the Internet
Create a secure Receive connector to receive email from a partner
Create a Receive connector to receive email from a system not running
Exchange
Create a Receive connector to receive messages from an internal Exchange
server
Modify the SMTP banner on a Receive connector
Foreign connectors
Create a Foreign connector to deliver messages to a non-SMTP fax gateway
Delivery agents and Delivery Agent connectors
Header firewall
Domains
Accepted domains
Configure an accepted domain within your Exchange organization as
authoritative
Configure an accepted domain for an independent business unit
Configure an accepted domain for a business unit with mailboxes outside your
Exchange organization
Configure Exchange to accept mail for multiple authoritative domains
Remote domains
Manage remote domains
Configure remote domain out of office replies
Configure remote domain automatic replies
Configure remote domain message reporting
 Supported character sets for remote domains
Transport agents
Enable support for legacy transport agents
Manage transport agents
View transport agents in the transport pipeline
Transport high availability
Shadow redundancy
Safety Net
Transport logs
Anti-spam agent logging
Configure anti-spam agent logging
Connectivity logging
Configure connectivity logging
Pipeline tracing
Configure pipeline tracing
Protocol logging
Configure protocol logging
Configure routing table logging
Message tracking
Configure message tracking
Search message tracking logs
Delivery reports for administrators
Track messages with delivery reports
Content conversion
Configure content transfer encoding
Message encoding options
TNEF conversion options
Content conversion tracing
DSNs and NDRs in Exchange 2013
Manage DSN messages
DSN message identity
DSN message text
 Supported languages for system messages
Message size limits
Message throttling
Back pressure
Queues
Manage queues
Use the Exchange Management Shell to manage queues
Configure Get-QueueDigest
Queue filters
Manage messages in queues
Queue Viewer
Connect to a server in Queue Viewer
Set Queue Viewer options
View queued message properties in Queue Viewer
Export lists from Queue Viewer
Message filters
Export messages from queues
Message retry, resubmit, and expiration intervals
Configure message retry, resubmit, and expiration intervals
Priority queuing
Enable and configure priority queuing
Change the location of the queue database
Pickup directory and Replay directory
Configure the Pickup directory and the Replay directory
TLS functionality and related terminology
Scenario: Configure Exchange to support WAN Optimization Controllers
Disable TLS between Active Directory sites
Recipients
Create user mailboxes
Manage user mailboxes
Add or remove email addresses for a mailbox
Configure email forwarding for a mailbox
 Configure message delivery restrictions for a mailbox
Configure message size limits for a mailbox
Configure storage quotas for a mailbox
Convert a Mailbox
Enable or disable Exchange ActiveSync for a mailbox
Enable or disable MAPI for a mailbox
Enable or disable Outlook Web App for a mailbox
Enable or disable single item recovery for a mailbox
Manage linked mailboxes
Create and manage distribution groups
Create a distribution group naming policy
Override the distribution group naming policy
Manage mail-enabled security groups
Manage dynamic distribution groups
View members of a dynamic distribution group
Manage mail contacts
Enable or disable email for a mail contact
Manage mail users
Enable or disable email for a mail user
Create and manage room mailboxes
Manage equipment mailboxes
Disconnected mailboxes
Disable or delete a mailbox
Connect a disabled mailbox
Connect or restore a deleted mailbox
Restore a soft-deleted mailbox
Manage mailbox restore requests
Permanently delete a mailbox
Custom attributes
Manage permissions for recipients
Unsupported characters for Exchange 2013 object names
Automatic mailbox distribution
Collaboration
Site mailboxes
Manage site mailbox provisioning policies
Public folders
FAQ: Public folders
Limits for public folders
Considerations when deploying public folders
Accessing public folders with Outlook 2016 for Mac
Migrate your public folders to Office 365 Groups
Public folder procedures
Set up public folders in a new organization
Configure legacy on-premises public folders for a hybrid deployment
Configure Exchange 2013 public folders for a hybrid deployment
Configure Exchange Online public folders for a hybrid deployment
Configure legacy public folders where user mailboxes are on Exchange 2013
servers
Use batch migration to migrate public folders to Exchange 2013 from previous
versions
Use batch migration to migrate legacy public folders to Office 365 and Exchange
Online
Use batch migration to migrate Exchange 2013 public folders to Exchange Online
Roll back a public folder migration from Exchange 2013 to Exchange Online
Use batch migration to migrate Exchange 2010 public folders to Office 365
Groups
Use batch migration to migrate Exchange 2013 public folders to Office 365
Groups
Create a public folder mailbox
Create a public folder
Mail-enable or mail-disable a public folder
Update the public folder hierarchy
Remove a public folder
Use favorite public folders in Outlook on the web
Move a public folder mailbox to a different mailbox database
Move a public folder to a different public folder mailbox
 Restore public folders and public folder mailboxes from failed moves
View statistics for public folders and public folder items
Shared mailboxes
Create a shared mailbox
Email addresses and address books
Address book policies
Scenario: Deploying address book policies
Address book policy procedures
Install and configure the Address Book Policy Routing agent
Create an address book policy
Assign an address book policy to mail users
Change the settings of an address book policy
Remove an address book policy
Details templates
Customize details templates
Restore a details template to the default configuration
Email address policies
Email address policy procedures
Create an Email Address Policy
Create an email address policy by using recipient filters
Edit an email address policy
Remove an email address policy
Offline address books
Offline address book procedures
Create an offline address book
Add an address list to or remove an address list from an offline address book
Change the default offline address book
Provision recipients for offline address book downloads
Remove an offline address book
Update an offline address book
Create an offline address book virtual directory
Change the offline address book generation schedule
 Configure offline address book distribution properties
Address lists
Address list procedures
Create an address list
Update an address list
Create an address list by using recipient filters
Move an address list
Remove an address list
Create a global address list
Configure global address list properties
Remove a global address list
Update a global address list
Hierarchical address books
Enable or disable hierarchical address books
Sharing
Federation
Trusted root certification authorities for federation trusts
Federation procedures
Configure federated sharing
Configure a federation trust
Manage a federation trust
Remove a federation trust
Renew the federation certificate
Disable or Re-enable federated sharing for your Exchange organization
Configuring federated sharing between Exchange organizations
Configure OAuth authentication between Exchange and Exchange Online
organizations
Organization relationships
Create an organization relationship
Modify an organization relationship
Remove an organization relationship
Sharing policies
Create a sharing policy
 Apply a sharing policy to mailboxes
Modify, disable, or remove a sharing policy
Enable Internet calendar publishing
Disable Internet calendar publishing
Clients and mobile
Outlook Anywhere
Test Outlook Anywhere connectivity
MAPI over HTTP
Exchange ActiveSync
Direct Push
Mobile device mailbox policies
Add or remove users from a mobile mailbox policy
Create or modify a mobile device mailbox policy
Supported mobile device mailbox policies for Windows Phones and devices
Mobile devices
Remote device wipe
View mobile device information for users
Mobile phone and tablet features
Perform a remote wipe on a mobile phone
Configure mobile phones to access email
POP3 and IMAP4
Start and stop the POP3 services
Start and stop the IMAP4 services
Enable POP3
Enable IMAP4
Enable or disable POP3 access for a user
Enable or disable IMAP4 access for a user
Set connection limits for POP3
Set connection limits for IMAP4
Set connection time-out limits for POP3
Set connection time-out limits for IMAP4
Configure calendar options for POP3
 Configure calendar options for IMAP4
Configure POP3 and IMAP4 message retrieval format options
Configure IP addresses and ports for POP3 and IMAP4 access
Allow POP3, IMAP4, and SMTP server settings to be viewed by end users in
Outlook Web App
Protocol logging for POP3 and IMAP4
Configure protocol logging for POP3 and IMAP4
Outlook for iOS and Android
Client protocol management
Virtual directory management
Exchange ActiveSync virtual directory management tasks
Default settings for Exchange virtual directories
Outlook Web App
Outlook Web App mailbox policies
Outlook Web App mailbox policy procedures
Create an Outlook Web App mailbox policy
Apply or remove an Outlook Web App mailbox policy on a mailbox
Remove an Outlook Web App mailbox policy from Exchange
View or configure Outlook Web App mailbox policy properties
Integrate Outlook Web App with Lync Server
View or configure Outlook Web App virtual directories
Simplify the Outlook Web App URL
Create a theme for Outlook Web App
Customize the Outlook Web App sign-In, language selection, and error pages
Configuring push notifications proxying for OWA for Devices
Using AD FS claims-based authentication with Outlook Web App and EAC
Using Outlook Web App Web parts
MailTips
Enable or disable MailTips
Configure the large audience size for your organization
Configure custom MailTips for recipients
MailTips over organization relationships
Manage MailTips for organization relationships
 Group metrics and MailTips
Configure group metrics
Add-ins for Outlook
Install or remove add-ins for Outlook for your organization
Manage user access to add-ins for Outlook
Specify the administrators and users who can install and manage add-ins for
Outlook
Configuring SSL offloading in Exchange 2013
Unified Messaging
New voice mail features
Voice architecture changes
IPv6 support in Unified Messaging
Voice mail preview enhancements
Unified Messaging cmdlet updates
Planning for Unified Messaging
Deploying voice mail and UM
Deploy Exchange 2013 UM
Checklist: Deploy Exchange 2013 UM
Upgrade Exchange 2010 UM to Exchange 2013 UM
Checklist: Upgrade Exchange 2010 UM to Exchange 2013 UM
Upgrade Exchange 2007 UM to Exchange 2013 UM
Checklist: Upgrade Exchange 2007 UM to Exchange 2013 UM
Deploying Exchange 2013 UM and Lync Server overview
Configure UM to work with Lync Server
Checklist: Integrate Exchange 2013 UM with Lync Server
Coexistence with Office Communications Server 2007 R2 and Lync Server
Deploying certificates for UM
Deploying certificates for UM procedures
Create certificates for UM
Import or export certificates for UM
Assign a certificate to the UM and UM Call Router services
UM languages, prompts, and greetings
Voice mail greetings, announcements, menus, and prompts
 UM languages, prompts, and greetings procedures
Install a UM language pack
Set the default language on a dial plan
Select the language for an auto attendant
Remove a UM language pack
Import and export custom greetings, announcements, menus, and prompts
Import custom prompts from Exchange 2007 to Exchange 2013
Enable custom prompt recording using the telephone user interface
Telephone system integration with UM
Telephony concepts and components
PBX and IP PBX configurations
Connect UM to your telephone system
Telephony advisor for Exchange 2013
Configuration notes for supported VoIP gateways, IP PBXs, and PBXs
Connect a VoIP gateway, IP PBX, or session border controller to UM
Connect UM to a supported VoIP gateway
Connect a VoIP gateway to communicate with a PBX
Configuration notes for supported session border controllers
Connect your voice mail system to your telephone network
UM dial plans
Audio codecs
Secondary dial plans
UM dial plan procedures
Create a UM dial plan
Manage a UM dial plan
Add Mailbox and Client Access servers to a SIP URI dial plan
Remove Mailbox and Client Access servers from a SIP URI dial plan
Change the audio codec
Configure the maximum call duration
Configure the maximum recording duration
Configure the recording idle time-out value
Configure the VoIP security setting
 Configure a dial plan for users who have similar names
Delete a UM dial plan
UM IP gateways
UM IP gateway procedures
Create a UM IP gateway
Manage a UM IP gateway
Enable a UM IP gateway
Disable a UM IP gateway
Configure a fully qualified domain name
Configure the IP address
Configure the listening port
Delete a UM IP gateway
UM hunt groups
UM hunt group procedures
Create a UM hunt group
View a UM hunt group
Delete a UM hunt group
UM services
UM protocols, ports, and services
UM services procedures
Manage UM settings on a Mailbox server
Manage UM settings on a Client Access server
Allow or prevent call answering on a Mailbox server
Allow or prevent call answering on a Client Access server
Configure the startup mode on a Mailbox server
Configure the startup mode on a Client Access server
Configure the number of incoming calls on a Mailbox server
Start the Microsoft Exchange Unified Messaging service
Stop the Microsoft Exchange Unified Messaging service
Start the Microsoft Exchange Unified Messaging Call Router service
Stop the Microsoft Exchange Unified Messaging Call Router service
Set the TCP listening port on a Client Access server
 Set the TLS listening port on a Client Access server
Automatically answer and route incoming calls
DTMF interface
UM auto attendant procedures
Set up a UM auto attendant
Create a UM auto attendant
Add an auto attendant extension number
Configure business hours
Create a holiday schedule
Enter a business name
Set a business location
Configure the time zone
Enable a customized business hours greeting
Enable a customized business hours menu prompt
Enable a customized non-business hours greeting
Enable a customized non-business hours menu prompt
Enable an informational announcement
Create menu navigation
Create business hours navigation menus
Create non-business hours navigation menus
Manage a UM auto attendant
Configure a DTMF fallback auto attendant
Enable a UM auto attendant
Disable a UM auto attendant
Delete a UM auto attendant
Enable or disable automatic speech recognition
Enable or prevent transferring calls from an auto attendant
Enable or disable sending voice messages to users
Enable or disable directory lookups
Configure the group of users that can be contacted
Configure an auto attendant for users who have similar names
Set up voice mail for users
UM mailbox policies
 UM mailbox policies
UM mailbox policy procedures
Create a UM mailbox policy
Manage a UM mailbox policy
Delete a UM mailbox policy
Voice mail for users
Voice mail-enabled user procedures
Enable a user for voice mail
Include text with the email message sent when a user Is enabled for voice mail
Manage voice mail settings for a user
Assign a UM mailbox policy
Change the UM dial plan
Enable calls from users who aren't UM-enabled
Disable calls from users who aren't UM-enabled
Allow callers without a caller ID to leave a voice message
Include text with the email message sent when a voice message Is received
Prevent callers without a caller ID from leaving a voice message
Disable voice mail for a user
Change a SIP address
Change an extension number
Add a SIP address
Remove a SIP address
Add an extension number
Remove an extension number
Change an E.164 number
Add an E.164 number
Remove an E.164 number
Set up client voice mail features
Setting up Outlook Voice Access
Outlook Voice Access commands
Navigating menus with Outlook Voice Access
Play on Phone
Outlook Voice Access procedures
 Enable or disable Outlook Voice Access for users
Configure an Outlook Voice Access number
Disable selected features for Outlook Voice Access users
Set mailbox features for Outlook Voice Access users
Set mailbox features for an Outlook Voice Access user
Enable or disable automatic speech recognition for an Outlook Voice Access
user
Enable an informational announcement for Outlook Voice Access users
Enable a customized greeting for Outlook Voice Access users
Enable or disable Play on Phone for Outlook Voice Access users
Enable or disable sending voice messages from Outlook Voice Access
Enable or prevent transferring calls from Outlook Voice Access
Configure the group of users that Outlook Voice Access users can contact
Configure the primary way for Outlook Voice Access users to search
Configure the secondary way for Outlook Voice Access users to search
Configure the number of sign-in failures before Outlook Voice Access users are
disconnected
Configure the number of input failures before Outlook Voice Access users are
disconnected
Configure the limit on personal greetings for Outlook Voice Access users
Allow voice mail users to forward calls
Forwarding calls procedures
Allow or prevent a user from creating call answering rules
Allow or prevent users in the same UM mailbox policy from creating call
answering rules
Create a call answering rule
View and manage a call answering rule
Enable or disable a call answering rule for a user
Remove a call answering rule for a user
Allow users to make calls
Dial codes, number prefixes, and number formats
Allowing users to make calls procedures
Enable outgoing calls on UM IP gateways
 Disable outgoing calls on UM IP gateways
Configure dial codes
Create dialing rules for users
Authorize calls using dialing rules
Allow users to see a voice mail transcript
Voice Mail Preview advisor
Voice Mail Preview procedures
Configure Voice Mail Preview partner services for users
Enable Voice Mail Preview for users
Disable Voice Mail Preview for users
Enable voice mail users to receive faxes
Fax advisor for Exchange UM
Setting up incoming faxing
Faxing procedures
Protect voice mail
Protected Voice Mail procedures
Configure Protected Voice Mail from authenticated callers
Configure Protected Voice Mail from unauthenticated callers
Enable or disable multimedia playback of protected voice messages
Specify the text to display for email clients that don't support Windows Rights
Management
Allow Message Waiting Indicator
Allow Message Waiting Indicator procedures
Allow Message Waiting Indicator (MWI) on a UM IP gateway
Prevent Message Waiting Indicator (MWI) on a UM IP gateway
Enable Message Waiting Indicator (MWI) for users
Disable Message Waiting Indicator (MWI) for users
Enable missed call notifications for a user
Disable missed call notifications for a user
Set Outlook Voice Access PIN security
PIN security procedures
Set Outlook Voice Access PIN policies
Reset a voice mail PIN
 Retrieve voice mail PIN information
Include text with the email message sent when a PIN Is reset
Set the minimum PIN length for voice mail
Set the PIN lifetime for voice mail
Set the number of previous voice mail PINs to recycle
Disable common PIN patterns for voice mail
Enable common PIN patterns for voice mail
Set the number of sign-in failures before a voice mail PIN is reset
Set the number of sign-in failures before a voice mail user Is locked out
Enable PIN-less sign-Ins for voice mail
Run reports for voice mail calls
UM reports procedures
Review the voice mail calls in your organization
Review the voice mail calls for a user
Investigate the audio quality of voice calls in your organization
Investigate the audio quality of voice calls for a user
Interpret voice mail call records
Test and troubleshoot voice mail
Testing and troubleshooting with the UM Troubleshooting Tool
Learn about the Exchange UM Troubleshooting Tool
Run the Exchange UM Troubleshooting Tool on Windows 7 or Windows 8
Set the credentials to use with the Exchange UM Troubleshooting Tool
Install the Exchange UM Troubleshooting Tool
Testing and troubleshooting with the Test-UMConnectivity cmdlet
Test UM operation
Test UM connectivity to VoIP gateways and PBXs
UM and voice mail terminology
Mailbox and Client Access servers
Mailbox server
Managed Store
Managed Store Limits
Manage mailbox databases in Exchange 2013
 Configure circular logging for a mailbox database
Understanding Exchange 2013 page zeroing
Exchange Search
File formats indexed by Exchange Search
Message properties indexed by Exchange Search
Exchange Search procedures
Disable or enable Exchange Search
Diagnose Exchange Search issues
Reseed the search catalog
Mailbox moves in Exchange 2013
Manage on-premises moves
Move the Exchange 2010 system mailbox to Exchange 2013
Prepare mailboxes for cross-forest move requests
Prepare mailboxes for cross-forest moves using the Prepare-MoveRequest.ps1
script in the Shell
Prepare mailboxes for cross-forest moves using sample code
Enable the MRS Proxy endpoint for remote moves
CSV files for mailbox migration
Mailbox import and export requests
Recreating arbitration mailboxes
Recoverable Items folder
Clean up the Recoverable Items folder
Configure Deleted Item retention and Recoverable Items quotas
Recover deleted messages in a user's mailbox
Get Recoverable Items folder statistics
Client Access server
Exchange Remote Connectivity Analyzer
Help Identify My Issue with Sending/Receiving Email on a Mobile Device
(Automatic Checks)
Help Identify My Issue with Sending/Receiving Email in Office Outlook
(Automatic Checks)
Azure: Help Identify My issue with Automatic Checks - DNS Records
Help Identify My Issues with Automatic Checks - 3rd Party Tools
 Help Identify My Issue with Automatic Checks - Active Directory
Help Idenfity My Issue with Automatic Checks - Adding Domains
Help Identify My Issue with Automatic Checks - SSO
Help Identify My Issue with Automatic Checks - Quota
Help Identify My Issue with Automatic Checks - Deploying Office
Help Identify My Issue with Automatic Checks - Migration
Help Identify My Issue with Automatic Checks - Directory Synchronization
Exchange 2013 Client Access server configuration
Autodiscover service
Load balancing
Configuring Kerberos authentication for load-balanced Client Access servers
Using the RollAlternateserviceAccountCredential.ps1 Script in the Shell
Troubleshooting the RollAlternateServiceAccountCredential.ps1 Script
Digital certificates and SSL
Create a digital certificate request
Exchange 2013 certificate management UI
Configure client-specific message size limits
Availability service in Exchange 2013
Configure the Availability service for cross-forest topologies
Edge Transport servers
Edge Subscriptions
EdgeSync replication data
Edge Subscription credentials
Manage Edge Subscriptions
Modify AD LDS configuration
Manually configure Edge Transport server mail flow
Configure Internet mail flow through a subscribed Edge Transport server
Configure Internet mail flow through an Edge Transport server without using
EdgeSync
Edge Transport server planning
Edge Transport server cloned configuration
Configure Edge Transport server using cloned configuration
Use an Exchange 2010 or 2007 Edge Transport server in Exchange 2013
 Address rewriting on Edge Transport servers
Manage address rewriting on Edge Transport servers
Import address rewrite entries on Edge Transport servers
High availability and site resilience
Changes to high availability and site resilience over previous versions
Database availability groups (DAGs)
Active Manager
Datacenter Activation Coordination mode
Mailbox database copies
AutoReseed
Planning for high availability and site resilience
Deploying high availability and site resilience
Managing high availability and site resilience
Managing database availability groups
Create a database availability group
Pre-stage the cluster name object for a database availability group
Configure database availability group properties
Manage database availability group membership
Create a database availability group network
Configure database availability group network properties
Configure AutoReseed for a database availability group
Remove a database availability group
Using a Microsoft Azure VM as a DAG witness server
Managing mailbox database copies
Add a mailbox database copy
Configure mailbox database copy properties
Move the mailbox database path for a mailbox database copy
Configure activation policy for a mailbox database copy
Update a mailbox database copy
Suspend or resume a mailbox database copy
Activate a mailbox database copy
Activate a lagged mailbox database copy
 Remove a mailbox database copy
Monitoring database availability groups
Switchovers and Failovers
Datacenter Switchovers
Perform a Server Switchover
Backup, restore, and disaster recovery
Using Windows Server Backup to back up and restore Exchange data
Use Windows Server Backup to back up Exchange
Use Windows Server Backup to restore a backup of Exchange
Recover an Exchange Server
Recover a database availability group member server
Recovery databases
Create a recovery database
Restore data using a recovery database
Database portability
Move a mailbox database using database portability
Dial tone portability
Perform a dial tone recovery
Managed Availability
Manage health sets and server health
Configure managed availability overrides
Exchange admin center in Exchange 2013
FAQ: Exchange admin center
Turn off access to the Exchange admin center
Find the internal and external URLs for the Exchange admin center
Keyboard shortcuts in the Exchange admin center
Server health and performance
Exchange Server 2013 Performance Recommendations
Exchange 2013 Sizing and Configuration Recommendations
Exchange 2013 Performance Counters
IIS Logs and Log Parser Studio Reports
Exchange workload management
 Change user throttling settings for specific users
Change user throttling settings for all users in your organization
Exchange Server 2013 Management Pack Guide
Exchange Server 2013 Management Pack Health Sets
Exchange Server 2013 Technical Articles
About Exchange documentation
Accessibility for people with disabilities
Third-party copyright notices
 Exchange Server 2013
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Welcome to Microsoft Exchange Server 2013! We know you're eager to get started, but there are a few things you
should be aware of before you start working with Exchange 2013 and using this content.
If you want a quick overview of what's new in Exchange 2013, check out What's new in Exchange 2013.
If you want to learn more about Exchange 2013, check out the Exchange Server 2013 TechCenter.
If you need more help or want to share ideas, the Exchange Server forums are a great place to start.
To get started with Exchange 2013, head for Planning and deployment. It lays out the recommended
sequence for preparing for and then installing Exchange 2013 and includes the following important topics:
Exchange 2013 system requirements
Exchange 2013 prerequisites
Prepare Active Directory and domains
Install Exchange 2013 using the Setup wizard
Install Exchange 2013 using unattended mode
Exchange 2013 post-Installation tasks

TIP
Have you heard about the Exchange Server Deployment Assistant? It's a free online tool that helps you
quickly deploy Exchange 2013 in your organization by asking you a few questions and creating a customized
deployment checklist just for you. If you want to learn more about it, go to Exchange Server Deployment
Assistant.

IMPORTANT
Make sure you read Release notes for Exchange 2013 before you begin your deployment. The release notes
contain important information about issues you might run into during and after your deployment.

For information on how to download Exchange 2013, see Updates for Exchange 2013.

Exchange 2013 Help

The Help content for Exchange 2013 consists of the following top-level categories:
What's new in Exchange 2013
Planning and deployment
Permissions
Messaging policy and compliance
 Anti-spam and anti-malware protection
Mail flow
Recipients
Collaboration
Email addresses and address books
Sharing
Clients and mobile
Unified Messaging
Mailbox and Client Access servers
Edge Transport servers
High availability and site resilience
Using PowerShell with Exchange 2013 (Exchange Management Shell)
Exchange admin center in Exchange 2013
Server health and performance
About Exchange documentation

NOTE
Check out our other Exchange content:
Exchange Online
Exchange Server Hybrid Deployments
Exchange Online Protection

Tell us what you think

If you have comments or questions about our topics or about the overall Help experience, we'd love to hear from
you. Just send your feedback to Exchange 2013 Help Feedback. Your comments will help us provide the most
accurate and concise content.
 What's new in Exchange 2013
6/19/2019 • 28 minutes to read • Edit Online

Applies to: Exchange Server 2013

Check out all of the newest capabilities in Exchange 2013.
Microsoft Exchange Server 2013 brings a new rich set of technologies, features, and services to the Exchange
Server product line. Its goal is to support people and organizations as their work habits evolve from a
communication focus to a collaboration focus. At the same time, Exchange Server 2013 helps lower the total cost
of ownership whether you deploy Exchange 2013 on-premises or provision your mailboxes in the cloud. New
features and functionality in Exchange 2013 are designed to do the following:
Support a multigenerational workforce: Social integration and making it easier to find people is
important to users. Smart Search learns from users' communication and collaboration behavior to
enhance and prioritize search results in Exchange. Also, with Exchange 2013, users can merge contacts
from multiple sources to provide a single view of a person, by linking contact information pulled from
multiple locations.
Provide an engaging experience: Microsoft Outlook 2013 and Microsoft Outlook Web App have a
fresh new look. Outlook Web App emphasizes a streamlined user interface that also supports the use of
touch, enhancing the mobile device experience with Exchange.
Integrate with SharePoint and Lync: Exchange 2013 offers greater integration with Microsoft
SharePoint 2013 and Microsoft Lync 2013 through site mailboxes and In-Place eDiscovery. Together,
these products offer a suite of features that make scenarios such as enterprise eDiscovery and
collaboration using site mailboxes possible.
Help meet evolving compliance needs: Compliance and eDiscovery are challenging for many
organizations. Exchange 2013 helps you to find and search data not only in Exchange, but across your
organization. With improved search and indexing, you can search across Exchange 2013, Lync 2013,
SharePoint 2013, and Windows file servers. In addition, data loss prevention (DLP ) can help keep your
organization safe from users mistakenly sending sensitive information to unauthorized people. DLP helps
you identify, monitor, and protect sensitive data through deep content analysis.
Provide a resilient solution: Exchange 2013 builds upon the Exchange Server 2010 architecture and
has been redesigned for simplicity of scale, hardware utilization, and failure isolation.
For information about the changes made to Exchange Server 2013 since release to manufacturing (RTM ), see
Updates for Exchange 2013.
See the following sections for more information about what's new in Exchange 2013:
Exchange admin center
Exchange 2013 architecture
Setup
Messaging policy and compliance
Anti-malware protection
Mail flow
Recipients
Sharing and collaboration
Integration with SharePoint and Lync
Clients and mobile
Unified Messaging
Batch mailbox moves
High availability and site resilience
Exchange workload management

NOTE
For information about features in earlier versions of Exchange that have been removed, discontinued, or replaced in
Exchange Server 2013, see What's discontinued in Exchange 2013. Also, you may be interested in Release notes for
Exchange 2013.

Exchange admin center

Exchange 2013 provides a single unified management console that allows for ease of use and is optimized for
management of on-premises, online, or hybrid deployments. The Exchange admin center (EAC ) in Exchange
2013 replaces the Exchange 2010 Exchange Management Console (EMC ) and the Exchange Control Panel
(ECP ). (However, "ECP" is still the name of the virtual directory used by the EAC.) Some EAC features include:
List view: The list view in EAC has been designed to remove key limitations that existed in ECP. ECP was
limited to displaying up to 500 objects and, if you wanted to view objects that weren't listed in the details
pane, you needed to use searching and filtering to find those specific objects. In Exchange 2013, the
viewable limit from within the EAC list view is approximately 20,000 objects. After the EAC returns the
results, the EAC client performs the searching and sorting, which greatly increases the performance
compared to the ECP in Exchange 2010. In addition, paging has been added so that you can page to the
results. You can also configure page size and export to a .csv file.
Add/Remove columns to the Recipient list view: You can choose which columns to view, and with
local cookies, you can save your custom list views per machine that you use to access the EAC.
Secure the ECP virtual directory: You can partition access from the Internet and intranets from within
the ECP IIS virtual directory to allow or disallow management features. With this feature, you can permit
or deny access to users trying to access the EAC from the Internet outside of your organizational
environment, while still allowing access to an end-user's Outlook Web App Options.
Public Folder management: In Exchange 2010 and Exchange 2007, public folders were managed
through the Public Folder administration console. Public folders are now in the EAC, and you don't need a
separate tool to manage them.
Notifications: In Exchange 2013, the EAC now has a Notification viewer so that you can view the status
of long-running processes and, if you choose, receive notification via an email message when the process
completes.
Role Based Access Control (RBAC ) User Editor: In Exchange 2010, you could use the RBAC User
Editor in the Exchange Toolbox to add users to management role groups. In Exchange 2013, the RBAC
User Editor functionality is now in the EAC and you don't need a separate tool to manage RBAC.
Unified Messaging Tools: In Exchange 2010, you could use the Call Statistics and User Call Logs tools
 to help provide UM statistics and information about specific calls for a UM -enabled user. In Exchange
2013, the Call Statistics and User Call Logs tools are now in the EAC and you don't need a separate tool to
manage them.
Groups enhancements: The Exchange admin center (EAC ) can now display up to 10,000 recipients in
the Groups Select Members window. By default, up to 500 recipients are returned when you open the
Select Members window, however, you can choose to list up to 10,000 recipients by clicking Get All
Results beneath the recipient list. We now support browsing more than 500 recipients by using the scroll
bar and we've also added enhanced search features to enable you to filter recipients that are displayed in
the recipient list. You can filter by:
city
company
country/region
department
office
title
For more information, see Exchange admin center in Exchange 2013.

Exchange 2013 architecture

Previous versions of Exchange were optimized and architected with certain technological constraints that existed
at that time. For example, during development for Exchange 2007, one of the key constraints was CPU
performance. To alleviate that constraint, Exchange 2007 was split into different server roles that allowed scale
out through server separation. However, server roles in Exchange 2007 and Exchange 2010 were tightly
coupled. The tight coupling of the roles had several downsides including version dependency, geo-affinity
(requiring all roles in a specific site), session affinity (requiring expensive layer 7 hardware load balancing), and
namespace complexity.
Today, CPU horsepower is significantly less expensive and is no longer a constraining factor. With that constraint
lifted, the primary design goal for Exchange 2013 is for simplicity of scale, hardware utilization, and failure
isolation. With Exchange 2013, we reduced the number of server roles to three: the Client Access, Mailbox, and
Edge Transport server roles.
The Mailbox server includes all the traditional server components found in Exchange 2010: the Client Access
protocols, Transport service, Mailbox databases, and Unified Messaging. The Mailbox server handles all activity
for the active mailboxes on that server. The Client Access server provides authentication, limited redirection, and
proxy services. The Client Access server itself doesn't do any data rendering. The Client Access server is a thin
and stateless server. There is never anything queued or stored on the Client Access server. The Client Access
server offers all the usual client access protocols: HTTP, POP and IMAP, and SMTP.
With this new architecture, the Client Access server and the Mailbox server have become "loosely coupled." All
processing and activity for a specific mailbox occurs on the Mailbox server that houses the active database copy
where the mailbox resides. All data rendering and data transformation is performed local to the active database
copy, eliminating concerns of version compatibility between the Client Access server and the Mailbox server.
With Exchange 2013 Service Pack 1, we've re-introduced the Edge Transport server role. The Edge Transport role
is typically deployed in your perimeter network, outside your internal Active Directory forest, and is designed to
minimize the attack surface of your Exchange deployment. By handling all Internet-facing mail flow, it also adds
additional layers of message protection and security against viruses and spam, and can apply transport rules to
control message flow. For more information about the Edge Transport server role, see Edge Transport servers.
The Exchange 2013 architecture provides the following benefits:
Version upgrade flexibility: No more rigid upgrade requirements. A Client Access server can be
upgraded independently and in any order in relation to the Mailbox server.
Session indifference: With Exchange 2010, session affinity to the Client Access server role was required
for several protocols. In Exchange 2013, the client access and mailbox components reside on the same
Mailbox server. Because the Client Access server simply proxies all connections for a user to a specific
Mailbox server, no session affinity is required at the Client Access servers. This allows inbound
connections to Client Access servers to be balanced using techniques provided by load-balancing
technology like least connection or round-robin.
Deployment simplicity: With an Exchange 2010 site-resilient design, you needed up to eight different
namespaces: two Internet Protocol namespaces, two for Outlook Web App fallback, one for Autodiscover,
two for RPC Client Access, and one for SMTP. A legacy namespace was also required if you were
upgrading from Exchange 2003 or Exchange 2007. With Exchange 2013, the minimum number of
namespaces drops to two. If you're coexisting with Exchange 2007, you still need to create a legacy
hostname, but if you're coexisting with Exchange 2010 or you're installing a new Exchange 2013
organization, the minimum number of namespaces you need is two: one for client protocols and one for
Autodiscover. You may also need an SMTP namespace.
As a result of these architectural changes, there have been some changes to client connectivity. First, RPC is no
longer a supported direct access protocol. This means that all Outlook connectivity must take place using RPC
over HTTP (also known as Outlook Anywhere). At first glance, this may seem like a limitation, but it actually has
some added benefits. The most obvious benefit is that there is no need to have the RPC client access service on
the Client Access server. This results in the reduction of two namespaces that would normally be required for a
site-resilient solution. In addition, there is no longer any requirement to provide affinity for the RPC client access
service.
Second, Outlook clients no longer connect to a server FQDN as they have done in all previous versions of
Exchange. Outlook uses Autodiscover to create a new connection point comprised of mailbox GUID, @ symbol,
and the domain portion of the user's primary SMTP address. This simple change results in a near elimination of
the unwelcome message of "Your administrator has made a change to your mailbox. Please restart." Only
Outlook 2007 and higher versions are supported with Exchange 2013.
The high availability model of the mailbox component has not changed significantly since Exchange 2010. The
unit of high availability is still the database availability group (DAG ). The DAG still uses Windows Server failover
clustering. Continuous replication still supports both file mode and block mode replication. However, there have
been some improvements. Failover times have been reduced as a result of transaction log code improvements
and deeper checkpoint on the passive databases. The Exchange Store service has been re-written in managed
code (see the "Managed Store" section later in this topic). Now, each database runs under its own process,
allowing for isolation of store issues to a single database.

Managed Store
In Exchange 2013, the Managed Store is the name of the newly rewritten Information Store processes,
Microsoft.Exchange.Store.Service.exe and Microsoft.Exchange.Store.Worker.exe. The new Managed Store is
written in C# and tightly integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) to
provide higher availability through improved resiliency. In addition, the Managed Store has been architected to
enable more granular management of resource consumption and faster root cause analysis through improved
diagnostics.
The Managed Store works with the Microsoft Exchange Replication service to manage mailbox databases, which
continues to use Extensible Storage Engine (ESE ) as the database engine. Exchange 2013 includes significant
changes to the mailbox database schema that provide many optimizations over previous versions of Exchange.
In addition to these changes, the Microsoft Exchange Replication service is responsible for all service availability
related to Mailbox servers. The architectural changes enable faster database failover and better physical disk
failure handling.
The Managed Store is also integrated with the Search Foundation search engine (the same search engine used
by SharePoint 2013) to provide more robust indexing and searching when compared to Microsoft Search in
previous versions of Exchange.
For more information, see High availability and site resilience.

Certificate management
Managing digital certificates is one of the most important security-related tasks for your Exchange organization.
Ensuring that certificates are appropriately configured is key to delivering a secure messaging infrastructure for
the enterprise. In Exchange 2010, the Exchange Management Console was the primary method of managing
certificates. In Exchange 2013, certificate management functionality is provided in the Exchange admin center,
the new Exchange 2013 administrator user interface.
The work in Exchange 2013 related to certificates focused around minimizing the number of certificates that an
Administrator must manage, minimizing the interaction the Administrator must have with certificates, and
allowing management of certificates from a central location. Benefits resulting from the changes in certificate
management are:
Certificate management can be performed on the Client Access server or the Mailbox server. The Mailbox
server has a self-signed certificate installed by default. The Client Access server automatically trusts the
self-signed certificate on the Exchange 2013 Mailbox server, so clients will not receive warnings about a
self-signed certificate not being trusted provided that the Exchange 2013 Client Access server has a non-
self-signed certificate from either a Windows certificate authority (CA) or a trusted third party.
In previous versions of Exchange, it was difficult to see when a digital certificate was nearing expiration. In
Exchange 2013, the Notifications center will display warnings when a certificate stored on any Exchange
2013 server is about to expire. Administrators can also choose to receive these notifications via email.
For more information, see Digital certificates and SSL .

Setup
Setup has been completely rewritten so that installing Exchange 2013 and making sure you've got the latest
product rollups and security fixes is easier than ever. Here are some of the improvements we've made:
Always up-to-date Setup: When you run the Setup wizard, you'll be given the option to download and
use the latest product rollups, security fixes, and language packs. This option doesn't just update the files
that'll be used to run Exchange; Setup itself can be updated. This design enables us to continue to improve
Setup post-release and include and update readiness checks as requirements are updated or changed.
If you're using unattended Setup mode, we can't automatically download updates. However, you can still
take advantage of running the latest version of Setup by downloading the latest updates beforehand, and
use the /UpdatesDir: <path> parameter to allow Setup to update itself before the installation process
begins.
Improved readiness checks: Readiness checks make sure that your computer and your organization are
ready for Exchange 2013. After you've provided the necessary information about your installation to
Setup, the readiness checks are run before installation begins. The new readiness check engine now runs
through all checks before reporting back to you on what actions need to be performed before Setup can
continue, and it does so faster than ever. As with previous versions of Exchange, you can tell Setup to
install the Windows features required by Setup so you don't have to install them manually.
 Simplified and modern wizard: We've removed all the steps in the Setup wizard that aren't absolutely
required for you to install Exchange. What's left is an easy-to-follow wizard that takes you through the
installation process one step at a time.
For more information, see Planning and deployment.

Messaging policy and compliance

There are two new message policy and compliance features in Exchange 2013: Data loss prevention and the
Microsoft Rights Management connector.
Data loss prevention (DLP ) capabilities help you protect your sensitive data and inform users of internal
compliance policies. DLP can also help keep your organization safe from users who might mistakenly send
sensitive information to unauthorized people. DLP helps you identify, monitor, and protect sensitive data through
deep content analysis. Exchange 2013 offers built-in DLP policies based on regulatory standards such as
personally identifiable information (PII) and payment card industry data security standards (PCI), and is
extensible to support other policies important to your business. Additionally, the new PolicyTips in Outlook 2013
inform users about policy violations before sensitive data is sent.
The Microsoft Rights Management connector (RMS connector) is an optional application that helps you enhance
data protection for your Exchange 2013 server by connecting to cloud-based Microsoft Rights Management
services. Once you install the RMS connector, it provides continuous data protection throughout the lifespan of
the information and because these services are customizable, you can define the level of protection you need.
For example, you can limit email message access to specific users or set view -only rights for certain messages.
To learn more about these features see:
Data loss prevention
Rights Management connector

In-place Archiving, retention, and eDiscovery

Exchange 2013 includes the following improvements to In-Place Archiving, retention, and eDiscovery to help
your organization meet its compliance needs:
In-Place Hold: In-Place Hold is a new unified hold model that allows you to meet legal hold
requirements in the following scenarios:
Preserve the results of the query (query-based hold), which allows for scoped immutability across
mailboxes.
Place a time-based hold to meet retention requirements (for example, retain all items in a mailbox
for seven years, a scenario that required the use of Single Item Recovery/Deleted Item Retention in
Exchange 2010).
Place a mailbox on indefinite hold (similar to litigation hold in Exchange 2010).
Place a user on multiple holds to meet different case requirements.
In-Place eDiscovery: In-Place eDiscovery allows authorized users to search mailbox data across all
mailboxes and In-Place Archives in an Exchange 2013 organization and copy messages to a discovery
mailbox for review. In Exchange 2013, In-Place eDiscovery has been enhanced to allow discovery
managers to perform more efficient searches and hold. These enhancements include:
Federated search allows you to search and preserve data across multiple data repositories. With
Exchange 2013, you can perform in-place eDiscovery searches across Exchange, SharePoint 2013,
and Lync 2013. You can use the eDiscovery Center in SharePoint 2013 to perform In-Place
 eDiscovery search and hold.
Query-based In-Place Hold allows you to save the results of the query, which allows for scoped
immutability across mailboxes.
Export search results Discovery Managers can export mailbox content to a .pst file from the
SharePoint 2013 eDiscovery Console. Mailbox export request cmdlets are no longer required to
export a mailbox to a .pst file.
Keyword statistics: Search statistics are offered on a per search term basis. This enables a
Discovery Manager to quickly make intelligent decisions about how to further refine the search
query to provide better results. eDiscovery search results are sorted by relevance.
KQL syntax: Discovery Managers can use Keyword Query Language (KQL ) syntax in search
queries. KQL is similar to the Advanced Query Syntax (AQS ), which was used for discovery
searches in Exchange 2010.
In-Place eDiscovery and Hold wizard: Discovery Managers can use the new In-Place
eDiscovery and Hold wizard to perform eDiscovery and hold operations.

> [!NOTE]
> If SharePoint 2013 isn't available, a subset of the eDiscovery functionality is available in
the Exchange admin center.

Search across primary and archive mailboxes in Outlook Web App: Users can search across their
primary and archive mailboxes in Outlook Web App. Two separate searches are no longer necessary.
Archive Lync content: Exchange 2013 supports archiving of Lync 2013 content in a user's mailbox. You
can place Lync content on hold using In-Place Hold and use In-Place eDiscovery to search Lync content
archived in Exchange.
Retention policies: Retention policies help your organization reduce risks associated with email and
other communications and also meet email retention requirements. Retention policies include the
following enhancements:
Support for Calendar and Tasks retention tags: You can create retention policy tags for the
Calendar and Tasks default folders to expire items in these folders. Items in these folders are also
moved to the user's archive based on the archive policy settings applied to the mailbox.
Improved ability to retain items for a specified period: You can use retention policy and a
time-based In-Place Hold to enforce retention of items for a set period.
For more information, see Messaging policy and compliance.

Transport rules
Transport rules in Exchange Server 2013 are a continuation of the features that are available in Exchange Server
2010. However, several improvements have been made to transport rules in Exchange 2013. The most
important change is the support for data loss prevention (DLP ). There are also new predicates and actions,
enhanced monitoring, and a few architectural changes.
For detailed information, see What's new for transport rules.

Information Rights Management

Information Rights Management (IRM ) is compatible with Cryptographic Mode 2, an Active Directory Rights
Management Services (AD RMS ) cryptography mode that supports stronger encryption by allowing you to use
2048-bit keys for RSA and 256-bit keys for SHA-1. Additionally, Mode 2 enables you to use the SHA-2 hashing
algorithm. For more information about cryptographic modes in AD RMS, see AD RMS Cryptographic Modes.

Auditing
Exchange 2013 includes the following improvements to auditing:
Auditing reports: The EAC includes auditing functionality so that you can run reports or export entries
from the mailbox audit log and the administrator audit log. The mailbox audit log records whenever a
mailbox is accessed by someone other than the person who owns the mailbox. This can help you
determine who has accessed a mailbox and what they have done. The administrator audit log records any
action, based on an Exchange Management Shell cmdlet, performed by an administrator. This can help
you troubleshoot configuration issues or identify the cause of problems related to security or compliance.
For more information, see Exchange auditing reports.
Viewing the administrator audit log: Instead of exporting the administrator audit log, which can take
up to 24 hours to receive in an email message, you can view administrator audit log entries in the EAC. To
do this, go to Compliance Management > Auditing and click View the administrator audit log. Up
to 1000 entries will be displayed on multiple pages. To narrow the search, you can specify a date range.
For more information, see View the administrator audit log.

Anti-malware protection
The built-in malware filtering capabilities of Exchange 2013 helps protect your network from malicious software
transferred through email messages. All messages sent or received by your Exchange server are scanned for
malware (viruses and spyware). If malware is detected, the message is deleted. Notifications may also be sent to
senders or administrators when an infected message is deleted and not delivered. You can also choose to replace
infected attachments with either default or custom messages that notify the recipients of the malware detection.
For more information about anti-malware protection, see Anti-malware protection.

Mail flow
How messages flow through an organization and what happens to them has changed significantly in Exchange
2013. Following is a brief overview of the changes:
Transport pipeline: The transport pipeline in Exchange 2013 is now made up of several different
services: the Front End Transport service on Client Access servers, the Transport service on Mailbox
servers, and the Mailbox Transport service on Mailbox servers. For more information, see Mail flow.
Routing: Mail routing in Exchange 2013 recognizes DAG boundaries as well as Active Directory site
boundaries. Also, mail routing has been improved to queue messages more directly for internal recipients.
For more information, see Mail routing.
Connectors: The default maximum message size for a Send connector or a Receive connector, as
specified by the MaxMessageSize parameter, has been increased from 10MB to 25MB. For more
information about how to set parameters on a connector, see Set-SendConnector and Set-
ReceiveConnector.
You can set a Send connector in the Transport service of a Mailbox server to route outbound mail through
a Front End transport server in the local Active Directory site, by means of the FrontEndProxyEnabled
parameter of the Set-SendConnector cmdlet, thus consolidating how email is routed from the Transport
service.
Edge Transport: You can optionally install an Edge Transport server in your perimeter network to reduce
your attack surface and provide message protection and security. For more information, see Edge
 Transport servers.

Recipients
This section describes the enhancements for managing recipients in Exchange 2013:
Group naming policy: Administrators can now use the EAC to create a group naming policy, which lets
you standardize and manage the names of distribution groups created by users in your organization. You
can require a specific prefix and suffix be added to the name for a distribution group when it's created, and
you can block specific words from being used. This capability helps you minimize the use of inappropriate
words in group names.
For more information, see Create a distribution group naming policy.
Message tracking: Administrators can also use the EAC to track delivery information for email messages
sent to or received by any user in your organization. You just select a mailbox, and then search for
messages sent to or received by a different user. You can narrow the search by searching for specific
words in the subject line. The resulting delivery report tracks a message through the delivery process and
specifies if the message was successfully delivered, pending delivery, or if it wasn't delivered.
For more information, see Track messages with delivery reports .

Sharing and collaboration

This section describes the sharing and collaboration enhancements in Exchange 2013.
Public folders: Public folders now take advantage of the existing high availability and storage
technologies of the mailbox store. The public folder architecture uses specially designed mailboxes to
store both the hierarchy and the public folder content. This new design also means that there is no longer
a public folder database. Public folder replication now uses the continuous replication model. High
availability for the hierarchy and content mailboxes is provided by the database availability group (DAG ).
With this design, we're moving away from a multi-master replication model to a single-master replication
model.
Outlook Web App users in your organization now have the ability to add public folders to, or remove
them from, their Favorites. Previously, this could only be done in Outlook.
For more information, see Public folders.
Site mailboxes: Email and documents are traditionally kept in two unique and separate data repositories.
Most teams would typically collaborate using both mediums. The challenge is that email and documents
are accessed using different clients, which usually results in a reduction in user productivity and a
degraded user experience.
The site mailbox is a new concept in Exchange 2013 that attempts to solve these problems. Site mailboxes
improve collaboration and user productivity by allowing access to both documents in a SharePoint site
and email messages in Outlook 2013, using the same client interface. A site mailbox is functionally
comprised of SharePoint site membership (owners and members), shared storage through an Exchange
mailbox for email messages and a SharePoint site for documents, and a management interface that
addresses provisioning and lifecycle needs.
For more information, see Site mailboxes.
Shared mailboxes: In previous versions of Exchange, creating a shared mailbox was a multi-step process
in which you had to use the Exchange Management Shell to set the delegate permissions. In Exchange
2013, you can now create a shared mailbox in one step via the Exchange admin center. In the EAC, go to
Recipients > Shared Mailboxes to create a shared mailbox. Shared mailbox is now a recipient type, so
 you can easily search for your shared mailboxes in either the user interface or by using the Shell.
For more information, see Shared mailboxes.

Integration with SharePoint and Lync

Exchange 2013 offers greater integration with SharePoint 2013 and Lync 2013. Benefits of this enhanced
integration include:
Exchange 2013 integrates with SharePoint 2013 to allow users to collaborate more effectively by using
site mailboxes.
Lync Server 2013 can archive content in Exchange 2013 and use Exchange 2013 as a contact store.
Discovery Managers can perform In-Place eDiscovery and Hold searches across SharePoint 2013,
Exchange 2013, and Lync 2013 data.
Oauth authentication allows partner applications to authenticate as a service or impersonate users where
required.
For more information, see Integration with SharePoint and Lync.

Clients and mobile

The Outlook Web App user interface is new and optimized for tablets and smartphones as well as desktop and
laptop computers. New features include apps for Outlook, which allow users and administrators to extend the
capabilities of Outlook Web App; Contact linking, the ability for users to add contacts from their LinkedIn
accounts; and updates to the look and features of the calendar.
For more information, see What's new for Outlook Web App in Exchange 2013.

Unified Messaging
Unified Messaging in Exchange 2013 contains essentially the same voice mail features included in Exchange
2010. However, some new and enhanced features and functionality have been added to those existing features.
More importantly, architectural changes in Exchange 2013 Unified Messaging resulted in components, services,
and functionality that were included with the Unified Messaging server role in Exchange 2010 to be divided
between the Exchange 2013 Client Access and Mailbox server roles.
For more details, see What's new for Unified Messaging in Exchange 2013.

Batch mailbox moves

Exchange 2013 introduces the concept of batch moves. The new move architecture is built on top of MRS
(Mailbox Replication service) moves with enhanced management capability. The new batch move architecture
features the following enhancements:
Ability to move multiple mailboxes in large batches.
Email notification during move with reporting.
Automatic retry and automatic prioritization of moves.
Primary and personal archive mailboxes can be moved together or separately.
Option for manual move request finalization, which allows you to review a move before you complete it.
Periodic incremental syncs to migrate the changes.
For more information, see Manage on-premises moves.

High availability and site resilience

Exchange 2013 uses DAGs and mailbox database copies, along with other features such as single item recovery,
retention policies, and lagged database copies, to provide high availability, site resilience, and Exchange native
data protection. The high availability platform, the Exchange Information Store and the Extensible Storage
Engine (ESE ), have all been enhanced to provide greater availability, easier management, and to reduce costs.
These enhancements include:
Managed availability: With managed availability, internal monitoring and recovery-oriented features
are tightly integrated to help prevent failures, proactively restore services, and initiate server failovers
automatically or alert administrators to take action. The focus is on monitoring and managing the end
user experience rather than just server and component uptime to help keep the service continuously
available.
Managed Store: The Managed Store is the name of the newly rewritten Information Store processes in
Exchange 2013. The new Managed Store is written in C# and tightly integrated with the Microsoft
Exchange Replication service (MSExchangeRepl.exe) to provide higher availability through improved
resiliency.
Support for multiple databases per disk: Exchange 2013 includes enhancements that enable you to
support multiple databases (mixtures of active and passive copies) on the same disk, thereby leveraging
larger disks in terms of capacity and IOPS as efficiently as possible.
Automatic reseed: Enables you to quickly restore database redundancy after disk failure. If a disk fails,
the database copy stored on that disk is copied from the active database copy to a spare disk on the same
server. If multiple database copies were stored on the failed disk, they can all be automatically re-seeded
on a spare disk. This enables faster reseeds, as the active databases are likely to be on multiple servers
and the data is copied in parallel.
Automatic recovery from storage failures: This feature continues the innovation introduced in
Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. In
addition to the Exchange 2010 bugcheck behaviors, Exchange 2013 includes additional recovery
behaviors for long I/O times, excessive memory consumption by MSExchangeRepl.exe, and severe cases
where the system is in such a bad state that threads can't be scheduled.
Lagged copy enhancements: Lagged copies can now care for themselves to a certain extent using
automatic log play down. Lagged copies will automatically play down log files in a variety of situations,
such as single page restore and low disk space scenarios. If the system detects that page patching is
required for a lagged copy, the logs will be automatically replayed into the lagged copy to perform page
patching. Lagged copies will also invoke this auto replay feature when a low disk space threshold has
been reached, and when the lagged copy has been detected as the only available copy for a specific period
of time. In addition, lagged copies can leverage Safety Net, making recovery or activation much easier.
Safety Net is improved functionality in Exchange 2013 based on the transport dumpster of Exchange
2010.
Single copy alert enhancements: The single copy alert introduced in Exchange 2010 is no longer a
separate scheduled script. It's now integrated into the managed availability components within the system
and is a native function within Exchange.
DAG network auto-configuration: DAGs networks can be automatically configured by the system
based on configuration settings. In addition to manual configuration options, DAGs can also distinguish
between MAPI and Replication networks and configure DAG networks automatically.
For more information about both of these features, see High availability and site resilience and Changes to high
availability and site resilience over previous versions.

Exchange workload management

An Exchange workload is an Exchange server feature, protocol, or service that has been explicitly defined for the
purposes of Exchange system resource management. Each Exchange workload consumes system resources such
as CPU, mailbox database operations, or Active Directory requests to execute user requests or run background
work. Examples of Exchange workloads include Outlook Web App, Exchange ActiveSync, mailbox migration, and
mailbox assistants.
There are two ways to manage Exchange workloads in Exchange 2013:
Monitor the health of system resources: Managing workloads based on the health of system
resources is new in Exchange 2013.
Control how resources are consumed by individual users: Controlling how resources are consumed
by individual users was possible in Exchange 2010 (where it's called user throttling), and this capability
has been expanded for Exchange 2013.
For more information about these features, see Exchange workload management.
 What's discontinued in Exchange 2013
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic discusses the components, features, or functionality that have been removed, discontinued, or replaced
in Microsoft Exchange Server 2013.

NOTE
The following topics may also interest you:
What's new in Exchange 2013 Information about new features and functionality in Exchange Server 2013.
Developer roadmap for Exchange 2013 See the "Development technologies removed from Exchange" section for
information about the API and Development features discontinued in Exchange 2013.

Discontinued features from Exchange 2010 to Exchange 2013

This section lists the Exchange Server 2010 features that are no longer available in Exchange 2013.

Architecture
FEATURE COMMENTS AND MITIGATION

Hub Transport server role The Hub Transport server role has been replaced by
Transport services which run on the Mailbox and Client
Access server roles. The Mailbox server role includes the
Microsoft Exchange Transport, Microsoft Exchange
Mailbox Transport Delivery, and the Microsoft Exchange
Mailbox Transport Submission service. The Client Access
server role includes the Microsoft Exchange Frontend
Transport service. For more information, see Mail flow.

Unified Messaging server role The Unified Messaging server role has been replaced by
Unified Messaging services which run on the Mailbox and
Client Access server roles. The Mailbox server role includes
the Microsoft Exchange Unified Messaging service and the
Client Access server role includes the Microsoft Exchange
Unified Messaging Call Router service. For more
information, see Voice architecture changes.

Management interfaces
FEATURE COMMENTS AND MITIGATION
 FEATURE COMMENTS AND MITIGATION

Exchange Management Console and Exchange Control The Exchange Management Console and the Exchange
Panel Control Panel have been replaced by the Exchange admin
center (EAC). EAC uses the same virtual directory (/ecp) as
the Exchange Control Panel. For more information, see
Exchange admin center in Exchange 2013.

Client access
FEATURE COMMENTS AND MITIGATION

Outlook 2003 is not supported To connect Microsoft Outlook to Exchange 2013, the use
of the Autodiscover service is required. However,
Microsoft Outlook 2003 doesn't support the use of the
Autodiscover service.

RPC/TCP access for Outlook clients In Exchange 2013, Microsoft Outlook clients can connect
using Outlook Anywhere (RPC/HTTP) or MAPI over HTTP
in Exchange 2013 Service Pack 1 and Outlook 2013
Service Pack 1 and later. If you have Outlook clients in
your organization, using Outlook Anywhere and/or MAPI
over HTTP is required. For more information, see Outlook
Anywhere and MAPI over HTTP.

Outlook Web App and Outlook

FEATURE COMMENTS AND MITIGATION

Spell check Outlook Web App no longer has built-in spell check
services. Instead, it uses the spell check features in your
Web browsers.

Customizable filters Outlook Web App no longer has customizable filtered

views and no longer supports saving filtered views to
Favorites. Customizable filters have been replaced by fixed
filters that can be used to view all messages, unread
messages, messages sent to the user, or flagged
messages.

Message flags The ability to set a custom date on a message flag isn't
available in Outlook Web App. You can use Outlook to set
custom dates.

Chat contact list The chat contact list that appeared in the folder list in
Outlook Web App for Exchange 2010 is no longer
available.

Search folders The ability for users to use Search folders isn't currently
available in Outlook Web App.
Mail flow
FEATURE COMMENTS AND MITIGATION

Linked connectors The ability to link a Send connector to a Receive connector

has been removed. Specifically, the
LinkedReceiveConnector parameter has been removed
from New-SendConnector and Set-SendConnector.

Anti-spam and anti-malware

FEATURE COMMENTS AND MITIGATION

Anti-spam agent management in the EMC In Exchange 2010, when you enabled the anti-spam
agents on a Hub Transport server, you could manage the
anti-spam agents in the Exchange Management Console
(EMC). In Exchange 2013, when you enable the anti-spam
agents on a Mailbox server, you can't manage the agents
using the EAC. You can only use the Shell. For information
about how to enable the anti-spam agents on a Mailbox
server, see Enable anti-spam functionality on Mailbox
servers.

Connection Filtering agent on Hub Transport servers In Exchange 2010, when you enabled the anti-spam
agents on a Hub Transport server, the Attachment Filter
agent was the only anti-spam agent that wasn't available.
In Exchange 2013, when you enable the anti-spam agents
on a Mailbox server, the Attachment Filter agent and the
Connection Filtering agent aren't available. The
Connection Filtering agent provides IP Allow List and IP
Block List capabilities. For information about how to
enable the anti-spam agents on a Mailbox server, see
Enable anti-spam functionality on Mailbox servers.

NOTE
You can't enable the anti-spam agents on an Exchange
2013 Client Access server. Therefore, the only way to get
the Connection Filtering agent is to install an Edge
Transport server in the perimeter network. For more
information, see Edge Transport servers.

Messaging policy and compliance

FEATURE COMMENTS AND MITIGATION
 FEATURE COMMENTS AND MITIGATION

Managed Folders In Exchange 2010, you use managed folders for

messaging retention management (MRM). In Exchange
2013, managed folders aren't supported. You must use
retention policies for MRM.

NOTE
Cmdlets related to managed folders are still available.
You can create managed folders, managed content
settings and managed folder mailbox policies, and
apply a managed folder mailbox policy to a user, but
the MRM assistant skips processing of mailboxes that
have a managed folder mailbox policy applied.

Port Managed Folder wizard In Exchange 2010, you use the Port Managed Folder
wizard to create retention tags based on managed folder
and managed content settings. In Exchange 2013, the
Exchange admin center doesn't include this functionality.
You can use the New-RetentionPolicyTag cmdlet with
the ManagedFolderToUpgrade parameter to create a
retention tag based on a managed folder.

Unified Messaging and voice mail

FEATURE COMMENTS AND MITIGATION

Directory lookups using Automatic Speech Recognition In Exchange 2010, Outlook Voice Access users can use
(ASR) speech inputs using Automatic Speech Recognition (ASR)
to search for users listed in the directory. Speech inputs
could be also used in Outlook Voice Access to navigate
menus, messages, and other options. However, even if an
Outlook Voice Access user is able to use speech inputs,
they have to use the telephone key pad to enter their PIN,
and navigate personal options.
In Exchange 2013, authenticated and non-authenticated
Outlook Voice Access users can't search for users in the
directory using speech inputs or ASR in any language.
However, callers that call into an auto attendant can use
speech inputs in multiple languages to navigate auto
attendant menus and search for users in the directory.

Tools
FEATURE COMMENTS AND MITIGATION

Exchange Best Practice Analyzer In Exchange 2010, the Exchange Best Practice Analyzer
examined your Exchange deployment and determined
whether the configuration was in line with Microsoft best
practices. In Exchange 2013, the Exchange Best Practice
Analyzer has been replaced by the Office 365 Best
Practices Analyzer for Exchange Server 2013.
 FEATURE COMMENTS AND MITIGATION

Mail flow troubleshooter In Exchange 2010, the mail flow troubleshooter assisted
you in troubleshooting common mail flow problems. In
Exchange 2013, the mail flow troubleshooter has been
retired. You can now use the messaging tracking feature
in EAC in Exchange 2013. For more information, see Track
messages with delivery reports.

Performance monitor In Exchange 2010, the Performance Monitor was included

in the Exchange toolbox to allow you to collect
information about the performance of your messaging
system. Performance Monitor is commonly used to view
key parameters while troubleshooting performance
problems. In Exchange 2013, the Performance Monitor
has been retired from the toolbox. You can still find the
Performance Monitor under Administrative Tools in
Windows Server 2008.

Performance troubleshooter In Exchange 2013, the Performance Troubleshooter has

been retired.

Routing Log Viewer In Exchange 2013, the routing log viewer has been retired.

Mailbox database copies

FEATURE COMMENTS AND MITIGATION

Update-MailboxDatabaseCopy Content index catalog seeding is no longer possible over

the replication network; it can only be done over a MAPI
Update Mailbox Database Copy wizard network. This is true even when you use the -Network
parameter in the Update-MailboxDatabaseCopy cmdlet.

Discontinued features from Exchange 2007 to Exchange 2013

This section lists the Exchange Server 2007 features that are no longer available in Exchange 2013.

APIs and development

FEATURE COMMENTS AND MITIGATION

Exchange WebDAV Use Exchange Web Services or EWS Managed API.

Alternatively, you can maintain an Exchange 2007 server
for mailboxes that are managed by applications that use
WebDAV. For more information, see Migrating from
WebDAV.

Architecture
 FEATURE COMMENTS AND MITIGATION

Storage groups Exchange 2013 no longer uses the storage group

construct, and instead you simply manage mailbox
databases. For more information, see Manage mailbox
databases in Exchange 2013.

Extensible Storage Engine (ESE) streaming backup APIs Exchange 2013 supports only Exchange-aware Volume
Shadow Copy Service (VSS)-based backups. Exchange
2013 does include a plug-in for Windows Server Backup
that enables you to backup and restore data. For
information, see Backup, restore, and disaster recovery.

User Datagram Protocol (UDP) notifications Support for User Datagram Protocol (UDP) notifications is
removed from Exchange 2013. This affects the user
experience when Outlook 2003 clients connect to their
mailboxes on an Exchange 2013 server. For more
information, see Microsoft Knowledge Base article
2009942, Folders take a long time to update when an
Exchange Server 2010 user uses Outlook 2003 in online
mode.

High availability
FEATURE COMMENTS AND MITIGATION

Cluster continuous replication (CCR) Exchange 2013 uses database availability groups (DAGs)
and mailbox database copies. For information, see High
availability and site resilience.

Local continuous replication (LCR) Exchange 2013 uses DAGs and mailbox database copies.
For information, see High availability and site resilience.

Standby continuous replication (SCR) Exchange 2013 uses DAGs and mailbox database copies.
For information, see High availability and site resilience.

Single copy cluster (SCC) Exchange 2013 uses DAGs and mailbox database copies.
For information, see High availability and site resilience.

Setup /recoverCMS Exchange 2013 uses Setup /m:recoverServer. For

information, see Recover an Exchange Server.

Clustered mailbox servers Exchange 2013 uses DAGs and mailbox database copies.
For information, see High availability and site resilience.

Client access
 FEATURE COMMENTS AND MITIGATION

Client authentication using Integrated Windows NTLM isn't supported for POP3 or IMAP4 client
authentication (NTLM) for POP3 and IMAP4 users connectivity in Exchange 2013. Connections from POP3 or
IMAP4 client programs using NTLM will fail. If you're
running the RTM version of Exchange 2013, the
recommended alternative to NTLM is to use Plain Text
Authentication with SSL.
If you're using Exchange 2013, to use NTLM, you must
retain an Exchange 2007 server in your Exchange 2013
organization.

Outlook Web App and Outlook

FEATURE COMMENTS AND MITIGATION

Document access Outlook Web App can't be used to access Microsoft

SharePoint document libraries and Windows file shares.

Message flags The ability to set a custom date on a message flag isn't
available in Outlook Web App 2013. You can use Outlook
to set custom dates.

Spell check Outlook Web App uses the spell check features in your
Web browser.

Search Folders The ability for users to use Search folders isn't currently
available in Outlook Web App.

Maximum Cached Views Exchange 2007 supported modifying the maximum

number of cached views per database
(msExchMaxCachedViews) parameter for Outlook clients.
Exchange 2013 no longer uses this parameter.

Recipient-related features
FEATURE COMMENTS AND MITIGATION

Export-Mailbox and Import-Mailbox cmdlets In Exchange 2013, use export requests or import
requests. For more information, see Mailbox import and
export requests.

Move-Mailbox cmdlet set In Exchange 2013, use move requests to move mailboxes.
For information, see Mailbox moves in Exchange 2013.

ISInteg In Exchange 2013, use New-MailboxRepairRequest.

Messaging policy and compliance
FEATURE COMMENTS AND MITIGATION

Managed Folders In Exchange 2007, you use managed folders for

messaging retention management (MRM). In Exchange
2013, managed folders aren't supported. You must use
retention policies for MRM.

NOTE
Cmdlets related to managed folders are still available.
You can create managed folders, managed content
settings and managed folder mailbox policies, and
apply a managed folder mailbox policy to a user, but
the MRM assistant skips processing of mailboxes that
have a managed folder mailbox policy applied.

Unified Messaging and voice mail

FEATURE COMMENTS AND MITIGATION

Directory lookups using Automatic Speech Recognition In Exchange 2007, Outlook Voice Access users can use
(ASR) for Outlook Voice Access speech inputs using Automatic Speech Recognition (ASR)
in English (US) - (en-US) to search for users listed in the
directory. Speech inputs could be also used in Outlook
Voice Access to navigate menus, messages, and other
options. However, even if an Outlook Voice Access user is
able to use speech inputs, they have to use the telephone
key pad to enter their PIN, and navigate personal options.
In Exchange 2013, authenticated and non-authenticated
Outlook Voice Access users can't search for users in the
directory using speech inputs or ASR in any language.
However, callers that call into an auto attendant can use
speech inputs in multiple languages to navigate auto
attendant menus and search for users in the directory.
 What's new for Outlook Web App in Exchange 2013
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

For Microsoft Exchange Server 2013, we've added several new features to Microsoft Outlook Web App and
updated its design.

NOTE
For more details about using Outlook Web App in your Exchange Server 2013 organization, see Outlook Web App.
Outlook Web App users in your organization now have the ability to add public folders to, or remove them from, their
Favorites. Previously, this could only be done in Outlook.

Apps in Outlook Web App

We've added several apps for Outlook: Bing Maps, Suggested Appointments, and Action Items. These apps are
integrated with Outlook and Outlook Web App and extend the information and functionality of messages and
calendar items.
Apps in Outlook attempt to anticipate your needs and automatically propose actions you might want to take by
using the contents of the email message. For example, if an email message contains a street address, the Bing
Maps app offers you a Bing tab with a quick link to a map and directions. Or, if a phrase in the email message
suggests a possible action item, the Action Items app creates a suggested Task for your review. An offer to meet is
suggested as an Appointment to be added to your calendar, thanks to the Suggested Appointments app.
Apps for Outlook aren't dependent on the version of Exchange Server that you're using. You won't have to worry
about breaking or losing any apps for Outlook that you have added when you upgrade Exchange servers or move
to a new Exchange version.
Administrators can use the Exchange admin center (EAC ) to manage the apps available to users in the
organization. Users can then manage their apps. Administrators can also allow users to download apps from
Office.com. For more information about the EAC, see Exchange admin center in Exchange 2013.
In addition, we encourage third-party developers to create additional apps for Outlook and then offer them at
Office.com. To learn more, see Build Apps for Office for background information and Mail apps for Outlook for
detailed information about building apps for Outlook.

People
Now, users can link multiple entries for the same person and view the information in a single contact card.
For example, if a user has two entries for Holly Holt in his Contacts folder, one entry copied from the
organization's address list and one entry that he added manually, he can link the two entries in his Contacts
folder and view all the information in one place. Contact linking is done automatically, but the user can also
manually link and unlink contacts.
Connected accounts have been extended to include the ability to connect to a user's LinkedIn account. After
the link is established, Outlook Web App automatically adds the user's LinkedIn contacts to the Contacts
folder.

Calendar
 Users can now view multiple calendars in a merged view. Entries from each calendar have their own color,
making it easy for users to identify which calendar an entry belongs to. In the day view, users can view
multiple calendars in a merged view or in separate columns.
The month view now includes an agenda for the selected day, providing users with helpful information as
they review the day's activities.
In all calendar views, users can click an item to view a pop-up of the item's details. In addition to the details,
controls are now available to accept or decline the item if it's a meeting, to edit or delete if it's an
appointment, or, if a meeting item, to join the meeting if an online meeting link is included.

Tablets and smartphones

Outlook Web App emphasizes a streamlined user interface that also supports the use of touch, enhancing the
mobile device experience with Exchange.

Supported browsers
To experience all Outlook Web App features, use one of the operating system and browser combinations labeled
"Best", as noted in the tables below. Outlook Web App is supported by many operating system and web browser
combinations, but not all Outlook Web App features are available in all combinations. Some browsers support
only the light version of Outlook Web App.

Supported browsers on desktop and laptop computers

In the table below, the following definitions apply:
Best: All Outlook Web App features are supported.
Good: Most Outlook Web App features are supported.
Light: The browser displays the light version of Outlook Web App
Windows operating system and browser combination

Web browser Windows XP and Windows Vista Windows 7 Windows 8

Windows Server and Windows
2003 Server 2008

Internet Explorer Light Not available Not available Not available

7

Internet Explorer Light Good Good Not available

8

Internet Explorer Not available Best Best Not available

9

Internet Explorer Not available Not available Best - plus offline Best - plus offline
10 access access

Internet Explorer Not available Not available Best - plus offline Best - plus offline
11 access access
 Firefox 17 or later Good Good Best Best

Safari 5 or later Light Light Light Light

Chrome 24 or Good - plus Good - plus Best - plus offline Best - plus offline
later offline access offline access access access

NOTE
In previous versions, Outlook Web App had a built-in spell checker. In Exchange Server 2013, Outlook Web App relies on the
web browser for spell checking, which Internet Explorer prior to version 10 doesn't provide.

NOTE
Office 365 users will be limited to the light version of Outlook Web App when using Internet Explorer 8. Users whose
mailboxes are on a locally managed Exchange server will continue to see the standard version of Outlook Web App when
using Internet Explorer 8, but may experience slow or otherwise unsatisfactory performance.

Other Windows operating system and browser combination

Web browser Mac OS X v10.7 or later Linux

Firefox 23 or later versions Best - plus offline access Best - plus offline access

Safari 6 or later versions Best - plus offline access Not available

Chrome 24 or later versions Best - plus offline access Best - plus offline access

NOTE
Operating system and browser combinations not listed display the light version of Outlook Web App.

Supported browsers for tablets and smartphones

You can use the web browser on a tablet or smartphone to sign in to Outlook Web App. The available Outlook
Web App features depends on the operating system and browser combination in use, as follows:
Best: All Outlook Web App features for smartphones and tablets are supported.
Light: The browser displays the light version of Outlook Web App.
Outlook Web App features available on tablets and smartphones
 Device Application Support

Windows 8 tablet Web browser Best

iOS 6 or later for iPhone 4s or later Web browser Best

iOS 6 or later for iPad 2 or later Web browser Best

All other smartphones and tablets Web browser Light

OWA for Devices app

The OWA for Devices app lets users in an Exchange 2013 on-premises deployment with an Office 365 mailbox or
in an Office 365 only organization use their iPhone or iPad access their mailbox. The OWA for iPhone and OWA
for iPad apps simplify signing in to their mailbox and allows them access their mailbox even when they don't have
an Internet connection. The OWA for iPhone or OWA for iPad apps are recommended instead of using your
iPhone's or iPad's browser. For Exchange on-premises deployments, you need to enable push notifications for
OWA for Devices to work, see Configuring push notifications proxying for OWA for Devices.
You can download the OWA for iPhone and OWA for iPad apps from the Apple App Store by searching for OWA
for iPhone or OWA for iPad or download them from OWA for iPhone in the Apple Store or OWA for iPad in the
Apple Store. The table below shows the versions of iPad and iPhone that are supported.
To learn more about OWA for iPhone and OWA for iPad, see OWA for iPhone and OWA for iPad.

Device OS version required

iPhone 4S, iPhone 5, iPhone 5c or iPhone 5s. This app is iOS 6 or later versions
optimized for iPhone 5.

iPad Wi-Fi (3rd generation), iPad Wi-Fi + Cellular (3rd iOS 6 or later versions
generation), iPad Wi-Fi (4th generation), iPad Wi-Fi +
Cellular (4th generation), iPad mini Wi-Fi, iPad mini Wi-Fi
+ Cellular, iPad Air, iPad Air Wi-Fi + Cellular, iPad mini
with Retina display, iPad mini with Retina display Wi-Fi +
Cellular

OWA for Android

OWA for Android lets you interact with your Office 365 mailbox to get to your email, Calendar, and People from
anywhere using your Android phone running Kit Kat 4.4 or higher. You can download the OWA for Android app at
the Google Play Store
With the OWA for Android app, you can:
Get, organize, search your email.
Schedule meetings, locate rooms, see shared calendars and use your voice to get your schedule.
Sync People with your phone.
 Skip the administrator phone setup.
Keep your Office 365 business data secure.
Use the Remote Wipe feature.
Learn more about the background behind OWA for Android on this week's Garage Series. See The Garage Series
Under the Hood: Evolving Exchange ActiveSync and OWA for Devices

NOTE
This app won't work with Outlook.com (formerly Hotmail) mailboxes.

Unavailable features
The following Outlook Web App features are currently unavailable in Exchange 2013. Some of these features may
be included in a future release.
Search scope: The ability for Outlook Web App users to search their primary mailbox and their online
archive simultaneously is no longer available in Exchange 2013. To search an online archive, users must
first navigate to the archive and then conduct their search.
Distribution list moderation: The ability to moderate distribution lists from Microsoft Outlook Web App
isn't currently available in Exchange 2013.
Custom date on message flags: The ability to set a custom date on a message flag isn't available in
Outlook Web App 2013. You can use Outlook to set custom dates.
Reading pane at the bottom of the window: The option to display the reading pane at the bottom of the
Outlook Web App window isn't currently available in Exchange 2013.
Reply to embedded email messages: The ability for users to reply to email messages sent as
attachments isn't currently available in Exchange 2013.
Search folders: The ability for users to use Search folders isn't currently available in Exchange 2013.
Access to legacy public folders: The ability for users to access public folders located on servers running
previous versions of Exchange isn't currently available in Exchange 2013.
Show Recovery option: The ability for users to work with recovery passwords for their mobile devices
with Outlook Web App isn't currently available in Exchange 2013.
 What's new for Unified Messaging in Exchange 2013
5/28/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, we're enhancing earlier releases of Exchange by introducing new features and
architectural changes. Unified Messaging (UM ) in Exchange 2013 includes the same feature set as Exchange 2010
and Exchange 2007, however Unified Messaging is no longer a separate server role. It's now a component of the
voice-related features offered in Exchange 2013.

Changes in the Voice architecture

The architecture of Exchange 2013 is different than it was in Exchange 2010 and Exchange 2007. In previous
versions of Exchange UM, all the components for Unified Messaging were included on a server that had the UM
server role installed. In Exchange 2013, all the Unified Messaging components are split between a Client Access
server running the Microsoft Exchange Unified Messaging Call Router service and a Mailbox server running the
Microsoft Exchange Unified Messaging service. All the functionality, including the services and worker processes
for Unified Messaging, is located on each Mailbox server, with the exception of the Client Access server running
the Microsoft Exchange Unified Messaging Call Router service, which proxies incoming calls to the Mailbox server.
For details, see Voice architecture changes.

Support for IPv6

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol. IPv6 is intended to correct
many of the shortcomings of IPv4, which was the previous version of the IP. As in Exchange 2010, Exchange 2013
Client Access and Mailbox servers fully support IPv6 networks. For details, see IPv6 support in Unified Messaging.

Support for UCMA 4.0 API

Since Service Pack 1 for Exchange 2010, the Unified Messaging role has relied on Unified Communications
Managed API v2.0 (UCMA) for signaling and media. Therefore, UCMA 2.0 is a prerequisite for Exchange 2010 UM
setup. UCMA 2.0 is downloaded separately and deployed manually by administrators on Unified Messaging
servers running Exchange 2010 SP1 or a later version. For Exchange 2013, UCMA 4.0 is required. However, given
that the UM server is no longer a separate server role in Exchange 2013, now it's the Client Access and Mailbox
servers that require UCMA 4.0.
UCMA 4.0 supports new features in Unified Messaging, such as using the same version of the Speech Engine for
both Text-to-Speech (TTS ) and Automatic Speech Recognition (ASR ). The platform that's used for Exchange 2013,
.NET 4.0, includes a single installer file and enables backward compatibility with Exchange 2010 and Exchange
2007 UM servers.
In Exchange 2010 SP2 and SP1, UCMA 2.0 installation is required prior to installing the service pack on a Unified
Messaging server. However, UCMA 2.0 had several limitations. UCMA 4.0 corrects many of the shortcomings. In
Exchange Server 2013, UM continues to use UCMA. However, the move to the newest version of UCMA provides
these benefits:
The newest build of UCMA incorporates hotfixes and patches.
UCMA requires .NET 4.0, which is the platform used by Exchange Server 2013. (UCMA 2.0 doesn't support
.NET 4.0.)
UCMA 4.0 supports IPv6.
 Simplified and automated deployment of UCMA 4.0. Exchange 2013 Setup performs a single check for
UCMA 4.0.
UCMA 4.0 setup includes all prerequisites for Exchange 2013.

NOTE
UCMA 4.0 is installed when you're installing Exchange 2013. For details about UCMA 4.0 and setup requirements, see
Exchange 2013 prerequisites. To upgrade to the most recent version of UCMA, you must first uninstall any previous versions
of UCMA that are installed using Add/Remove programs.

Improvements to Voice Mail Preview

Some enhancements to the speech-related services are offered for Exchange Server 2013 UM via the Speech
Engine 11.0 and UCMA 4.0. Grammar generation and language improvements are included. In addition, Exchange
Server 2013 UM includes several enhancements to the UI and improvements for confidence and accuracy for
Voice Mail Preview. For details, see Voice mail preview enhancements.

Enhanced caller ID support

In previous releases of Exchange Unified Messaging, a UM server that took a call used caller ID to try to look up
the identity of the calling party. This search extended across Active Directory and the UM user's personal contacts
stored in their mailbox.
Exchange users are often annoyed by failures to identify Exchange or personal contacts from their caller ID. Until
now, only the default contact folder in Exchange UM was used for this search. But Exchange Server 2013 users are
likely to have contacts aggregated from external social networks or contacts in unique folders that the users have
created manually. Exchange 2013 supports contact aggregation from external social networks, provides
intelligence to link multiple contacts referring to the same person, and uses that data to present person-centric
(rather than contact-centric) views. The contacts that are aggregated from external networks are placed in contact
folders along with any additional contact folders that users created.The features in Exchange 2013 UM extend the
scope of the search to include the user's other Exchange and personal contact folders that were created manually.
Caller ID look-up is integrated with contact aggregation, so that it searches across external contacts. The PersonID
property, where present and with a non-null value, improves the user experience for caller ID resolution by
suppressing duplicate matches to contacts that are associated with the same person. Because the PersonID
property is the same on both results, UM treats this as a match to a single contact.

Enhancements to speech platform and speech recognition

Exchange Server 2013 UM introduces some enhancements to the speech platform and speech recognition,
including the following:
Enhancements and improved accuracy for Voice Mail Preview.
Support for the Microsoft Speech Platform - Runtime (Version 11.0).
Speech grammar generation using the system mailbox for an organization.
Exchange Unified Messaging uses static and dynamic speech grammars to recognize commands, names of
contacts in the global address list, and names of personal contacts in the user's mailbox. Today, in Exchange Server
2013, every Mailbox server running the Microsoft Exchange Unified Messaging service generates grammars for
all UM languages installed on it and stores them in directories. Every Mailbox server stores every possible
grammar, which it generates based on the number of dial plans, auto attendants, and the UM languages that are
installed.
Grammar files are used as inputs to the speech recognition process and are generated on a periodic basis. The
GGG.exe command in Exchange 2007 and Exchange 2010 allowed you to manually update the grammar files
without waiting for the scheduled update. In Exchange Server 2013, to address ASR grammar-generation
scalability issues for UM, the speech GAL grammar generation no longer happens on the server with the Unified
Messaging server role installed. Instead, it happens periodically using the Mailbox Assistant, on the Mailbox server
running the Microsoft Exchange Unified Messaging service that hosts the organization's arbitration mailbox. The
GAL speech grammar file is stored in the arbitration mailbox for an organization and then later downloaded to all
Mailbox servers in that Exchange organization. By default, the Mailbox Assistant runs every 24 hours. You can
adjust the frequency by using the Set-MailboxServer cmdlet.

Cmdlet updates
For Exchange 2013, many UM cmdlets have been brought over from Exchange 2010, but there have been changes
in some of those cmdlets, and new cmdlets have been added for new functionality. For details, see Unified
Messaging cmdlet updates.
 What's new for transport rules
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, several improvements have been made to transport rules. This topic provides
a brief overview of some of the key changes and enhancements. To learn more about transport rules, see Mail flow
or transport rules.

Support for data loss prevention policies

Data loss prevention (DLP ) features in Exchange 2013 can help organizations reduce unintentional disclosure of
sensitive data. Transport rules have been updated to support creating rules that accompany and enforce DLP
policies. To learn more about DLP support in transport rules, see the following topics:
Integrating sensitive information rules with transport rules
Data loss prevention

New predicates and actions

The functionality of transport rules has been extended via the addition of new predicates and actions. Each
predicate listed below can be used as a condition or an exception when you're creating transport rules.
For detailed information about using these new predicates and actions, see Transport rule conditions (predicates)
and Transport rule actions.

New predicates
AttachmentExtensionMatchesWords: Used to detect messages that contain attachments with specific
extensions.
AttachmentHasExecutableContent: Used to detect messages that contain attachments with executable
content.
HasSenderOverride: Used to detect messages where the sender has chosen to override a DLP policy
restriction.
MessageContainsDataClassifications: Used to detect sensitive information in the message body and any
of the attachments. For a list of data classifications available, see What the sensitive information types in
Exchange look for.
MessageSizeOver: Used to detect messages whose overall size is greater than or equal to the specified
limit.
SenderIPRanges: Used to detect messages sent from a specific set of IP address ranges.

New actions
GenerateIncidentReport: Generates an incident report that is sent to a specified SMTP address. The
action also has a parameter called IncidentReportOriginalMail that accepts one of two values:
IncludeOriginalMail or DoNotIncludeOriginalMail.
NotifySender: Controls how the sender of a message that goes against a DLP policy is notified. You can
 choose to simply inform the sender and route the message normally, or you can choose to reject the
message and notify the sender.
StopRuleProcessing: Stops the processing of all subsequent rules on the message.
ReportSeverityLevel: Sets the specified severity level in the incident report. Values for the action are:
Informational, Low, Medium, High, and Off.
RouteMessageOutboundRequireTLS: Requires Transport Layer Security (TLS ) encryption when routing
this message outside your organization. If TLS encryption isn't supported, the message is rejected and not
delivered.

Other changes in Transport rules

Support for extended regular expression syntax: Transport rules in Exchange 2013 are based on the
Microsoft.NET Framework regular expression (regex) functionality and now support extended regular
expression syntax.
Transport rules agent invocation: The key architectural change in Exchange 2013 for Transport rules is
the Transport Rules Agent is invoked on onResolvedMessage. In previous versions of Exchange, the Rules
Agent was invoked on onRoutedMessage. This change allowed us to add new actions, such as requiring
TLS, which can change how a message is routed. To learn more about the transport rules architecture in
Exchange 2013, see Mail flow or transport rules.
Detailed Transport rule information in message tracking logs: Detailed information about Transport
rules is now included in message tracking logs. The information includes which rules were triggered for a
specific message and the actions taken as a result of processing those rules.
New rule monitoring functionality: Exchange 2013 monitors Transport rules that are configured and
measures the cost of running these rules both when you're creating the rule and also during regular
operation. Exchange can detect and generate alerts for rules that are causing delays in mail delivery.
 Release notes for Exchange 2013
6/14/2019 • 12 minutes to read • Edit Online

Applies to: Exchange Server 2013

Welcome to Microsoft Exchange Server 2013! This topic contains important information that you need to know
to successfully deploy Exchange 2013. Please read this topic completely before beginning your deployment.
This topic contains the following sections:
Setup and deployment
Exchange Management Shell
Mailbox
Public folders
Mail flow
Client connectivity
Exchange 2010 coexistence

Setup and deployment

msExchProductId doesn't reflect release version of Exchange 2013 installed After Exchange
extends your Active Directory schema and prepares Active Directory for Exchange, several properties are
updated to show that preparation is complete. One of these properties is msExchangeProductId under the
CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> container in
the Configuration naming context. If no Active Directory schema changes are introduced in the release of
Exchange 2013 you're installing, this property won't be updated or may show an unexpected value. This
could cause confusion if the value doesn't match the version of Exchange 2013 being installed.
This behavior is expected as the value of msExchProductId doesn't reflect the version of Exchange 2013
being installed. This property reflects the version of Exchange 2013 that last made changes to the Active
Directory schema. To avoid confusion, we recommend that you follow the steps in the How do you know
this worked? section of Prepare Active Directory and domains to verify that your Active Directory has
been updated and is ready for the release of Exchange 2013 you're installing.
Setup incorrectly requests .NET Framework 4.0: If you try to install Exchange 2013 without .NET
Framework installed on the computer, Setup incorrectly requests that you install .NET Framework 4.0
when, in fact, .NET Framework 4.5 or later is required.
To work around this issue, install .NET Framework 4.5 or later. You don't need to install .NET Framework
4.0. For a complete list of prerequisites, see Exchange 2013 prerequisites.
Exchange XML application configuration files are overwritten during cumulative update
installation: Any customized Exchange or Internet Information Server per-server settings you make in
Exchange XML application configuration files, for example, web.config files on Client Access servers or the
EdgeTransport.exe.config file on Mailbox servers, will be overwritten when you install an Exchange
Cumulative Update or Service Pack. Make sure that you save this information so you can easily re-
configure your server after the install. You must re-configure these settings after you install an Exchange
Cumulative Update or Service Pack.
 Installing Exchange using Delegate Admin permissions causes Setup to fail When a user who's a
member of only the Delegated Setup role group attempts to install Exchange on a pre-provisioned server,
Setup will fail. This happens because the Delegated Setup group lacks the permissions required to create
and configure certain objects in Active Directory.
To work around this issue, do one of the following:
Add the user installing Exchange to the Domain Admins Active Directory security group.
Install Exchange using a user that's a member of the Organization Management role group.
For more information about how to install Exchange 2013, see Planning and deployment.

Exchange Management Shell

The Shell unexpectedly loads Exchange 2007 or Exchange 2010 cmdlets Previously, opening the
Shell on an Exchange 2013 server would result in the Shell opening a connection to the local server or
another server running Exchange 2013. When the connection is made, Exchange 2013 cmdlets are loaded.
Starting with Exchange 2013 CU11, the Shell will connect to the Exchange server where the logged on
user's mailbox is located. If the logged on user doesn't have a mailbox, the Shell will connect to the server
where the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} arbitration mailbox is located. The
target server can be any supported version of Exchange. This means if the logged on user's mailbox (or
the arbitration mailbox if the user has no mailbox) is located on an Exchange 2010 server, the Shell will
connect to that server and load Exchange 2010 cmdlets. This may prevent you from performing certain
tasks because Exchange 2010 cmdlets can't manage Exchange 2013 configuration or servers.
Starting with Exchange 2013 CU11, this behavior is by design. To make sure the Shell loads Exchange
2013 cmdlets, move the logged on user's mailbox to Exchange 2013. If the logged on user doesn't have a
mailbox, move the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} arbitration mailbox to an
Exchange 2013 server.
For details and information on how to move the arbitration mailbox, see Exchange Management Shell and
Mailbox Anchoring on the Exchange Team blog.

Mailbox
Mailbox servers running different versions of Exchange can be added to the same database
availability group The Add-DatabaseAvailabilityGroupServer cmdlet and the Exchange admin
center incorrectly allow an Exchange 2013 server to be added to an Exchange 2016-based database
availability group (DAG ), and vice versa. Exchange supports adding only Mailbox servers running the
same version (Exchange 2013 versus Exchange 2016, for example) to a DAG. Additionally, the Exchange
admin center displays both Exchange 2013 and Exchange 2016 servers in the list of servers available to
add to a DAG. This could allow an administrator to inadvertently add a server running an incompatible
version of Exchange to a DAG (for example, adding an Exchange 2013 server to an Exchange 2016-based
DAG ).
There is currently no workaround for this issue. Administrators must be diligent when adding a Mailbox
server to a DAG. Add only Exchange 2013 servers to Exchange 2013-based DAGs, and only Exchange
2016 servers to Exchange 2016-based DAGs. You can differentiate each version of Exchange by looking at
the Version column in the list of servers in the Exchange admin center. The following are the server
versions for Exchange 2013 and Exchange 2016:
Exchange 2013 15.0 (Build xxx.xx)
Exchange 2016 15.1 (Build xxx.xx)
Mailbox size increase when migrating from previous Exchange versions: When you move a
 mailbox from a previous version of Exchange to Exchange 2013, the mailbox size reported may increase
30 percent to 40 percent. Disk space used by the mailbox database has not increased, only the attribution
of space used by each mailbox has increased. The increase in mailbox size is due to the inclusion of all
item properties into quota calculations, providing a more accurate computation of space consumed by
items within their mailbox. This increase may cause some users to exceed their mailbox size quotas when
their mailbox is moved to Exchange 2013.
To prevent users from exceeding their mailbox size quotas, increase the database or mailbox quota values
to accommodate the new quota calculation. To configure database or mailbox quota values, use the
IssueWarningQuota, ProhibitSendQuota, and ProhibitSendReceiveQuota parameters on the Set-
MailboxDatabase and Set-Mailbox cmdlets, respectively.
Outlook 2007 and Outlook 2010 clients may be unable to download the Offline Address Book: If
the Offline Address Book (OAB ) internal URL isn't accessible from the Internet, Outlook 2007 and
Outlook 2010 clients may be unable to download the OAB.
To work around this issue for Outlook 2007 and Outlook 2010 clients, make the OAB internal URL
accessible from the Internet. Outlook 2013 isn't affected by this issue.
Installing Exchange 2013 in an existing Exchange organization may cause all clients to
download the OAB: Installing the first Exchange 2013 server into an existing Exchange 2007 or
Exchange 2010 organization may cause all clients in the organization to download a new copy of the OAB,
resulting in network saturation and server performance issues. This issue occurs because Exchange 2013
creates a new default OAB in the organization that supersedes the Exchange 2007 or Exchange 2010 OAB.
Mailboxes that don't have a specific OAB assigned, or that are located on a mailbox database that doesn't
have a specific OAB assigned, will download the new default OAB.
To prevent clients from downloading a new copy of the OAB when Exchange 2013 is installed, assign an
OAB to every mailbox or to the mailbox database the mailboxes are located on. This must be done prior to
Exchange 2013 being installed in the organization.
Users may be routed to an OAB generation mailbox that's not responsible for the requested
OAB: Exchange 2013 CU5 and later CUs have changed how OABs are linked to OAB generation
mailboxes. This change makes it possible for a user to be routed to an OAB generation mailbox that isn't
responsible for the OAB that the user is requesting. This can happen if all of the following are true:
You have more than one OAB generation mailbox in your organization.
You upgrade the Mailbox servers that host OAB generation mailboxes before you upgrade your
Client Access servers.
You're upgrading your Exchange 2013 servers from a release prior to CU5 to a later release (for
example, upgrading from Exchange 2013 CU3 to Exchange 2013 CU6).
Your Client Access servers are running a release prior to CU5.
To work around this issue, make sure that you upgrade your Client Access servers to Exchange 2013 CU6
or later before you upgrade your Mailbox servers. This will make sure the Client Access servers know how
to proxy the requests to the OAB generation mailbox that is responsible for generating the user's OAB.
To read more about the OAB changes in Exchange 2013 CU5, see OAB Improvements in Exchange 2013
Cumulative Update 5.

Public folders
Unauthorized senders can no longer send messages to mail-enabled public folders: Prior to
Exchange 2013 CU6, unauthorized senders could send messages to mail-enabled public folders. This
 allowed the possibility for external senders to send mail to mail-enabled public folders regardless of the
permissions set on the public folder.
Starting with Exchange 2013 CU6, if you want external senders to send mail to a mail-enabled public
folders, the Anonymous user needs to be granted at least the Create Items permission. If you've set up
mail-enabled public folders and haven't done this, external senders will receive a delivery failure
notification and the messages won't be delivered to the mail-enabled public folder.
You can use the Shell or Outlook to set the permissions on the Anonymous user. To read more about how
to set permissions on the Anonymous user, see Mail-enable or mail-disable a public folder.
The maximum number of public folders that can be migrated to Exchange 2013 from legacy Exchange
servers is 500,000. For more information about public folder migration, see Use batch migration to
migrate public folders to Exchange 2013 from previous versions.

Mail flow
TransportAgent cmdlets on Client Access servers require local Windows PowerShell: An issue
exists with the *-TransportAgent cmdlets that prevents those cmdlets from installing, uninstalling, and
managing transport agents on Client Access servers using the Exchange Management Shell. To install,
uninstall, and manage transport agents on Client Access servers, you must manually load the
Exchange Windows PowerShell snap-in and then run the *-TransportAgent cmdlets. If you attempt to
install, uninstall, or manage transport agents using the Exchange Management Shell, your changes will be
applied to the Exchange 2013 Mailbox server you're connected to.
To install, uninstall, or manage transport agents on Client Access servers, do the following on the Client
Access server you want to manage:

WARNING
Loading the Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell snap-in and running
cmdlets other than the *-TransportAgent cmdlets is not supported and may result in irreparable damage to your
Exchange deployment.
You must be a local Administrator on the Client Access server where you want to install, uninstall, or manage
transport agents. We do not support the modification of access control lists (ACLs) on Exchange files, directories, or
Active Directory objects.

IMPORTANT
Perform the following procedure on Client Access servers only. You don't need to load the Exchange Windows
PowerShell snap-in if you want to manage transport agents on Mailbox servers.

1. Open a new Windows PowerShell window.

2. Run the following command.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

3. Perform transport agent management tasks as normal.

4. Repeat this procedure on each Client Access server you want to manage.

Client connectivity
NTLM authentication fails for non-domain joined clients: Authentication between a client, such as
Windows Live Mail, and Exchange 2013 may fail when the following conditions are true:
Then authentication method the client uses is NTLM.
The computer isn't joined to the domain.
To work around this issue, you can do one of the following:
Join the computer the client is running on to the domain.
Change the authentication type the client uses from NTLM to Basic Auth over TLS.
GSSAPI authentication fails when used with the Send-MailMessage cmdlet: Generic Security
Service Application Program Interface (GSSAPI) authentication may fail when the Send-MailMessage
cmdlet, which is included with default installs of Windows PowerShell, is used to send authenticated mail
to Exchange 2013. When this happens, you'll see an entry in the Application event log on the Exchange
2013 Client Access server that received the connection with the following information:
Source: MSExchangeFrontEndTransport
Event ID: 1035
Description: Inbound authentication failed with error IllegalMessage for Receive connector Client
Frontend <server name>. The authentication mechanism is Gssapi. The source IP address of the
client who tried to authenticate to Exchange is [<client IP address>].
To work around this issue, you need to remove the Integrated authentication method from the client
receive connector on your Exchange 2013 Client Access servers. To remove the Integrated
authentication method from a client receive connector, run the following command on each Exchange
2013 Client Access server that could receive connections from computers running the Send-
MailMessage cmdlet:

Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth,

BasicAuthRequireTLS

MAPI over HTTP may experience poor performance when you upgrade to Exchange 2013 SP1: If
you upgrade from an Exchange 2013 cumulative update to Exchange 2013 SP1 and enable MAPI over
HTTP, clients that connect to an Exchange 2013 SP1 server using the protocol may experience poor
performance. This is because required settings aren't configured during an upgrade from a cumulative
update to Exchange 2013 SP1. This issue doesn't occur if you upgrade to Exchange 2013 SP1 from
Exchange 2013 RTM or if you install a new Exchange 2013 SP1 or later server.

NOTE
This is only an issue if the MAPI over HTTP protocol is enabled on your Client Access servers. It's disabled by
default. If MAPI over HTTP is disabled, clients use the RPC over HTTP protocol instead.

To work around this issue, do the following:

1. On servers running the Client Access server role, run the following commands in a Windows
Command Prompt:
 set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool"

/CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"

2. On servers running the Mailbox server role, run the following commands in a Windows Command
Prompt:

set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool"

/CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool"

/CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"

Exchange 2010 coexistence

Requests to access Exchange 2010 mailboxes may not work when proxied through Exchange
2013 Client Access servers: In some situations, the proxy request between the Exchange 2013 and
Exchange 2010 Service Pack 3 (SP3) Client Access servers without any update rollups installed may not
work correctly and an error appears. This can happen if all of the following conditions are true:
A user with an Exchange 2013 mailbox tries to open an Exchange 2010 mailbox using one of the
following methods:
The Open Another Mailbox option in Outlook Web App -OR-
The Another user option in the Exchange admin center
The Client Access server the user connected to is running Exchange 2013.
The Exchange 2010 Client Access server was upgraded to Exchange 2010 SP3 from the release to
manufacturing (RTM ) version of Exchange 2010 or a previous Exchange 2010 service pack.
If all the conditions above are true, the user won't be able to access the other user's Exchange
2010 Outlook Web App options and a blank page may appear.
To work around this issue, install Exchange 2010 SP3 Update Rollup 1 or later on each Exchange 2010
server.
 Updates for Exchange 2013
6/28/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

Learn how the update process for Microsoft Exchange Server 2013 has changed. This article also provides links
to information about the features and improvements that were included in current, and previous, releases of
Exchange 2013.
With Microsoft Exchange Server 2013, we changed the way we deliver hotfixes and service packs. Instead of the
priority-driven hotfix release and rollup update model used by previous versions of Microsoft Exchange,
Exchange 2013 now follows a scheduled delivery model. In this model, cumulative updates (CU ), which address
customer-reported issues and may include new functionality and/or features, are released quarterly. Critical
product updates, which are packages that address a Microsoft-released security bulletin or contain a change in
time zone definitions, are released as needed on a monthly basis for the most recently released CU and the
immediately previous CU.
To get the latest version of Exchange 2013, download and install Microsoft Exchange Server 2013 Cumulative
Update 21. Because each CU is a full installation of Exchange and includes updates and changes from all previous
CU's, you don't need to install any previous CU's or service packs first.
For more information about updates as they relate to Exchange 2013, including an extensive FAQ, see Servicing
Exchange 2013 and "Servicing Model Update" in Released: Exchange Server 2013 Cumulative Update 2.
The following table contains links to Exchange Team blog posts ("What's New" information) for this and other
Exchange 2013 CUs.
For information on how to upgrade to the latest CU after you've downloaded it, see Upgrade Exchange
2013 to the latest cumulative update or service pack.
For information about the new features you'll get when you upgrade to Exchange 2013 from previous
versions of Exchange, see What's new in Exchange 2013.
For downloads and updates for other versions of Exchange, see Exchange Server Updates: build numbers
and release dates.

VERSION BLOG PST

Exchange 2013 CU23 Released: June 2019 Quarterly Exchange Updates

Exchange 2013 CU22 Released: February 2019 Quarterly Exchange Updates

Exchange 2013 CU21 Released: June 2018 Quarterly Exchange Updates

Exchange 2013 CU20 Released: March 2018 Quarterly Exchange Updates

Exchange 2013 CU19 Released: December 2017 Quarterly Exchange Updates

Exchange 2013 CU18 Released: September 2017 Quarterly Exchange Updates

Exchange 2013 CU17 Released: June 2017 Quarterly Exchange Updates

 VERSION BLOG PST

Exchange 2013 CU16 Released: March 2017 Quarterly Exchange Updates

Exchange 2013 CU15 Released: December 2016 Quarterly Exchange Updates

Exchange 2013 CU14 Released: September 2016 Quarterly Exchange Updates

Exchange 2013 CU13 Released: June 2016 Quarterly Exchange Updates

Exchange 2013 CU12 Released: March 2016 Quarterly Exchange Updates

Exchange 2013 CU11 Released: December 2015 Quarterly Exchange Updates

Exchange 2013 CU10 Released: September 2015 Quarterly Exchange Updates

Exchange 2013 CU9 Released: June 2015 Exchange Cumulative Update and
Update Rollups

Exchange 2013 CU8 Released: Exchange Server 2013 Cumulative Update 8

Exchange 2013 CU7 Released: Exchange Server 2013 Cumulative Update 7

OAB Improvements in Exchange 2013 Cumulative Update 7

Exchange 2013 CU6 Released: Exchange Server 2013 Cumulative Update 6

Public Folder Updates in Exchange 2013 CU6: Improving

Scale and More

Exchange 2013 CU5 Released: Exchange Server 2013 Cumulative Update 5

Exchange 2013 SP1 Released: Exchange Server 2013 Service Pack 1

Exchange 2013 CU3 Released: Exchange Server 2013 Cumulative Update 3

Exchange 2013 CU2 Released: Exchange Server 2013 Cumulative Update 2

Exchange 2013 CU1 Released: Exchange Server 2013 Cumulative Update 1

Exchange 2013 RTM What's new in Exchange 2013

Exchange Server 2013 Reaches General Availability

New features, improvements, and updates included in Exchange 2013

SP1
Windows Server 2012 R2 support
Windows Server 2012 R2 is now a supported operating system in Exchange 2013 SP1. Exchange 2013 SP1 also
supports installation in Active Directory environments running Windows Server 2012 R2. For more information,
see Exchange 2013 system requirements.
Edge Transport servers return
Edge Transport servers minimize attack surface by handling all Internet-facing mail flow, which provides SMTP
relay and smart host services for your Exchange organization, including connection filtering, attachment filtering
and address rewriting. For more information, see Edge Transport servers.
OWA Junk Email Reporting
Outlook Web App customers can report missed spam in the inbox (false negative) and misclassified as spam
(false positive) messages to Microsoft for analysis by using its built-in junk email reporting options. Depending
on the results of the analysis, we can then adjust the anti-spam filter rules for our Exchange Online Protection
(EOP ) service. For more information, see Report junk email and phishing scams in Outlook on the web.
S/MIME for Message Signing and Encryption
Exchange 2013 SP1 now supports S/MIME -based message security with Outlook Web App.
Secure/Multipurpose Internet Mail Extensions (S/MIME ) allows people to help protect sensitive information by
sending signed and encrypted email within their organization. Administrators can enable S/MIME for mailboxes
by synchronizing user certificates and then configuring Outlook Web App to support S/MIME. For more
information, see S/MIME for message signing and encryption and the Get-SmimeConfig cmdlet reference.
DLP Policy Tips available in the desktop and mobile version of Outlook Web App
Data loss prevention (DLP ) Policy Tips are informative notices that are displayed to senders in Outlook when
they try sending sensitive information. In Exchange 2013 SP1, this functionality has been extended to both the
desktop version of Outlook Web App and the mobile version (named OWA for Devices). You'll see it in action if
you have an existing DLP policy with Policy Tips turned on for Outlook. If your policy already includes Policy Tips
for Outlook, you don't need to set up anything else. Go ahead and try it out!
Not currently using Policy Tips? To get started, Create a DLP policy from a template, then add a policy tip by
editing the policy and adding a Notify the sender with a Policy Tip action.
DLP Classification based on Document Fingerprints
Deep content analysis is a cornerstone of DLP in Exchange. Document Fingerprinting expands this capability to
enable you to identify standard forms used in your organization, which may contain sensitive information. For
example, you can create a fingerprint based off a blank employee information form, and then detect all employee
information forms with sensitive content filled in.
DLP sensitive information types for new regions
Exchange 2013 SP1 provides an expanded set of standard DLP sensitive information types covering an increased
set of regions, which makes it easier to start using the DLP features. Exchange 2013 SP1 adds region support for
Poland, Finland and Taiwan. To learn more about the new DLP sensitive information types, see What the sensitive
information types in Exchange look for.
Using AD FS claims-based authentication with Outlook Web App and ECP
Deploying and configuring Active Directory Federation Services (AD FS ) using claims means multifactor
authentication can be used with Exchange 2013 SP1 including supporting smartcard and certificate-based
authentication in Outlook Web App. In a nutshell, to implement AD FS to support multifactor authentication:
Install and configure Windows Server 2012 R2 AD FS (this is the most current version of AD FS and
contains additional support for multifactor authentication). To learn more about setting up AD FS, see
Active Directory Federation Services (AD FS ) Overview
Create relying party trusts and the required AD FS claims.
Publish Outlook Web App through Web Application Proxy (WAP ) on Windows Server 2012 R2.
Configure Exchange 2013 to use AD FS authentication.
Configure the Outlook Web App virtual directory to use only AD FS authentication. All other methods of
authentication should be disabled.
 Restart Internet Information Services on each Client Access server to load the configuration.
For details, see Using AD FS claims-based authentication with Outlook Web App and EAC
SSL Offloading support
SSL offloading is supported for all of the protocols and related services on Exchange 2013 Client Access servers.
By enabling SSL offloading, you terminate the incoming SSL connections on a hardware load balancer instead of
on the Client Access servers. Using SSL offloading moves the SSL workloads that are CPU and memory
intensive from the Client Access server to a hardware load balancer.
SSL offloading is supported with following protocols and services:
Outlook Web App
Exchange admin center (EAC )
Outlook Anywhere
Offline Address Book (OAB )
Exchange ActiveSync (EAS )
Exchange Web Services (EWS )
Autodiscover
MAPI virtual directory for Outlook clients
If you have multiple Client Access servers, each Client Access server in your organization must be configured
identically. You need to perform the required steps for each protocol or service on every Client Access server in
your on-premises organization. For details, see Configuring SSL offloading in Exchange 2013
Public Attachment Handling in Exchange Online
Although there are both private (internal network) and public (external network) settings to control attachments
using Outlook Web App mailbox policies, admins require more consistent and reliable attachment handling when
a user signs in to Outlook Web App from a computer on a public network such as at a coffee shop or library. Go
here for details, Public Attachment Handling in Exchange Online.
Browser Support for AppCache
Internet Explorer 10 and Windows Store apps using JavaScript support the Application Cache API (or
AppCache), as defined in the HTML5 specification, which allows you to create offline web applications. AppCache
enables webpages to cache (or save) resources locally, including images, script libraries, style sheets, and so on. In
addition, AppCache allows URLs to be served from cached content using standard Uniform Resource Identifier
(URI) notation. The following is a list of the browsers that support AppCache:
Internet Explorer 10 or later versions
Google Chrome 24 or later versions
Firefox 23 or later versions
Safari 6 or later (only on OS X/iOS ) versions
Exchange OAuth authentication protocol
Information workers in Exchange on-premises organizations need to collaborate with information workers in
Exchange Online organizations when they are connected via an Exchange hybrid deployment. New in Exchange
2013 SP1, this connection can now be enabled and enhanced by using the new Exchange OAuth authentication
protocol. The new Exchange OAuth authentication process will replace the Exchange federation trust
configuration process and currently enables the following Exchange features:
 Exchange hybrid deployment features, such as shared free/busy calendar information, MailTips, and
Message Tracking.
Exchange In-place eDiscovery
For more information, see Configure OAuth authentication between Exchange and Exchange Online
organizations.
Hybrid deployments with multiple Active Directory forests
New in Exchange 2013 SP1, hybrid deployments are now supported in organizations with multiple Active
Directory forests. For hybrid deployment features and considerations, multi-forest organizations are defined as
organizations having Exchange servers deployed in multiple Active Directory forests. Organizations that utilize a
resource forest for user accounts, but maintain all Exchange servers in a single forest, aren't classified as multi-
forest in hybrid deployment scenarios. These types of organizations should consider themselves a single forest
organization when planning and configuring a hybrid deployment.
For more information, see Hybrid deployments with multiple Active Directory forests.
Database Availability Group without an Administrative Access Point
Windows Server 2012 R2 enables you to create a failover cluster without an administrative access point.
Exchange 2013 SP1 introduces the ability to leverage this capability and create a database availability group
(DAG ) without a cluster administrative access point. Creating a DAG without an administrative access point
reduces complexity and simplifies DAG management. In addition, it reduces the attack surface of a DAG by
removing the cluster/DAG name from DNS, thereby making it unresolvable over the network.
For more information, see High availability and site resilience.
UM Language Packs
The UM language packs for Exchange 2013 SP1 are available. If you install SP1 on your Mailbox servers, you
must install the Exchange 2013 SP1 UM language packs. See Exchange Server 2013 SP1 UM Language Packs to
download them. UM language packs are specific to the version of Exchange and the Service Pack (SP ) installed.
 Planning and deployment
6/11/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Do you need guidance doing an Exchange install? This article provides guidance for planning a deployment of
Microsoft Exchange Server 2013 as well as links to articles that you'll need during deployment.
The following sections contain links to information about planning for and then deploying Microsoft Exchange
Server 2013.

IMPORTANT
Make sure you read the Release notes for Exchange 2013 topic before you begin your deployment. The release notes
contain important information on issues you might encounter during and after your deployment.

Planning for Exchange 2013

Use the following links to access information to help you plan the deployment of Exchange Server 2013 into
your organization.

IMPORTANT
See Establish a Test Environment later in this topic about installing Exchange 2013 in a test environment.

Mailbox and Client Access servers: Learn about the Mailbox and Client Access server roles that are
included with Exchange 2013.
Exchange 2013 system requirements: Understand the system requirements that need to be satisfied in
your organization before you can install Exchange 2013.
Exchange 2013 prerequisites: Learn which Windows Server 2008 R2 Service Pack 1 (SP1) or Windows
Server 2012 features and the other software that needs to be installed to perform a successful installation
of Exchange 2013.
Exchange Server Deployment Assistant: Use this tool to generate a customized checklist for planning,
installing, or upgrading to Exchange 2013. Guidance is available for multiple scenarios, including an on-
premises, hybrid, or cloud deployment.
Active Directory: Read this topic to learn about how Exchange 2013 uses Active Directory and how your
Active Directory deployment affects your Exchange deployment.
Anti-malware protection: Read this topic to understand anti-malware protection options for Exchange
2013.
Exchange Server Hybrid Deployments: Read this topic to help you with planning a hybrid deployment
with Microsoft Office 365 and your on-premises Exchange 2013 organization.
Planning for high availability and site resilience: Read this topic to help you with planning to achieve your
high availability and business continuity requirements.
Integration with SharePoint and Lync: Read this topic to learn about integrating Exchange 2013, Microsoft
 SharePoint 2013, and Microsoft Lync 2013 to enable cross-product archiving, hold, and eDiscovery; site
mailboxes; authentication; Lync presence; and more.
Planning for Unified Messaging: Read this topic to learn more about planning for Exchange 2013 Unified
Messaging.
Exchange 2013 storage configuration options: Read this topic to learn about the storage architectures,
disk types, and storage configurations supported by the Exchange 2013 Mailbox server role.
Exchange 2013 virtualization: Read this topic to learn more about how you can deploy Exchange 2013 in
a virtualized environment.
Multi-tenancy in Exchange 2013: Read this topic to learn more about how you can configure Exchange
2013 to host multiple and discrete organizations or business units that ordinarily don't share email, data,
users, global address lists (GALs), or other commonly used Exchange objects.
Exchange Development Technologies: This topic contains important information about Application
Programming Interfaces (APIs) that are available for applications that use Exchange 2013.

Establish a test environment

Before installing Exchange 2013 for the first time, we recommend that you install it in an isolated test
environment. This approach reduces the risk of end-user downtime and negative ramifications to the production
environment.
The test environment will act as your "proof of concept" for your new Exchange 2013 design and make it
possible to move forward or roll back any implementations before deploying into your production
environments. Having an exclusive test environment for validation and testing allows you to do pre-installation
checks for your future production environments. By installing in a test environment first, we believe that your
organization will have a better likelihood of success in a full production implementation.
For many organizations, the costs of building a test lab may be high because of the need to duplicate the
production environment. To reduce the hardware costs associated with a prototype lab, we recommend the use
of virtualization by using Windows Server 2008 R2 or Windows Server 2012 Hyper-V technologies. Hyper-V
enables server virtualization, allowing multiple virtual operating systems to run on a single physical machine.
For more detailed information about Hyper-V, see Server Virtualization. For information about Microsoft
support of Exchange 2013 in production on hardware virtualization software, see "Hardware virtualization" in
Exchange 2013 system requirements.

Deploying an installation of Exchange 2013

The deployment phase is the period during which you install Exchange 2013 into your organization. Before you
begin the deployment phase, you should plan your Exchange organization. For more information, see the
Planning section earlier in this topic.
Use the following links to access the information you need to help you with deploying Exchange 2013.
Prepare Active Directory and domains: Learn about the steps you need to take to prepare your Active
Directory forest for Exchange 2013 and the changes Exchange makes to your forest.
Install Exchange 2013 using the Setup wizard: Follow the steps in this topic to use the Exchange 2013
Setup wizard to install Exchange 2013 into a new Exchange organization.
Install Exchange 2013 using unattended mode: Follow the steps in this topic to use Exchange 2013
unattended setup to install Exchange 2013 into a new Exchange organization.
Install the Exchange 2013 Edge Transport role using the Setup wizard: Follow the steps in this topic to use
 the Exchange 2013 Setup wizard to install the Exchange 2013 Edge Transport role into a perimeter
network.
Upgrade Exchange 2013 to the latest cumulative update or service pack: Follow the steps in this topic to
apply the latest cumulative update or service pack to Exchange 2013 servers in your organization.
Upgrade from Exchange 2010 to Exchange 2013: Follow the steps in this topic to install Exchange 2013
into an existing Exchange 2010 organization.
Upgrade from Exchange 2007 to Exchange 2013: Follow the steps in this topic to install Exchange 2013
into an existing Exchange 2007 organization.
Deploy multiple forest topologies for Exchange 2013: Read this topic for information that will help you
deploy Exchange 2013 in an organization that contains more than one Active Directory forest.
Deploying voice mail and UM: Read this topic for information that will help you understand deploying
Exchange 2013 Unified Messaging, whether a new deployment or an upgrade.
Hybrid Deployment procedures: Read this topic for information that will help you deploy Exchange 2013
in an existing hybrid deployment.
Exchange 2013 post-Installation tasks: Learn about post-installation tasks to complete your Exchange
2013 installation.

Understanding Exchange 2013 Setup

You can use different types and modes of Exchange 2013 Setup to install and maintain the various editions and
versions of Exchange 2013.

Exchange editions and versions

Exchange 2013 is available in two server editions: Standard Edition and Enterprise Edition. These are licensing
editions that are defined by a product key. For more information, see Exchange Server Licensing.

Types of Exchange Setup

You have the following options for Exchange 2013 Setup:
Exchange Setup UI: Running Setup.exe without any command-line switches provides an interactive
experience where you are guided by the Exchange 2013 Setup wizard.
Exchange Unattended Setup: Running Setup.exe with command-line switches enables you to install
Exchange from an interactive command line or through a script.
Setup.exe is available from the Exchange 2013 DVD or the downloaded source files.

Modes of Exchange Setup

Setup for Exchange 2013 includes several installation modes:
Install: Use this mode when you're installing a new server role or adding a server role to an existing
installation (maintenance mode). You can use this mode from both the Exchange Setup wizard and the
unattended install.
Uninstall: Use this mode when you're removing the Exchange installation from a computer. You can use
this mode from both the Exchange Setup wizard and the unattended install.
Upgrade: Select this mode used when you have an existing installation of Exchange and you're installing
 a cumulative update or service pack. You can use this mode from both the Exchange Setup wizard and the
unattended install.

NOTE
Exchange 2013 doesn't support in-place upgrades from previous versions of Exchange. This mode is used only to
install cumulative updates or service packs.

RecoverServer: Use this mode when there has been a catastrophic failure of a server, and you need to
recover data. You must install a server using the same fully qualified domain name (FQDN ) as the failed
server, and then run Setup with the /m:RecoverServer switch. Don't specify the roles to restore. Setup
detects the Exchange Server object in Active Directory and installs the corresponding files and
configuration automatically. After you recover the server, you can restore databases and reconfigure any
additional settings. To run in RecoverServer mode, you can't have Exchange installed on the server. The
Exchange server object must exist in Active Directory. You can only use this mode during an unattended
installation.

NOTE
You must complete one mode of Setup before you can use another mode.

For more information

IPv6 support in Exchange 2013
Exchange admin center in Exchange 2013
Exchange 2013 language support
Exchange 2013 readiness checks
 Exchange Server Deployment Assistant
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Exchange Server Deployment Assistant is a Web-based tool that can help you with your Microsoft Exchange
Server 2016 and Exchange Server 2013 deployment. The Deployment Assistant asks you a few questions about
your current environment and then generates a custom checklist and procedures that help simplify your
deployment. To access the Deployment Assistant, see Exchange Server Deployment Assistant.
You can use the Deployment Assistant for the following deployment scenarios:
Exchange 2016 On-Premises only
New installation of Exchange Server 2016
Upgrade from Exchange Server 2010 to Exchange 2016
Upgrade from Exchange Server 2013 to Exchange 2016 (coming soon)
Upgrade from a mixed Exchange Server 2010 and Exchange Server 2013 organization to Exchange
2016 (coming soon)
For more information about this scenario, see Planning and deployment.
Exchange 2016 Hybrid (On-Premises + Exchange Online)
Scenarios supporting Exchange 2016 hybrid deployments will be available soon!
Exchange 2013 On-Premises only
New installation of Exchange Server 2013
Upgrade from Exchange Server 2010 to Exchange 2013
Upgrade from Exchange Server 2007 to Exchange 2013
Upgrade from a mixed Exchange 2007 and Exchange 2010 organization to Exchange 2013
For more information about this scenario, see Planning and deployment.
Exchange 2013 Hybrid (On-Premises + Exchange Online)
Exchange 2013 on-premises with Exchange Online
Exchange 2010 on-premises with Exchange Online
Exchange 2007 on-premises with Exchange Online
For more information about this scenario, see Exchange Server Hybrid Deployments.

IMPORTANT
If you have an Exchange 2003 on-premises organization and want to configure a new hybrid deployment with
Office 365, you must add one or more servers running Exchange 2010 Server Service Pack 3, not Exchange 2013
servers, to your on-premises organization. To do that, we strongly recommend that you use the Exchange 2010
hybrid deployment option in the Exchange Server Deployment Assistant.
 Cloud only
For more information about this scenario, see Understanding Cloud-Only Deployments.
In addition to the above Exchange 2013 deployment scenarios, the Deployment Assistant also has deployment
scenarios for Exchange 2010.
 Active Directory
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 uses Active Directory to store and share directory information with Windows.
Active Directory forest design for Exchange 2013 is similar to Exchange Server 2010, except in a few ways, which
are discussed below.

Active Directory driver

The Active Directory driver is the core Microsoft Exchange component that allows Exchange services to create,
modify, delete, and query for Active Directory Domain Services (AD DS ) data. In Exchange 2013, all access to
Active Directory is done using the Active Directory driver itself. Previously, in Exchange 2010, DSAccess provided
directory lookup services for components such as SMTP, message transfer agent (MTA), and the Exchange store.
The Active Directory driver also uses Microsoft Exchange Active Directory Topology (MSExchangeADTopology),
which allows the Active Directory driver to use Directory Service Access (DSAccess) topology data. This data
includes the list of available domain controllers and global catalog servers available to handle Exchange requests.
For more information about the Active Directory Driver, see Active Directory Domain Services.

Active Directory schema changes

Exchange 2013 adds new attributes to the Active Directory domain service schema and also makes other
modifications to existing classes and attributes. For more information about Active Directory changes when you
install Exchange 2013, see Exchange 2013 Active Directory schema changes.

For more information

To learn more about how Exchange 2013 stores and retrieves information in Active Directory so that you can plan
access to it, see Access to Active Directory.
For more information about Active Directory forest design, see AD DS Design Guide.
To learn more about computers running Windows in an Active Directory domain and deploying Exchange 2013 in
a domain that has a disjoint namespace, see Disjoint namespace scenarios.
 Access to Active Directory
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 stores all configuration and recipient information in the Active Directory
directory service database. When a computer running Exchange 2013 requires information about recipients and
information about the configuration of the Exchange organization, it must query Active Directory to access the
information. Active Directory servers must be available for Exchange 2013 to function correctly.
This topic explains how Exchange 2013 stores and retrieves information in Active Directory so that you can plan
access to Active Directory. This topic also discusses issues you should be aware of if you try to recover deleted
Exchange 2013 Active Directory objects.

Exchange information stored in Active Directory

The Active Directory database stores information in three types of logical partitions that are described in the
following sections:
Schema partition
Configuration partition
Domain partition

Schema partition
The schema partition stores the following two types of information:
Schema classes define all the types of objects that can be created and stored in Active Directory.
Schema attributes define all the properties that can be used to describe the objects that are stored in
Active Directory.
When you install the first Exchange 2013 server role in the forest or run the Active Directory preparation process,
the Active Directory preparation process adds many classes and attributes to the Active Directory schema. The
classes that are added to the schema are used to create Exchange-specific objects, such as agents and connectors.
The attributes that are added to the schema are used to configure the Exchange-specific objects and the mail-
enabled users and groups. These attributes include properties, such as Outlook Web App settings and
Microsoft Exchange Unified Messaging (UM ) settings. Every domain controller and global catalog server in the
forest contains a complete replica of the schema partition.
For more information about schema modifications in Exchange 2013, see Exchange 2013 Active Directory schema
changes.

Configuration partition
The configuration partition stores information about the forest-wide configuration. This configuration information
includes the configuration of Active Directory sites, Exchange global settings, transport settings, and mailbox
policies. Each type of configuration information is stored in a container in the configuration partition. Exchange
configuration information is stored in a subfolder under the configuration partition's Services container. The
information that is stored in this container includes the following:
 Address lists
Address book mailbox policies
Administrative groups
Client access settings
Connections
Mobile Mailbox Settings
Global settings
Monitoring Settings
System policies
Retention policies container
Transport settings
Every domain controller and global catalog server in the forest contains a complete replica of the configuration
partition.

Domain partition
The domain partition stores information in default containers and in organizational units that are created by the
Active Directory administrator. These containers hold the domain-specific objects. This data includes Exchange
system objects and information about the computers, users, and groups in that domain. When Exchange 2013 is
installed, Exchange updates the objects in this partition to support Exchange functionality. This functionality affects
how recipient information is stored and accessed.
Each domain controller contains a complete replica of the domain partition for the domain for which it is
authoritative. Every global catalog server in the forest contains a subset of the information in every domain
partition in the forest.

How Exchange 2013 accesses information in Active Directory

Exchange 2013 uses an Active Directory API to access information that is stored in Active Directory. The Microsoft
Exchange Active Directory Topology service runs on all Exchange 2013 server roles. This service reads information
from all Active Directory partitions. The data that is retrieved is cached and is used by Exchange 2013 servers to
discover the Active Directory site location of all Exchange services in the organization.
For more information about topology and service discovery, see Planning to use Active Directory sites for routing
mail.
Exchange 2013 is an Active Directory site-aware application that prefers to communicate with the directory
servers that are located in the same site as the Exchange server to optimize network traffic. Each Exchange 2013
organizational server role must communicate with Active Directory to retrieve information about recipients and
information about the other Exchange 2013 server roles. The data that each server role obtains is described in the
following sections.
By default, whenever an Exchange 2013 server starts, it binds to a randomly selected domain controller and global
catalog server in its own site. You can view the selected directory servers by using the Get-ExchangeServer
cmdlet in the Exchange Management Shell. You can also use the Set-ExchangeServer cmdlet to configure a static
list of domain controllers to which an Exchange 2013 server should bind or a list of domain controllers that should
be excluded.
 IMPORTANT
A Windows Server 2008 domain controller can be configured as a read-only directory server. This configuration is useful
when you want to deploy a domain controller or global catalog server in a remote site for authentication and authorization
purposes, but you don't want to allow administrators in that site to write changes to Active Directory. However, you can't
deploy an Exchange 2013 server in any site that contains only read-only directory servers.

Mailbox server role

The Mailbox server role stores configuration information about mailbox users and stores in Active Directory.
Additionally, for Exchange 2013, the Mailbox server includes all the traditional server components found in
Exchange 2010: the Client Access protocols, Transport service, Mailbox databases, and Unified Messaging. The
Mailbox server handles all activity for the active mailboxes on that server.

Client access server role

In Exchange 2013, the Client Access server provides authentication, limited redirection, and proxy services. The
Client Access server itself doesn't do any data rendering. The Client Access server is a thin and stateless server.
There is never anything queued or stored on the Client Access server. The Client Access server offers all the usual
client access protocols: HTTP, POP and IMAP, and SMTP.

Recovery of deleted Exchange objects

Active Directory Recycle Bin helps minimize directory service downtime by enhancing your ability to preserve and
recover accidentally deleted Active Directory objects without restoring Active Directory data from backups,
restarting Active Directory Domain Services (AD DS ), or rebooting domain controllers.
The most important thing to understand about recovering deleted Exchange-related Active Directory objects is
that Exchange objects don't exist in isolation. For example, when you mail-enable a user, several different policies
and links are calculated for the user based on your current Exchange configuration. Two problems that may arise
when you restore a deleted Exchange configuration or recipient object are:
Collisions: Some Exchange attributes must be unique across a forest. For example, proxy (email) addresses
must not be the same for two different users. Active Directory doesn't enforce proxy address uniqueness,
Exchange administrative tools check for uniqueness. Exchange email address policies also automatically
resolve possible conflicts in proxy address assignment based on deterministic rules. Therefore, it's possible
to restore an Exchange user object and, as a result, create a collision with proxy addresses or other attributes
that should be unique.
Misconfigurations: Exchange has automated rules that assign various policies or settings. If you delete a
recipient, and then change the rules or policies, restoring an Exchange user object may result in a user being
assigned to the wrong policy (or even to a policy that no longer exists).
The following guidelines will help you minimize problems or issues when you recover deleted Exchange-related
objects:
If you deleted an Exchange configuration object using Exchange management tools, don't restore the object.
Instead, create the object again using the Exchange management tools (Exchange admin center or Exchange
Management Shell).
If you deleted an Exchange configuration object without using the Exchange management tools, recover the
object as soon as possible. The more administrative and configuration changes that have been made in the
system since the deletion, the more likely it is that restoring the objects will result in misconfiguration.
If you recover deleted Exchange recipients (contacts, users, or distribution groups), monitor closely for
 collisions and errors relating to the recovered objects. If Exchange policies or other configuration relating to
recipients may have been modified since the deletion, re-apply current policies to the restored recipients to
ensure that they're configured correctly.

For more information

Active Directory Recycle Bin Step-by-Step Guide
Introduction to Active Directory Administrative Center Enhancements (Level 100)
Advanced AD DS Management Using Active Directory Administrative Center (Level 200)
 Exchange 2013 Active Directory schema changes
7/23/2019 • 16 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 adds new and modifies existing Active Directory schema classes and attributes.
This reference topic provides a summary of the Active Directory schema changes that are made when you install
the release to manufacturing (RTM ) version of Exchange 2013 or any of its cumulative updates or service packs.
Refer to the .ldf files for more information about changes to the Active Directory schema. The .ldf files are located
in the \amd64\Setup\Data\ directory in the Exchange installation files.
Exchange 2013 schema updates are cumulative. Each release includes all of the changes included in previous
releases. This means that if you skip a release, you may still need to apply schema updates even if the release
you're installing doesn't include its own changes. The following table gives examples of when your Active
Directory will be updated, and when it's already up-to-date.

CURRENT EXCHANGE 2013 RELEASE NEW EXCHANGE 2013 RELEASE BEING

INSTALLED INSTALLED ARE SCHEMA UPDATES REQUIRED?

Service Pack 1 Cumulative Update 8 Yes, schema updates are required.

through You need to apply the CU5, CU6, and
Cumulative Update 21 CU7 schema updates.

Cumulative Update 6 Cumulative Update 8 Yes, schema updates are required.

through You need to apply the CU7 schema
Cumulative Update 21 updates.

Cumulative Update 7 Cumulative Update 8 No, no schema updates are required.

through No schema changes are made in CU7
Cumulative Update 21 through CU21.

NOTE
The Active Directory schema changes identified in this topic may not apply to all editions of an Exchange Server version.
To verify that Active Directory has been successfully prepared, see the "How do you know this worked?" section in Prepare
Active Directory and domains.

Exchange 2013 CU23 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU23.

Exchange 2013 CU22 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU22.
However, a reduction in Active Directory permissions is made: The "Allow" Access Control Entry (ACE ) that grants
the "Exchange Windows Permissions" group the "Write DACL" right to the "User" and "INetOrgPerson" inherited
object types is updated to include the "Inherit Only" flag on the domain root object. For more information, see KB
4490059.

Exchange 2013 CU21 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU21.

Exchange 2013 CU20 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU20.

Exchange 2013 CU19 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU19.

Exchange 2013 CU18 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU18.

Exchange 2013 CU17 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU17.

Exchange 2013 CU16 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU16.

Exchange 2013 CU15 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU15.

Exchange 2013 CU14 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU14.

Exchange 2013 CU13 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU13.

Exchange 2013 CU12 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU12.

Exchange 2013 CU11 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU11.

Exchange 2013 CU10 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU10.

Exchange 2013 CU9 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU9.

Exchange 2013 CU8 Active Directory schema changes

No changes are made to the Active Directory schema in Exchange 2013 CU8.
Exchange 2013 CU7 Active Directory schema changes
This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 CU7. This section includes the following subsections:
Classes modified by Exchange 2013 CU7
Attributes added by Exchange 2013 CU7

Classes modified by Exchange 2013 CU7

This section contains the classes modified in Exchange 2013 CU7.

CLASS CHANGE ATTRIBUTE/CLASS

Mail-Recipient add: mayContain msExchStsRefreshTokensValidFrom

ms-Exch-Base-Class add: mayContain msExchMultiMailboxGUIDs

ms-Exch-Base-Class add: mayContain msExchMultiMailboxLocationsLink

Group add: auxiliaryClass msExchMailStorage

Attributes added by Exchange 2013 CU7

This section contains the attributes added in Exchange 2013 CU7.
ms-Exch-Multi-Mailbox-GUID
ms-Exch-Sts-Refresh-Tokens-Valid-From
ms-Exch-Multi-Mailbox-Locations-Link

Exchange 2013 CU6 Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 CU6. This section includes the following subsections:
Classes modified by Exchange 2013 CU6
Attributes added by Exchange 2013 CU6
Attributes modified by Exchange 2013 CU6

Classes modified by Exchange 2013 CU6

This section contains the classes modified in Exchange 2013 CU6.

CLASS CHANGE ATTRIBUTE/CLASS

Mail-Recipient add: mayContain msExchAuxMailboxParentObjectIdLi

nk
 CLASS CHANGE ATTRIBUTE/CLASS

Top add: mayContain msExchAuxMailboxParentObjectIdB

L

Attributes added by Exchange 2013 CU6

This section contains the attributes added in Exchange 2013 CU6.
ms-Exch-Aux-Mailbox-Parent-Object-Id-Link
ms-Exch-Aux-Mailbox-Parent-Object-Id-BL

Attributes modified by Exchange 2013 CU6

This section contains the attributes modified in Exchange 2013 CU6.

ATTRIBUTE CHANGE VALUE

ms-Exch-Smtp-TLS-Certificate replace: rangeUpper 1024

Exchange 2013 CU5 Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 CU5. This section includes the following subsections:
Classes added by Exchange 2013 CU5
Attributes added by Exchange 2013 CU5
Attributes modified by Exchange 2013 CU5

Classes added by Exchange 2013 CU5

This section contains the classes added in Exchange 2013 CU5.

CLASS CHANGE

ms-Exch-Unified-Policy ntdsSchemaAdd

ms-Exch-Unified-Rule ntdsSchemaAdd

Attributes added by Exchange 2013 CU5

This section contains the attributes added in Exchange 2013 CU5.
ms-Exch-UG -Member-Link
ms-Exch-UG -Member-BL

Attributes modified by Exchange 2013 CU5

This section contains the attributes modified in Exchange 2013 CU5.
 ATTRIBUTE CHANGE VALUE

ms-Exch-Smtp-Receive-Tls- Replace: rangeUpper 1024

Certificate-Name

Mail-Recipient Replace: mayContain msExchUGMemberLink

Top Replace: mayContain msExchUGMemberBL

Exchange 2013 SP1 Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 Service Pack 1 (SP1). This section includes the following subsections:
Classes added by Exchange 2013 SP1
Classes modified by Exchange 2013 SP1
Attributes added by Exchange 2013 SP1
Global catalog attributes added by Exchange 2013 SP1
Attributes modified by Exchange 2013 SP1

Classes added by Exchange 2013 SP1

This section contains the classes added in Exchange 2013 SP1.

CLASS CHANGE

ms-Exch-Intra-Organization-Connector ntdsSchemaModify

ms-Exch-Client-Access-Rule ntdsSchemaModify

Classes modified by Exchange 2013 SP1

This section contains the attributes added in Exchange 2013 SP1.

CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Mail-Storage add: mayContain msExchMailboxContainerGuid

ms-Exch-Mail-Storage add: mayContain msExchUnifiedMailbox

ms-Exch-OAB add: mayContain msExchOABGeneratingMailboxLink

Top add: mayContain msExchOABGeneratingMailboxBL

Attributes added by Exchange 2013 SP1
This section contains the attributes added in Exchange 2013 SP1.
ms-Exch-OAB -Generating-Mailbox-Link
ms-Exch-OAB -Generating-Mailbox-BL

Global catalog attributes added by Exchange 2013 SP1

The following global catalog attributes are added by Exchange 2013 SP1:
ms-Exch-Mailbox-Container-Guid
ms-Exch-Unified-Mailbox

Attributes modified by Exchange 2013 SP1

This section contains the attributes modified in Exchange 2013 SP1.

ATTRIBUTE CHANGE VALUE

Ms-exch-schema-version-pt rangeUpper 15292

Exchange 2013 CU3 Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 CU3. This section includes the following subsections:
Classes added by Exchange 2013 CU3
Attributes added by Exchange 2013 CU3
Attributes modified by Exchange 2013 CU3

Classes added by Exchange 2013 CU3

This section contains the classes added in Exchange 2013 CU3.

CLASS CHANGE

msExchThrottlingPolicy ntdsSchemaModify

Attributes added by Exchange 2013 CU3

This section contains the attributes added in Exchange 2013 CU3.
ms-Exch-Encryption-Throttling-Policy-State-Ex

Attributes modified by Exchange 2013 CU3

This section contains the attributes modified in Exchange 2013 CU3.
 ATTRIBUTE CHANGE VALUE

ms-Exch-Coexistence-Secure-Mail- rangeUpper 1024

Certificate-Thumbprintms-Exch-
Sync-Cookie

Exchange 2013 CU2 Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 CU2. This section includes the following subsections:
Classes added by Exchange 2013 CU2
Classes modified by Exchange 2013 CU2
Attributes added by Exchange 2013 CU2
Attributes modified by Exchange 2013 CU2

Classes added by Exchange 2013 CU2

This section contains the classes added in Exchange 2013 CU2.

CLASS CHANGE

ms-Exch-Config-Settings ntdsSchemaAdd

ms-Exch-Encryption-Virtual-Directory ntdsSchemaAdd

Classes modified by Exchange 2013 CU2

This section contains the classes modified in Exchange 2013 CU2.

CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Base-Class Add:mayContain msExchTenantCountry

ms-Exch-Base-Class Add:mayContain msExchConfigurationXML

ms-Exch-Account-Forest Add:mayContain msExchPartnerId

Attributes added by Exchange 2013 CU2

This section contains the attributes added in Exchange 2013 CU2.
ms-Exch-Tenant-Country

Attributes modified by Exchange 2013 CU2

This section contains the attributes modified in Exchange 2013 CU2.
 ATTRIBUTE CHANGE VALUE

ms-Exch-Sync-Cookie rangeUpper 262144

ms-Exch-Schema-Version-Pt rangeUpper 15281

Object IDs added by Exchange 2013 CU2

The following class object IDs are added when you install Exchange 2013 CU1:
1.2.840.113556.1.5.7000.62.50204
1.2.840.113556.1.5.7000.62.50205
The following attribute object IDs are added when you install Exchange 2013 CU1:
1.2.840.113556.1.4.7000.102.52130

Exchange 2013 CU1 Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 CU1. This section includes the following subsections:
Classes modified by Exchange 2013 CU1
Classes added by Exchange 2013 CU1
Attributes modified by Exchange 2013 CU1
Object IDs added by Exchange 2013 CU1
Indexed attributes added by Exchange 2013 CU1
Property sets modified by Exchange 2013 CU1
Global catalog attributes added by Exchange 2013 CU1

Classes modified by Exchange 2013 CU1

This section contains the classes modified in Exchange 2013 CU1.

CLASS CHANGE ATTRIBUTE/CLASS

Exch-Configuration-Unit-Container add:mayContain msExchArchiveRelease

Exch-Configuration-Unit-Container add:mayContain msExchMailboxRelease

Exch-Exchange-Server add:mayContain msExchArchiveRelease

Exch-Exchange-Server add:mayContain msExchMailboxRelease

Exch-OAB add:mayContain msExchLastUpdateTime

 CLASS CHANGE ATTRIBUTE/CLASS

Exch-Accepted-Domain add:mayContain msExchOfflineOrgIdHomeRealmRec

ord

Exch-Base-Class add:mayContain msExchCapabilityIdentifiers

Exch-Base-Class add:mayContain msExchObjectID

Exch-Base-Class add:mayContain msExchProvisioningTags

Exch-Organization-Container add:mayContain msExchMaxABP

Exch-Organization-Container add:mayContain msExchMaxOAB

Exch-Organization-Container add:mayContain pFContacts

Exch-Team-Mailbox-Provisioning- add:mayContain msExchConfigurationXML

Policy

Exch-MDB-Availability-Group add:mayContain msExchEvictedMembersLink

Top add:mayContain msExchEvictedMembersBL

Exch-On-Premises-Organization add:mayContain msExchTrustedDomainLink

Exch-OWA-Mailbox-Policy add:mayContain msExchConfigurationXML

Exch-OWA-Virtual-Directory add:mayContain msExchConfigurationXML

Classes added by Exchange 2013 CU1

This section contains the classes modified in Exchange 2013 CU1.

CLASS CHANGE

Exch-Mapi-Virtual-Directory ntdsSchemaAdd

Exch-Push-Notifications-App ntdsSchemaAdd

Attributes modified by Exchange 2013 CU1

This section contains the attributes modified in Exchange 2013 CU1.
 CLASS CHANGE ATTRIBUTE/CLASS

Exch-Mailflow-Policy-Transport- rangeUpper 256000

Rules-Template-Xml

Exch-Configuration-Unit-Container rangeUpper 15254

Object IDs added by Exchange 2013 CU1

The following attribute object IDs are added when you install Exchange 2013 CU1:
1.2.840.113556.1.4.7000.102.52109
1.2.840.113556.1.4.7000.102.52110
1.2.840.113556.1.4.7000.102.52127
1.2.840.113556.1.4.7000.102.52126
1.2.840.113556.1.4.7000.102.52128
1.2.840.113556.1.4.7000.102.52129
The following class object IDs are added when you install Exchange 2013 CU1:
1.2.840.113556.1.5.7000.62.50202
1.2.840.113556.1.5.7000.62.50203

Indexed attributes added by Exchange 2013 CU1

The following table lists the attributes that are added to the list of indexed attributes when you install Exchange
2013 CU1.

ATTRIBUTE SEARCH FLAG VALUE

ms-Exch-Provisioning-Tags 1

Property sets modified by Exchange 2013 CU1

The following property sets are modified when you install Exchange 2013 CU1:
Exchange-Information

Global catalog attributes added by Exchange 2013 CU1

The following global catalog attributes are added by Exchange 2013 CU1:
ms-Exch-Offline-OrgId-Home-Realm-Record
ms-Exch-EvictedMembers-Link
ms-Exch-EvictedMembers-BL

Exchange 2013 RTM Active Directory schema changes

This section summarizes the changes that are made to the Active Directory schema when you install Exchange
2013 RTM. This section includes the following subsections:
Classes modified by Exchange 2013 RTM
Attributes modified by Exchange 2013 RTM
Classes added by Exchange 2013 RTM
Attributes added by Exchange 2013 RTM
MAPI IDs added by Exchange 2013 RTM
Extended rights added by Exchange 2013 RTM
Object IDs added by Exchange 2013 RTM
Indexed attributes added by Exchange 2013 RTM
Global catalog attributes added by Exchange 2013 RTM

Classes modified by Exchange 2013 RTM

This section contains the classes modified in Exchange 2013 RTM.

CLASS CHANGE ATTRIBUTE/CLASS

Mail-Recipient add:mayContain msExchLocalizationFlags

Mail-Recipient add:mayContain msExchRoleGroupType

ms-Exch-Base-Class add:mayContain msExchDirsyncAuthorityMetadata

ms-Exch-Base-Class add:mayContain msExchDirsyncStatusAck

ms-Exch-Base-Class add:mayContain msExchEdgeSyncConfigFlags

ms-Exch-Base-Class add:mayContain msExchHABRootDepartmentLink

ms-Exch-Base-Class add:mayContain msExchDefaultPublicFolderMailbox

ms-Exch-Base-Class add:mayContain msExchForestModeFlag

ms-Exch-Configuration-Unit- add:mayContain msExchDirsyncStatus

Container

ms-Exch-Configuration-Unit- add:mayContain msExchIsDirsyncStatusPending

Container
CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Mail-Storage add:mayContain msExchPreviousArchiveDatabase

ms-Exch-Configuration-Unit- add:mayContain msExchDirSyncServiceInstance

Container

ms-Exch-Configuration-Unit- add:mayContain msExchOrganizationUpgradePolicyL

Container ink

ms-Exch-OWA-Mailbox-Policy add:mayContain msExchOWASetPhotoURL

ms-Exch-OWA-Virtual-Directory add:mayContain msExchOWASetPhotoURL

ms-Exch-Exchange-Server add:mayContain msExchWorkloadManagementPolic

yLink

Mail-Recipient add:mayContain ms-DS-GeoCoordinates-Altitude

Mail-Recipient add:mayContain ms-DS-GeoCoordinates-Latitude

Mail-Recipient add:mayContain ms-DS-GeoCoordinates-Longitude

ms-Exch-Resource-Policy add:mayContain msExchCustomerExpectationCritical

ms-Exch-Resource-Policy add:mayContain msExchDiscretionaryCritical

ms-Exch-Resource-Policy add:mayContain msExchInternalMaintenanceCritical

ms-Exch-Resource-Policy add:mayContain msExchUrgentCritical

ms-Exch-Availability-Address-Space add:mayContain msExchFedTargetAutodiscoverEPR

ms-Exch-Private-MDB add:mayContain msExchMailboxDatabaseTransportFl

ags

Mail-Recipient add:mayContain msExchRecipientSoftDeletedStatus

Mail-Recipient add:mayContain msExchWhenSoftDeletedTime

ms-Exch-Custom-Attributes add:mayContain msExchExtensionCustomAttribute1

CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Custom-Attributes add:mayContain msExchExtensionCustomAttribute2

ms-Exch-Custom-Attributes add:mayContain msExchExtensionCustomAttribute3

ms-Exch-Custom-Attributes add:mayContain msExchExtensionCustomAttribute4

ms-Exch-Custom-Attributes add:mayContain msExchExtensionCustomAttribute5

ms-Exch-Virtual-Directory add:mayContain msExchMRSProxyFlags

ms-Exch-Virtual-Directory add:mayContain msExchMRSProxyMaxConnections

ms-Exch-Active-Sync-Device add:mayContain msExchDeviceClientType

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringDeferAttem

pts

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringDeferWaitTi

me

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringFlags

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringPrimaryUpd

atePath

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringSecondaryU

pdatePath

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringUpdateFreq

uency

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringUpdateTim

eout

ms-Exch-Mail-Storage add:mayContain msExchTeamMailboxExpiration

ms-Exch-Mail-Storage add:mayContain msExchTeamMailboxOwners

ms-Exch-Mail-Storage add:mayContain msExchTeamMailboxSharePointLink

edBy
CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Mail-Storage add:mayContain msExchTeamMailboxSharePointUrl

ms-Exch-Mail-Storage add:mayContain msExchTeamMailboxShowInClientLi

st

ms-Exch-Mail-Storage add:mayContain msExchCalendarLoggingQuota

ms-Exch-MSO-Sync-Service- add:mayContain msExchMSOForwardSyncNonRecipi

Instance entCookie

ms-Exch-MSO-Sync-Service- add:mayContain msExchMSOForwardSyncRecipientC

Instance ookie

ms-Exch-MSO-Sync-Service- add:mayContain msExchMSOForwardSyncReplayList

Instance

ms-Exch-MSO-Sync-Service- add:mayContain msExchAccountForestLink

Instance

Top add:mayContain msExchAccountForestBL

Top add:mayContain msExchTrustedDomainBL

Top add:mayContain msExchAcceptedDomainBL

Top add:mayContain msExchHygieneConfigurationMalwa

reBL

Top add:mayContain msExchHygieneConfigurationSpam

BL

ms-Exch-Base-Class add:mayContain msExchELCMailboxFlags

Mail-Recipient add:mayContain msExchHomeMTASL

Mail-Recipient add:mayContain msExchMailboxMoveSourceArchive

MDBLinkSL

Mail-Recipient add:mayContain msExchMailboxMoveSourceMDBLin

kSL
CLASS CHANGE ATTRIBUTE/CLASS

Mail-Recipient add:mayContain msExchMailboxMoveTargetArchive

MDBLinkSL

Mail-Recipient add:mayContain msExchMailboxMoveTargetMDBLin

kSL

ms-Exch-Accepted-Domain add:mayContain msExchHygieneConfigurationLink

ms-Exch-Accepted-Domain add:mayContain msExchTransportResellerSettingsLin

kSL

ms-Exch-Configuration-Unit- add:mayContain msExchManagementSiteLinkSL

Container

ms-Exch-Configuration-Unit- add:mayContain msExchOrganizationUpgradePolicyL

Container inkSL

ms-Exch-Fed-OrgId add:mayContain msExchFedDelegationTrustSL

ms-Exch-Mail-Gateway add:mayContain msExchHomeMDBSL

ms-Exch-Mail-Gateway add:mayContain msExchHomeMTASL

ms-Exch-Mail-Storage add:mayContain msExchArchiveDatabaseLinkSL

ms-Exch-Mail-Storage add:mayContain msExchDisabledArchiveDatabaseLin

kSL

ms-Exch-Mail-Storage add:mayContain msExchHomeMDBSL

ms-Exch-Mail-Storage add:mayContain msExchMailboxMoveTargetMDBLin

kSL

ms-Exch-Mail-Storage add:mayContain msExchPreviousArchiveDatabaseSL

ms-Exch-Mail-Storage add:mayContain msExchPreviousHomeMDBSL

ms-Exch-MRS-Request add:mayContain msExchMailboxMoveSourceMDBLin

kSL
CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-MRS-Request add:mayContain msExchMailboxMoveStorageMDBLi

nkSL

ms-Exch-MRS-Request add:mayContain msExchMailboxMoveTargetMDBLin

kSL

ms-Exch-OAB add:mayContain msExchOffLineABServerSL

ms-Exch-Routing-Group- add:mayContain msExchHomeMTASL

Connector

ms-Exch-Site-Connector add:mayContain msExchHomeMTASL

ms-Exch-Tenant-Perimeter-Settings add:mayContain msExchTransportResellerSettingsLin

kSL

ms-Exch-Domain-Content-Config add:mayContain msExchContentByteEncoderTypeFo

r7BitCharsets

ms-Exch-Domain-Content-Config add:mayContain msExchContentPreferredInternetCo

dePageForShiftJis

ms-Exch-Domain-Content-Config add:mayContain msExchContentRequiredCharSetCo

verage

ms-Exch-Coexistence-Relationship add:mayContain msExchCoexistenceOnPremisesSma

rtHost

ms-Exch-Coexistence-Relationship add:mayContain msExchCoexistenceSecureMailCertifi

cateThumbprint

ms-Exch-Coexistence-Relationship add:mayContain msExchCoexistenceTransportServers

Mail-Recipient add:mayContain ms-exch-group-external-member-

count

Mail-Recipient add:mayContain ms-exch-group-member-count

Ms-Exch-Organization-Container add:mayContain ms-exch-organization-flags-2

Mail-Recipient add:mayContain msExchGroupExternalMemberCoun

t
CLASS CHANGE ATTRIBUTE/CLASS

Mail-Recipient add:mayContain msExchGroupMemberCount

Mail-Recipient add:mayContain msExchShadowWhenSoftDeletedTi

me

ms-Exch-Organization-Container add:mayContain msExchOrganizationFlags2

ms-Exch-Organization-Container add:mayContain msExchUMAvailableLanguages

ms-Exch-Control-Point-Config add:mayContain msExchRMSOnlineCertificationLocat

ionUrl

ms-Exch-Control-Point-Config add:mayContain msExchRMSOnlineKeySharingLocati

onUrl

ms-Exch-Control-Point-Config add:mayContain msExchRMSOnlineLicensingLocatio

nUrl

ms-Exch-Throttling-Policy add:mayContain msExchThrottlingPolicyFlags

ms-Exch-Exchange-Server add:mayContain msExchMalwareFilteringScanTimeou

t

ms-Exch-Hosted-Content-Filter- add:mayContain msExchSpamCountryBlockList

Config

ms-Exch-Hosted-Content-Filter- add:mayContain msExchSpamLanguageBlockList

Config

ms-Exch-Hosted-Content-Filter- add:mayContain msExchSpamNotifyOutboundRecipi

Config ents

ms-Exch-Malware-Filter-Config add:mayContain msExchMalwareFilterConfigExternal

SenderAdminAddress

ms-Exch-Malware-Filter-Config add:mayContain msExchMalwareFilterConfigInternal

SenderAdminAddress

ms-Exch-MSO-Sync-Service- add:mayContain msExchActiveInstanceSleepInterval

Instance
CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-MSO-Sync-Service- add:mayContain msExchPassiveInstanceSleepInterval

Instance

ms-Exch-MSO-Sync-Service- add:mayContain msExchSyncDaemonMaxVersion

Instance

ms-Exch-MSO-Sync-Service- add:mayContain msExchSyncDaemonMinVersion

Instance

Mail-Recipient add:mayContain msExchPublicFolderMailbox

Mail-Recipient add:mayContain msExchPublicFolderSmtpAddress

ms-Exch-Hosted-Content-Filter- add:mayContain msExchSpamDigestFrequency

Config

ms-Exch-Hosted-Content-Filter- add:mayContain msExchSpamQuarantineRetention

Config

ms-Exch-Organization-Container add:mayContain msExchWACDiscoveryEndpoint

ms-Exch-Organization-Container add:mayContain msExchAdfsAuthenticationRawConfi

guration

ms-Exch-Organization-Container add:mayContain msExchServiceEndPointURL

ms-Exch-Public-Folder add:mayContain msExchPublicFolderEntryId

ms-Exch-Transport-Rule add:mayContain msExchTransportRuleImmutableId

ms-Exch-Transport-Settings add:mayContain msExchTransportMaxRetriesForLoca

lSiteShadow

ms-Exch-Transport-Settings add:mayContain msExchTransportMaxRetriesForRem

oteSiteShadow

ms-Exch-Transport-Settings add:mayContain msExchConfigurationXML

ms-Exch-Account-Forest possSuperiors msExchContainer

CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Base-Class add:mayContain msExchCanaryData0

ms-Exch-Base-Class add:mayContain msExchCanaryData1

ms-Exch-Base-Class add:mayContain msExchCanaryData2

ms-Exch-Base-Class add:mayContain msExchCorrelationId

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantCompletionT

Container argetVector

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantFlags

Container

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantSafeLockdow

Container nSchedule

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantSourceForest

Container

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantStartLockdo

Container wn

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantStartRetired

Container

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantStartSync

Container

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantStatus

Container

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantTargetForest

Container

ms-Exch-Configuration-Unit- add:mayContain msExchRelocateTenantTransitionCo

Container unter

ms-Exch-Configuration-Unit- add:mayContain msExchSyncCookie

Container
 CLASS CHANGE ATTRIBUTE/CLASS

ms-Exch-Throttling-Policy add:mayContain msExchAnonymousThrottlingPolicy

StateEx

ms-Exch-Throttling-Policy add:mayContain msExchEASThrottlingPolicyStateEx

ms-Exch-Throttling-Policy add:mayContain msExchEWSThrottlingPolicyStateEx

ms-Exch-Throttling-Policy add:mayContain msExchGeneralThrottlingPolicyState

Ex

ms-Exch-Throttling-Policy add:mayContain msExchIMAPThrottlingPolicyStateEx

ms-Exch-Throttling-Policy add:mayContain msExchOWAThrottlingPolicyStateEx

ms-Exch-Throttling-Policy add:mayContain msExchPOPThrottlingPolicyStateEx

ms-Exch-Throttling-Policy add:mayContain msExchPowershellThrottlingPolicySt

ateEx

ms-Exch-Throttling-Policy add:mayContain msExchRCAThrottlingPolicyStateEx

ms-Exch-Mailflow-Policy add:mayContain msExchImmutableId

ms-Exch-MDB add:mayContain msExchCalendarLoggingQuota

ms-Exch-Transport-Rule add:mayContain msExchImmutableId

ms-Exch-MSO-Sync-Service- add:mayContain msExchSyncServiceInstanceNewTen

Instance antMaxVersion

ms-Exch-MSO-Sync-Service- add:mayContain msExchSyncServiceInstanceNewTen

Instance antMinVersion

Attributes modified by Exchange 2013 RTM

This section contains the attributes modified in Exchange 2013 RTM.

CLASS CHANGE VALUE

ms-Exch-Schema-Version-Pt rangeUpper 15137

CLASS CHANGE VALUE

ms-Exch-HAB-Root-Department- replace: TRUE

Link isMemberOfPartialAttributeSet

ms-Exch-Archive-GUID replace: searchFlags 9

ms-Exch-Accepted-Domain-Name replace: searchFlags 9

ms-Exch-Bypass-Audit replace: searchFlags 19

ms-Exch-Mailbox-Audit-Enable replace: searchFlags 19

ms-Exch-Extension-Custom- isMemberOfPartialAttributeSet: TRUE

Attribute-1

ms-Exch-Extension-Custom- isMemberOfPartialAttributeSet: TRUE

Attribute-2

ms-Exch-Extension-Custom- isMemberOfPartialAttributeSet: TRUE

Attribute-3

ms-Exch-Extension-Custom- isMemberOfPartialAttributeSet: TRUE

Attribute-4

ms-Exch-Extension-Custom- isMemberOfPartialAttributeSet TRUE

Attribute-5

ms-Exch-Coexistence-On- ntdsSchemaAdd attributeID:

Premises-Smart-Host 1.2.840.113556.1.4.7000.102.5199
2 isMemberOfPartialAttributeSet:
FALSE (not in global catalogue)
searchFlags: 0 (no index)

ms-Exch-Coexistence-Secure-Mail- ntdsSchemaAdd attributeID:

Certificate-Thumbprint 1.2.840.113556.1.4.7000.102.5199
1 isMemberOfPartialAttributeSet:
FALSE (not in global catalogue)
searchFlags: 0 (no index)

ms-Exch-Coexistence-Transport- ntdsSchemaAdd attributeID:

Servers 1.2.840.113556.1.4.7000.102.5199
0 isMemberOfPartialAttributeSet:
FALSE (not in global catalogue)
searchFlags: 0 (no index)
 CLASS CHANGE VALUE

ms-Exch-ELC-Mailbox-Flags replace: attributeSecurityGuid F6SzsVXskUGzJ7cuM+OK8g==

ms-Exch-Malware-Filtering- rangeUpper 38880

Update-Frequency

ms-Exch-MSO-Forward-Sync-Non- rangeUpper 20480

Recipient-Cookie

ms-Exch-MSO-Forward-Sync- rangeUpper 20480

Recipient-Cookie

ms-Exch-Role-Entries rangeUpper 8192

ms-Exch-Group-External-Member- ntdsSchemaModify isMemberOfPartialAttributeSet:

Count TRUE MAPIID:36066

ms-Exch-Group-Member-Count ntdsSchemaModify replace:

isMemberOfPartialAttributeSetisMe
mberOfPartialAttributeSet: TRUE
MAPIID: 36067

Classes added by Exchange 2013 RTM

The following classes are added when you install Exchange 2013 RTM:
ms-Exch-ActiveSync-Device-Autoblock-Threshold
ms-Exch-MSO -Forward-Sync-Divergence
ms-Exch-MSO -Sync-Service-Instance
ms-Exch-Organization-Upgrade-Policy
ms-Exch-Workload-Policy
ms-Exch-Resource-Policy
ms-Exch-Team-Mailbox-Provisioning-Policy
ms-Exch-Account-Forest
ms-Exch-Hosted-Content-Filter-Config
ms-Exch-Hygiene-Configuration
ms-Exch-Malware-Filter-Config
ms-Exch-Protocol-Cfg-SIP -Container
ms-Exch-Protocol-Cfg-SIP -FE -Server
ms-Exch-Exchange-Transport-Server
 ms-Exch-Auth-Auth-Config
ms-Exch-Auth-Auth-Server
ms-Exch-Auth-Partner-Application
ms-Exch-Mailflow -Policy-Collection
ms-Exch-Mailflow -Policy

Attributes added by Exchange 2013 RTM

The following attributes encompass a set of changes required for new features and are added when you install
Exchange 2013 RTM:
ms-Exch-ActiveSync-Device-AutoBlock-Duration
ms-Exch-ActiveSync-Device-Autoblock-Threshold-Incidence-Duration
ms-Exch-ActiveSync-Device-Autoblock-Threshold-Incidence-Limit
ms-Exch-ActiveSync-Device-Autoblock-Threshold-Type
ms-Exch-Dirsync-Authority-Metadata
ms-Exch-Dirsync-Status
ms-Exch-Dirsync-Status-Ack
ms-Exch-Edge-Sync-Config-Flags
ms-Exch-Is-Dirsync-Status-Pending,
ms-Exch-Localization-Flags
ms-Exch-Previous-Archive-Database
ms-Exch-RoleGroup-Type
ms-Exch-External-Directory-Object-Class
ms-Exch-MSO -Forward-Sync-Divergence-Count
ms-Exch-MSO -Forward-Sync-Divergence-Timestamp
ms-Exch-MSO -Forward-Sync-Divergence-Related-Object-Link
ms-Exch-Default-Public-Folder-Mailbox
ms-Exch-Forest-Mode-Flag
ms-Exch-Dir-Sync-Service-Instance
ms-Exch-Organization-Upgrade-Policy-Date
ms-Exch-Organization-Upgrade-Policy-Enabled
ms-Exch-Organization-Upgrade-Policy-MaxMailboxes
ms-Exch-Organization-Upgrade-Policy-Priority
ms-Exch-Organization-Upgrade-Policy-Source-Version
ms-Exch-Organization-Upgrade-Policy-Status
ms-Exch-Organization-Upgrade-Policy-Target-Version
ms-Exch-OWA-Set-Photo-URL
ms-Exch-Organization-Upgrade-Policy-Link
ms-Exch-Organization-Upgrade-Policy-BL
ms-Exch-Workload-Classification
ms-Exch-Workload-Management-Is-Enabled
ms-Exch-Workload-Type
ms-Exch-Workload-Management-Policy-Link
ms-Exch-Workload-Management-Policy-BL
ms-Exch-Workload-Management-Policy
ms-Exch-Customer-Expectation-Overloaded
ms-Exch-Customer-Expectation-Underloaded
ms-Exch-Discretionary-Overloaded
ms-Exch-Discretionary-Underloaded
ms-Exch-Internal-Maintenance-Overloaded
ms-Exch-Internal-Maintenance-Underloaded
ms-Exch-Resource-Type
ms-Exch-Urgent-Overloaded
ms-Exch-Urgent-Underloaded
ms-DS -GeoCoordinates-Altitude
ms-DS -GeoCoordinates-Latitude
ms-DS -GeoCoordinates-Longitude
ms-Exch-Customer-Expectation-Critical
ms-Exch-Discretionary-Critical
ms-Exch-Internal-Maintenance-Critical
ms-Exch-Urgent-Critical
ms-Exch-Mailbox-Database-Transport-Flags
ms-Exch-Extension-Custom-Attribute-1
ms-Exch-Extension-Custom-Attribute-2
ms-Exch-Extension-Custom-Attribute-3
ms-Exch-Extension-Custom-Attribute-4
ms-Exch-Extension-Custom-Attribute-5
ms-Exch-MRS -Proxy-Flags
ms-Exch-MRS -Proxy-Max-Connections
ms-Exch-Recipient-SoftDeleted-Status
ms-Exch-When-Soft-Deleted-Time
ms-Exch-Device-Client-Type
ms-Exch-Malware-Filtering-Defer-Attempts
ms-Exch-Malware-Filtering-Defer-Wait-Time
ms-Exch-Malware-Filtering-Flags
ms-Exch-Malware-Filtering-Primary-Update-Path
ms-Exch-Malware-Filtering-Secondary-Update-Path
ms-Exch-Malware-Filtering-Update-Frequency
ms-Exch-Malware-Filtering-Update-Timeout
ms-Exch-Team-Mailbox-Expiration
ms-Exch-Team-Mailbox-Expiry-Days
ms-Exch-Team-Mailbox-Owners
ms-Exch-Team-Mailbox-SharePoint-Linked-By
ms-Exch-Team-Mailbox-SharePoint-Url
ms-Exch-Team-Mailbox-Show -In-Client-List
ms-Exch-Account-Forest-Link
ms-Exch-Account-Forest-BL
ms-Exch-Trusted-Domain-Link
ms-Exch-Trusted-Domain-BL
ms-Exch-Archive-Database-Link-SL
ms-Exch-Disabled-Archive-Database-Link-SL
ms-Exch-Fed-Delegation-Trust-SL
ms-Exch-Home-MDB -SL
ms-Exch-Home-MTA-SL
ms-Exch-Mailbox-Move-Source-Archive-MDB -Link-SL
ms-Exch-Mailbox-Move-Source-MDB -Link-SL
ms-Exch-Mailbox-Move-Storage-MDB -Link-SL
ms-Exch-Mailbox-Move-Target-Archive-MDB -Link-SL
ms-Exch-Mailbox-Move-Target-MDB -Link-SL
ms-Exch-Malware-Filter-Config-Alert-Text
ms-Exch-Malware-Filter-Config-External-Body
ms-Exch-Malware-Filter-Config-External-Subject
ms-Exch-Malware-Filter-Config-Flags
ms-Exch-Malware-Filter-Config-From-Address
ms-Exch-Malware-Filter-Config-From-Name
ms-Exch-Malware-Filter-Config-Internal-Body
ms-Exch-Malware-Filter-Config-Internal-Subject
ms-Exch-Management-Site-Link-SL
ms-Exch-Off-Line-AB -Server-SL
ms-Exch-Organization-Upgrade-Policy-Link-SL
ms-Exch-Previous-Archive-Database-SL
ms-Exch-Previous-Home-MDB -SL
ms-Exch-RMS -Computer-Accounts-Link-SL
ms-Exch-Spam-Add-Header
ms-Exch-Spam-Asf-Settings
ms-Exch-Spam-Asf-Test-Bcc-Address
ms-Exch-Spam-False-Positive-Cc
ms-Exch-Spam-Flags
ms-Exch-Spam-Modify-Subject
ms-Exch-Spam-Outbound-Spam-Cc
ms-Exch-Spam-Redirect-Address
ms-Exch-Transport-Reseller-Settings-Link-SL
ms-Exch-Hygiene-Configuration-Link
ms-Exch-Accepted-Domain-BL
ms-Exch-Malware-Filter-Config-Link
ms-Exch-Hygiene-Configuration-Malware-BL
ms-Exch-Hosted-Content-Filter-Config-Link
ms-Exch-Hygiene-Configuration-Spam-BL
ms-Exch-Content-Byte-Encoder-Type-For-7-Bit-Charsets
ms-Exch-Content-Preferred-Internet-Code-Page-For-Shift-Jis
ms-Exch-Content-Required-Char-Set-Coverage
ms-Exch-Group-External-Member-Count
ms-Exch-Group-Member-Count
ms-Exch-Organization-Flags-2
ms-Exch-RMSOnline-Certification-Location-Url
ms-Exch-RMSOnline-Key-Sharing-Location-Url
ms-Exch-RMSOnline-Licensing-Location-Url
ms-Exch-Shadow -When-Soft-Deleted-Time
ms-Exch-Throttling-Policy-Flags
ms-Exch-Malware-Filter-Config-External-Sender-Admin-Address
ms-Exch-Malware-Filter-Config-Internal-Sender-Admin-Address
ms-Exch-Malware-Filtering-Scan-Timeout
ms-Exch-Spam-Country-Block-List
ms-Exch-Spam-Language-Block-List
ms-Exch-Spam-Notify-Outbound-Recipients
ms-Exch-Auth-App-Secret
ms-Exch-Auth-Application-Identifier
ms-Exch-Auth-Auth-Server-Type
ms-Exch-Auth-Authorization-Url
ms-Exch-Auth-Certificate-Data
ms-Exch-Auth-Certificate-Thumbprint
ms-Exch-Auth-Flags
ms-Exch-Auth-Issuer-Name
ms-Exch-Auth-Issuing-Url
ms-Exch-Auth-Linked-Account
ms-Exch-Auth-Metadata-Url
ms-Exch-Auth-Realm
ms-Exch-Mailflow -Policy-Countries
ms-Exch-Mailflow -Policy-Keywords
ms-Exch-Mailflow -Policy-Publisher-Name
ms-Exch-Mailflow -Policy-Transport-Rules-Template-Xml
ms-Exch-Mailflow -Policy-Version
ms-Exch-Public-Folder-EntryId
ms-Exch-Public-Folder-Mailbox
ms-Exch-Public-Folder-Smtp-Address
ms-Exch-Spam-Digest-Frequency
ms-Exch-Spam-Quarantine-Retention
 ms-Exch-Transport-MaxRetriesForLocalSiteShadow
ms-Exch-Transport-MaxRetriesForRemoteSiteShadow
ms-Exch-Transport-Rule-Immutable-Id
ms-Exch-WAC -Discovery-Endpoint
ms-Exch-Anonymous-Throttling-Policy-State-Ex
ms-Exch-Canary-Data-0
ms-Exch-Canary-Data-1
ms-Exch-Canary-Data-2
ms-Exch-Correlation-Id
ms-Exch-EAS -Throttling-Policy-State-Ex
ms-Exch-EWS -Throttling-Policy-State-Ex
ms-Exch-General-Throttling-Policy-State-Ex
ms-Exch-IMAP -Throttling-Policy-State-Ex
ms-Exch-OWA-Throttling-Policy-State-Ex
ms-Exch-POP -Throttling-Policy-State-Ex
ms-Exch-Powershell-Throttling-Policy-State-Ex
ms-Exch-RCA-Throttling-Policy-State-Ex
ms-Exch-Relocate-Tenant-Completion-Target-Vector
ms-Exch-Relocate-Tenant-Flags
ms-Exch-Relocate-Tenant-Safe-Lockdown-Schedule
ms-Exch-Relocate-Tenant-Source-Forest
ms-Exch-Relocate-Tenant-Start-Lockdown
ms-Exch-Relocate-Tenant-Start-Retired
ms-Exch-Relocate-Tenant-Start-Sync
ms-Exch-Relocate-Tenant-Status
ms-Exch-Relocate-Tenant-Target-Forest
ms-Exch-Relocate-Tenant-Transition-Counter
ms-Exch-Sync-Cookie
ms-Exch-Adfs-Authentication-Raw -Configuration
ms-Exch-Service-End-Point-URL
ms-Exch-Sync-Service-Instance-New -Tenant-Max-Version
ms-Exch-Sync-Service-Instance-New -Tenant-Min-Version

MAPI IDs added by Exchange 2013 RTM

The following MAPI IDs are added when you install Exchange 2013 RTM:
36066
36067

Extended rights added by Exchange 2013 RTM

The following table lists the extended rights that are added when you install Exchange 2013 RTM. Installing
Exchange 2013 RTM doesn't modify any existing extended rights.

IDENTIFIER VALUES

CN=ms-Exch-SMTP-Accept-XProxyFrom,CN=Extended- changetype: ntdsSchemaAdd

Rights,<ConfigurationContainerDN>
displayName: Accept XProxyFrom
objectClass: controlAccessRight
rightsGuid: 5bee2b72-50d7-49c7-ba66-39a25daa1e92
validAccesses: 256

Object IDs added by Exchange 2013 RTM

The following attribute object IDs are added when you install Exchange 2013 RTM:
1.2.840.113556.1.4.7000.102.51794
1.2.840.113556.1.4.7000.102.51795
1.2.840.113556.1.4.7000.102.51792
1.2.840.113556.1.4.7000.102.51791
1.2.840.113556.1.4.7000.102.51789
1.2.840.113556.1.4.7000.102.51787
1.2.840.113556.1.4.7000.102.51788
1.2.840.113556.1.4.7000.102.51786
1.2.840.113556.1.4.7000.102.51790
1.2.840.113556.1.4.7000.102.51774
1.2.840.113556.1.4.7000.102.51773
1.2.840.113556.1.4.7000.102.51775
1.2.840.113556.1.4.7000.102.51798
1.2.840.113556.1.4.7000.102.51801
1.2.840.113556.1.4.7000.102.51800
1.2.840.113556.1.4.7000.102.51799
1.2.840.113556.1.4.7000.102.51805
1.2.840.113556.1.4.7000.102.51796
1.2.840.113556.1.4.7000.102.51797
1.2.840.113556.1.4.7000.102.51814
1.2.840.113556.1.4.7000.102.51813
1.2.840.113556.1.4.7000.102.51815
1.2.840.113556.1.4.7000.102.51816
1.2.840.113556.1.4.7000.102.51818
1.2.840.113556.1.4.7000.102.51812
1.2.840.113556.1.4.7000.102.51819
1.2.840.113556.1.4.7000.102.51806
1.2.840.113556.1.4.7000.102.51820
1.2.840.113556.1.4.7000.102.51821
1.2.840.113556.1.4.7000.102.51811
1.2.840.113556.1.4.7000.102.51807
1.2.840.113556.1.4.7000.102.51810
1.2.840.113556.1.4.7000.102.51808
1.2.840.113556.1.4.7000.102.51809
1.2.840.113556.1.4.7000.102.51830
1.2.840.113556.1.4.7000.102.51829
1.2.840.113556.1.4.7000.102.51824
1.2.840.113556.1.4.7000.102.51823
1.2.840.113556.1.4.7000.102.51827
1.2.840.113556.1.4.7000.102.51826
1.2.840.113556.1.4.7000.102.51822
1.2.840.113556.1.4.7000.102.51833
1.2.840.113556.1.4.7000.102.51832
1.2.840.113556.1.4.2183
1.2.840.113556.1.4.2184
1.2.840.113556.1.4.2185
1.2.840.113556.1.4.7000.102.51838
1.2.840.113556.1.4.7000.102.51836
1.2.840.113556.1.4.7000.102.51837
1.2.840.113556.1.4.7000.102.51839
1.2.840.113556.1.4.7000.102.51840
1.2.840.113556.1.4.7000.102.51876
1.2.840.113556.1.4.7000.102.51877
1.2.840.113556.1.4.7000.102.51878
1.2.840.113556.1.4.7000.102.51879
1.2.840.113556.1.4.7000.102.51880
1.2.840.113556.1.4.7000.102.51851
1.2.840.113556.1.4.7000.102.51852
1.2.840.113556.1.4.7000.102.51859
1.2.840.113556.1.4.7000.102.51860
1.2.840.113556.1.4.7000.102.51861
1.2.840.113556.1.4.7000.102.51864
1.2.840.113556.1.4.7000.102.51863
1.2.840.113556.1.4.7000.102.51862
1.2.840.113556.1.4.7000.102.51865
1.2.840.113556.1.4.7000.102.51866
1.2.840.113556.1.4.7000.102.51867
1.2.840.113556.1.4.7000.102.51868
1.2.840.113556.1.4.7000.102.51871
1.2.840.113556.1.4.7000.102.51870
1.2.840.113556.1.4.7000.102.51872
1.2.840.113556.1.4.7000.102.51875
1.2.840.113556.1.4.7000.102.51874
1.2.840.113556.1.4.7000.102.51873
1.2.840.113556.1.4.7000.102.51869
1.2.840.113556.1.4.7000.102.51915
1.2.840.113556.1.4.7000.102.51883
1.2.840.113556.1.4.7000.102.51914
1.2.840.113556.1.4.7000.102.51931
1.2.840.113556.1.4.7000.102.51932
1.2.840.113556.1.4.7000.102.51939
1.2.840.113556.1.4.7000.102.51930
1.2.840.113556.1.4.7000.102.51940
1.2.840.113556.1.4.7000.102.51933
1.2.840.113556.1.4.7000.102.51934
1.2.840.113556.1.4.7000.102.51935
1.2.840.113556.1.4.7000.102.51936
1.2.840.113556.1.4.7000.102.51952
1.2.840.113556.1.4.7000.102.51923
1.2.840.113556.1.4.7000.102.51927
1.2.840.113556.1.4.7000.102.51926
1.2.840.113556.1.4.7000.102.51922
1.2.840.113556.1.4.7000.102.51929
1.2.840.113556.1.4.7000.102.51928
1.2.840.113556.1.4.7000.102.51925
1.2.840.113556.1.4.7000.102.51924
1.2.840.113556.1.4.7000.102.51941
1.2.840.113556.1.4.7000.102.51942
1.2.840.113556.1.4.7000.102.51937
1.2.840.113556.1.4.7000.102.51943
1.2.840.113556.1.4.7000.102.51944
1.2.840.113556.1.4.7000.102.51938
1.2.840.113556.1.4.7000.102.51882
1.2.840.113556.1.4.7000.102.51881
1.2.840.113556.1.4.7000.102.51921
1.2.840.113556.1.4.7000.102.51918
1.2.840.113556.1.4.7000.102.51920
1.2.840.113556.1.4.7000.102.51916
1.2.840.113556.1.4.7000.102.51919
1.2.840.113556.1.4.7000.102.51917
1.2.840.113556.1.4.7000.102.51945
1.2.840.113556.1.4.7000.102.51946
1.2.840.113556.1.4.7000.102.51948
1.2.840.113556.1.4.7000.102.51949
1.2.840.113556.1.4.7000.102.51947
1.2.840.113556.1.4.7000.102.51950
1.2.840.113556.1.4.7000.102.51951
1.2.840.113556.1.4.7000.102.51954
1.2.840.113556.1.4.7000.102.51955
1.2.840.113556.1.4.7000.102.51953
1.2.840.113556.1.4.7000.102.51993
1.2.840.113556.1.4.7000.102.51995
1.2.840.113556.1.4.7000.102.51994
1.2.840.113556.1.4.7000.102.51998
1.2.840.113556.1.4.7000.102.51997
1.2.840.113556.1.4.7000.102.52004
1.2.840.113556.1.4.7000.102.52003
1.2.840.113556.1.4.7000.102.52002
1.2.840.113556.1.4.7000.102.52001
1.2.840.113556.1.4.7000.102.52005
1.2.840.113556.1.4.7000.102.52007
1.2.840.113556.1.4.7000.102.52006
1.2.840.113556.1.4.7000.102.51996
1.2.840.113556.1.4.7000.102.52008
1.2.840.113556.1.4.7000.102.52017
1.2.840.113556.1.4.7000.102.52014
1.2.840.113556.1.4.7000.102.52021
1.2.840.113556.1.4.7000.102.52020
1.2.840.113556.1.4.7000.102.52012
1.2.840.113556.1.4.7000.102.52011
1.2.840.113556.1.4.7000.102.52013
1.2.840.113556.1.4.7000.102.52018
1.2.840.113556.1.4.7000.102.52019
1.2.840.113556.1.4.7000.102.52022
1.2.840.113556.1.4.7000.102.52015
1.2.840.113556.1.4.7000.102.52016
1.2.840.113556.1.4.7000.102.52029
1.2.840.113556.1.4.7000.102.52030
1.2.840.113556.1.4.7000.102.52039
1.2.840.113556.1.4.7000.102.52041
1.2.840.113556.1.4.7000.102.52037
1.2.840.113556.1.4.7000.102.52035
1.2.840.113556.1.4.7000.102.52034
1.2.840.113556.1.4.7000.102.52036
1.2.840.113556.1.4.7000.102.52032
1.2.840.113556.1.4.7000.102.52033
1.2.840.113556.1.4.7000.102.52031
1.2.840.113556.1.4.7000.102.52024
1.2.840.113556.1.4.7000.102.52040
1.2.840.113556.1.4.7000.102.52023
1.2.840.113556.1.4.7000.102.52042
1.2.840.113556.1.4.7000.102.52051
1.2.840.113556.1.4.7000.102.52052
1.2.840.113556.1.4.7000.102.52053
1.2.840.113556.1.4.7000.102.52065
1.2.840.113556.1.4.7000.102.52043
1.2.840.113556.1.4.7000.102.52044
1.2.840.113556.1.4.7000.102.52045
1.2.840.113556.1.4.7000.102.52046
1.2.840.113556.1.4.7000.102.52047
1.2.840.113556.1.4.7000.102.52048
1.2.840.113556.1.4.7000.102.52049
1.2.840.113556.1.4.7000.102.52050
1.2.840.113556.1.4.7000.102.52063
1.2.840.113556.1.4.7000.102.52061
1.2.840.113556.1.4.7000.102.52059
1.2.840.113556.1.4.7000.102.52058
1.2.840.113556.1.4.7000.102.52055
1.2.840.113556.1.4.7000.102.52056
1.2.840.113556.1.4.7000.102.52054
1.2.840.113556.1.4.7000.102.52060
1.2.840.113556.1.4.7000.102.52057
1.2.840.113556.1.4.7000.102.52062
1.2.840.113556.1.4.7000.102.52064
The following class object IDs are added when you install Exchange 2013 RTM:
1.2.840.113556.1.5.7000.62.50161
1.2.840.113556.1.5.7000.62.50162
1.2.840.113556.1.5.7000.62.50163
1.2.840.113556.1.5.7000.62.50166
1.2.840.113556.1.5.7000.62.50164
1.2.840.113556.1.5.7000.62.50165
1.2.840.113556.1.5.7000.62.50167
1.2.840.113556.1.5.7000.62.50170
1.2.840.113556.1.5.7000.62.50172
1.2.840.113556.1.5.7000.62.50171
1.2.840.113556.1.5.7000.62.50173
1.2.840.113556.1.5.7000.62.50178
1.2.840.113556.1.5.7000.62.50174
1.2.840.113556.1.5.7000.62.50176
1.2.840.113556.1.5.7000.62.50177
1.2.840.113556.1.5.7000.62.50187
1.2.840.113556.1.5.7000.62.50188
1.2.840.113556.1.5.7000.62.50190
1.2.840.113556.1.5.7000.62.50189
1.2.840.113556.1.5.7000.62.50191
1.2.840.113556.1.5.7000.62.50192

Indexed attributes added by Exchange 2013 RTM

The following table lists the attributes that are added to the list of indexed attributes when you install Exchange
2013 RTM.

ATTRIBUTE SEARCH FLAG VALUE

ms-Exch-Is-Dirsync-Status-Pending 1

ms-Exch-Archive-GUID 9

ms-Exch-Accepted-Domain-Name 9

ms-Exch-Bypass-Audit 9
ATTRIBUTE SEARCH FLAG VALUE

ms-Exch-Mailbox-Audit-Enable 19

ms-Exch-Default-Public-Folder-Mailbox 19

ms-Exch-OWA-Set-Photo-URL 16

ms-Exch-Organization-Upgrade-Policy-Link 1

ms-DS-GeoCoordinates-Altitude 1

ms-DS-GeoCoordinates-Latitude 1

ms-DS-GeoCoordinates-Longitude 1

ms-Exch-Mailbox-Database-Transport-Flags 16

ms-Exch-Extension-Custom-Attribute-1 1

ms-Exch-Extension-Custom-Attribute-2 1

ms-Exch-Extension-Custom-Attribute-3 1

ms-Exch-Extension-Custom-Attribute-4 1

ms-Exch-Extension-Custom-Attribute-5 1

ms-Exch-Recipient-SoftDeleted-Status 27

ms-Exch-When-Soft-Deleted-Time 17

ms-Exch-Device-Client-Type 1

ms-Exch-Team-Mailbox-Expiration 16

ms-Exch-Team-Mailbox-Expiry-Days 16

ms-Exch-Team-Mailbox-Owners 16
ATTRIBUTE SEARCH FLAG VALUE

ms-Exch-Team-Mailbox-SharePoint-Linked-By 16

ms-Exch-Team-Mailbox-SharePoint-Url 16

ms-Exch-Team-Mailbox-Show-In-Client-List 16

ms-Exch-Home-MDB-SL 1

ms-Exch-Home-MTA-SL 1

ms-Exch-Mailbox-Move-Source-Archive-MDB-Link-SL 1

ms-Exch-Mailbox-Move-Source-MDB-Link-SL 1

ms-Exch-Mailbox-Move-Target-Archive-MDB-Link-SL 1

ms-Exch-Organization-Upgrade-Policy-Link-SL 1

ms-Exch-Previous-Archive-Database-SL 8

ms-Exch-Previous-Home-MDB-SL 8

ms-Exch-Auth-Issuer-Name 1

ms-Exch-Auth-Application-Identifier 1

ms-Exch-Transport-Rule-Immutable-Id 1

ms-Exch-Public-Folder-EntryId 24

ms-Exch-Public-Folder-Mailbox 24

ms-Exch-Public-Folder-Smtp-Address 24

ms-Exch-Relocate-Tenant-Completion-Target-Vector 8

ms-Exch-Relocate-Tenant-Flags 8
 ATTRIBUTE SEARCH FLAG VALUE

ms-Exch-Relocate-Tenant-Safe-Lockdown-Schedule 8

ms-Exch-Relocate-Tenant-Start-Lockdown 8

ms-Exch-Relocate-Tenant-Start-Retired 8

ms-Exch-Relocate-Tenant-Start-Sync 8

ms-Exch-Relocate-Tenant-Transition-Counter 8

ms-Exch-Sync-Cookie 8

ms-Exch-Relocate-Tenant-Source-Forest 9

ms-Exch-Relocate-Tenant-Status, 9

ms-Exch-Relocate-Tenant-Target-Forest 9

Global catalog attributes added by Exchange 2013 RTM

The following global catalog attributes are added by Exchange 2013 RTM:
ms-Exch-Dirsync-Authority-Metadata
ms-Exch-Dirsync-Status
ms-Exch-Dirsync-Status-Ack
ms-Exch-Edge-Sync-Config-Flags
ms-Exch-Is-Dirsync-Status-Pending
ms-Exch-Localization-Flags
ms-Exch-Previous-Archive-Database
ms-Exch-RoleGroup-Type
ms-Exch-HAB -Root-Department-Link
ms-Exch-Default-Public-Folder-Mailbox
ms-Exch-Team-Mailbox-Expiration
ms-Exch-Team-Mailbox-Expiry-Days
ms-Exch-Team-Mailbox-Owners
ms-Exch-Team-Mailbox-SharePoint-Linked-By
ms-Exch-Team-Mailbox-SharePoint-Url
ms-Exch-Team-Mailbox-Show -In-Client-List
ms-Exch-Recipient-SoftDeleted-Status
ms-Exch-When-Soft-Deleted-Time
ms-Exch-Device-Client-Type
ms-Exch-Extension-Custom-Attribute-1
ms-Exch-Extension-Custom-Attribute-2
ms-Exch-Extension-Custom-Attribute-3
ms-Exch-Extension-Custom-Attribute-4
ms-Exch-Extension-Custom-Attribute-5
ms-Exch-Archive-Database-Link-SL
ms-Exch-Disabled-Archive-Database-Link-SL
ms-Exch-Home-MDB -SL
ms-Exch-Home-MTA-SL
ms-Exch-Mailbox-Move-Source-Archive-MDB -Link-SL
ms-Exch-Mailbox-Move-Source-MDB -Link-SL
ms-Exch-Mailbox-Move-Storage-MDB -Link-SL
ms-Exch-Mailbox-Move-Target-Archive-MDB -Link-SL
ms-Exch-Mailbox-Move-Target-MDB -Link-SL
ms-Exch-Previous-Archive-Database-SL
ms-Exch-Previous-Home-MDB -SL
ms-Exch-RMS -Computer-Accounts-Link-SL
ms-Exch-Group-Member-Count
ms-Exch-Group-External-Member-Count
ms-Exch-Correlation-Id
ms-Exch-Relocate-Tenant-Completion-Target-Vector,
ms-Exch-Relocate-Tenant-Flags
ms-Exch-Relocate-Tenant-Safe-Lockdown-Schedule
ms-Exch-Relocate-Tenant-Source-Forest
ms-Exch-Relocate-Tenant-Start-Lockdown
ms-Exch-Relocate-Tenant-Start-Retired
ms-Exch-Relocate-Tenant-Start-Sync
ms-Exch-Relocate-Tenant-Status
ms-Exch-Relocate-Tenant-Target-Forest
ms-Exch-Relocate-Tenant-Transition-Counter
ms-Exch-Sync-Cookie
 Disjoint namespace scenarios
5/21/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic provides information about the concept of disjoint namespaces and the supported scenarios for
deploying Microsoft Exchange 2013 in a domain that has a disjoint namespace.

DNS and NetBIOS domain names

First, some background. Every computer that is on the Internet has a Domain Name System (DNS ) name. This is
also known as the machine name or host name. Every computer running the Windows operating system with
networking capabilities also has a NetBIOS name.
A computer running Windows in an Active Directory domain has both a DNS domain name and a NetBIOS
domain name, as follows:
DNS domain name: The DNS domain name consists of one or more subdomains separated by a dot (.)
and is terminated by a top-level domain name. For example, in the DNS domain name corp.contoso.com,
the subdomains are corp and contoso and the top-level domain name is com.
NetBIOS domain name: Typically, the NetBIOS domain name is the subdomain of the DNS domain
name. For example, if the DNS domain name is contoso.com, the NetBIOS domain name is contoso. If the
DNS domain name is corp.contoso.com, the NetBIOS domain name is corp.

NOTE
To find DNS and NetBIOS information for computers running Windows Server 2008, see View DNS and NetBIOS name-
related information of a computer running Windows Server 2008.

A computer in an Active Directory domain also has a primary DNS suffix and can have additional DNS suffixes. By
default, the primary DNS suffix is the same as the DNS domain name. For detailed steps about how to change the
primary DNS suffix, see the procedures later in this topic.
You define the DNS domain name and NetBIOS domain name of an Active Directory domain when you configure
the first domain controller in the domain. For more information about configuring domain controllers, see Domain
Controller Roles and Active Directory Domain Services Overview.

Disjoint namespaces
In most domain topologies, the primary DNS suffix of the computers in the domain is the same as the DNS
domain name.
In some cases, you may require these namespaces to be different. This is called a disjoint namespace. For example,
a merger or acquisition may cause you to have a topology with a disjoint namespace. In addition, if DNS
management in your company is split between administrators who manage Active Directory and administrators
who manage networks, you may need to have a topology with a disjoint namespace.
A disjoint namespace scenario is one in which the primary DNS suffix of a computer doesn't match the DNS
domain name where that computer resides. The computer with the primary DNS suffix that doesn't match is said
to be disjoint. Another disjoint namespace scenario occurs if the NetBIOS domain name of a domain controller
doesn't match the DNS domain name.
Exchange 2013 and disjoint namespaces
Exchange 2013 supports the following three scenarios for deploying Exchange in a domain that has a disjoint
namespace:
Primary DNS suffix and DNS domain name are different: The primary DNS suffix of the domain
controller isn't the same as the DNS domain name. Computers that are members of the domain can be
either disjoint or not disjoint.
Member computer is disjoint: A member computer in an Active Directory domain is disjoint, even
though the domain controller is not disjoint.
NetBIOS name of domain controller differs from subdomain of its DNS domain name: The
NetBIOS domain name of the domain controller isn't the same as the subdomain of the DNS domain name
of that domain controller.
These scenarios are detailed in the following sections.

NOTE
It's supported to run Exchange 2013 in the disjoint namespace scenarios described in this topic. However, if you have a
disjoint namespace scenario that isn't one of the scenarios described in this topic, you must work with Microsoft Services to
deploy Exchange 2013. For more information, see Microsoft Services.

Scenario: Primary DNS suffix and DNS domain name are different
In this scenario, the primary DNS suffix of the domain controller isn't the same as the DNS domain name. The
domain controller is disjoint in this scenario. Computers that are members of the domain, including Exchange
servers and Microsoft Outlook client computers, can have a primary DNS suffix that either matches the primary
DNS suffix of the domain controller or matches the DNS domain name.

Scenario: Member computer is disjoint

In this scenario, the primary DNS suffix of a member computer on which Exchange 2013 is installed isn't the same
as the DNS domain name, even though the primary DNS suffix of the domain controller is the same as the DNS
domain name. In this scenario, you have a domain controller that isn't disjoint and a member computer that is
disjoint. Member computers that are running Outlook can have a primary DNS suffix that either matches the
primary DNS suffix of the disjoint Exchange server or matches the DNS domain name.

Scenario: NetBIOS name of domain controller differs from subdomain

of its DNS domain name
In this scenario, the NetBIOS domain name of the domain controller isn't the same as the DNS domain name of
the same domain controller.
NetBIOS domain name doesn't match DNS domain name
Allow Exchange 2013 servers to access domain controllers that are
disjoint
To allow Exchange 2013 servers to access domain controllers that are disjoint, you must modify the msDS -
AllowedDNSSuffixes Active Directory attribute on the domain object container. You must add both of the DNS
suffixes to the attribute. For detailed steps about how to modify the attribute, see The computer's primary DNS
suffix does not match the FQDN of the domain where it resides.
In addition, to make sure that the DNS suffix search list contains all DNS namespaces that are deployed within the
organization, you must configure the search list for each computer in the domain that is disjoint. The list of
namespaces should include not only the primary DNS suffix of the domain controller and the DNS domain name,
but also any additional namespaces for other servers with which Exchange may interoperate (such as monitoring
servers or servers for third-party applications). You can do this by setting Group Policy for the domain. For more
information about Group Policy, see the following topics:
Group Policy Frequently Asked Questions (FAQ )
New group policies for DNS in Windows Server 2003
Group Policy
For detailed steps about how to configure the DNS suffix search list Group Policy, see Configure the DNS suffix
search list for a disjoint namespace.

View DNS and NetBIOS name-related information of a computer

running Windows Server 2008
1. Click Start, right-click Computer, and then click Properties.
2. In System, the DNS host name and primary DNS suffix are displayed under Computer name, domain,
and workgroup settings next to Full computer name. The DNS domain name is displayed next to
Domain.
3. Click Change settings.
4. In System Properties, on the Computer Name tab, click Change.
5. In Computer Name/Domain Changes, click More. The primary DNS suffix is displayed under Primary
DNS suffix of this computer. The NetBIOS computer name is displayed under NetBIOS computer
name.
To change the primary DNS suffix, type the new primary DNS suffix under Primary DNS suffix of this
computer, and then click OK.
6. From a Command Prompt window, type set. The variable USERDNSDOMAIN displays the DNS domain
name. The variable USERDOMAIN displays the NetBIOS domain name.
 Configure the DNS suffix search list for a disjoint
namespace
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic explains how to use the Group Policy Management console (GPMC ) to configure the Domain Name
System (DNS ) suffix search list. In some Microsoft Exchange 2013 scenarios, if you have a disjoint namespace, you
must configure the DNS suffix search list to include multiple DNS suffixes.

What do you need to know before you begin?

Estimated time to complete: 10 minutes
To perform this procedure, the account you use must be delegated membership in the Domain Admins
group.
Confirm that you have installed .NET Framework 3.0 on the computer on which you will install the GPMC.

NOTE
The current version of the GPMC that you can download from the Microsoft Download Center operates on the 32-
bit versions of the Windows Server 2003 and Windows XP operating systems and can remotely manage Group Policy
objects on 32-bit and 64-bit domain controllers. This version of the GPMC doesn't include a 64-bit version, and the
32-bit version doesn't run on 64-bit platforms. The 32-bit version of Windows Server 2008 and the 32-bit version of
Windows Vista both include a 32-bit version of the GPMC. The 64-bit version of Windows Server 2008 and the 64-
bit version of Windows Vista both include a 64-bit version of the GPMC.

For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the GPMC to configure the DNS suffix search list

1. On a 32-bit computer in your domain, install GPMC with Service Pack 1 (SP1). For download information,
see Group Policy Management Console with Service Pack 1.

NOTE
If you have a computer in your domain running Windows Server 2008 or Windows Vista, you can skip this step.

2. Click Start > Programs > Administrative Tools > Group Policy Management.
3. In Group Policy Management, expand the forest and the domain in which you will apply Group Policy.
Right-click Group Policy Objects, and then click New.
4. In New GPO, type a name for the policy, and then click OK.
5. Right-click the new policy that you created in Step 4, and then click Edit.
6. In Group Policy Management Editor, expand Computer Configuration, expand Policies, expand
Administrative Templates, expand Network, and then click DNS Client.
7. Right-click DNS Suffix Search List, click All Tasks, and then click Edit.
8. On the DNS Suffix Search List Properties page, select Enabled. In the DNS Suffixes box, type the
primary DNS suffix of the disjoint computer, the DNS domain name, and any additional namespaces for
other servers with which Exchange may interoperate, such as monitoring servers or servers for third-party
applications. Click OK.
9. In Group Policy Management, expand Group Policy Objects, and then select the policy that you created
in Step 4. On the Scope tab, scope the policy so that it applies to only the computers that are disjoint.

How do you know this worked?

After you install Exchange 2013, verify that you can send email messages inside and outside your organization.

For more information

Windows Server Group Policy
Group Policy
Disjoint namespace scenarios
 Exchange 2013 system requirements
5/28/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

Learn about the Exchange 2013 requirements that you need to know before you install Exchange 2013. For
example, you'll learn about the hardware, network, and operating system requirements.
Before you install Microsoft Exchange Server 2013, we recommend that you review this topic to ensure that
your network, hardware, software, clients, and other elements meet the requirements for Exchange 2013. In
addition, make sure you understand the coexistence scenarios that are supported for Exchange 2013 and
earlier versions of Exchange.

Supported coexistence scenarios

The following table lists the scenarios in which coexistence between Exchange 2013 and earlier versions of
Exchange is supported.
Coexistence of Exchange 2013 and earlier versions of Exchange Server
EXCHANGE VERSION EXCHANGE ORGANIZATION COEXISTENCE

Exchange Server 2003 and earlier versions Not supported

Exchange 2007 Supported with the following minimum versions of

Exchange:
1Update Rollup 10 for Exchange 2007 Service
Pack 3 (SP3) on all Exchange 2007 servers in the
organization, including Edge Transport servers.
Exchange 2013 Cumulative Update 2 (CU2) or
later on all Exchange 2013 servers in the
organization.

Exchange 2010 Supported with the following minimum versions of

Exchange:
2 Exchange 2010 SP3 on all Exchange 2010
servers in the organization, including Edge
Transport servers.
Exchange 2013 CU2 or later on all Exchange
2013 servers in the organization.
 EXCHANGE VERSION EXCHANGE ORGANIZATION COEXISTENCE

Mixed Exchange 2010 and Exchange 2007 organization Supported with the following minimum versions of
Exchange:
1Update Rollup 10 for Exchange 2007 SP3 on all
Exchange 2007 servers in the organization,
including Edge Transport servers.
2 Exchange 2010 SP3 on all Exchange 2010
servers in the organization, including Edge
Transport servers.
Exchange 2013 CU2 or later on all Exchange
2013 servers in the organization.

1 If you want to create an EdgeSync Subscription between an Exchange 2007 Hub Transport server and an
Exchange 2013 SP1 Edge Transport server, you need to install Exchange 2007 SP3 Update Rollup 13 or later
on the Exchange 2007 Hub Transport server.
2 If you want to create an EdgeSync Subscription between an Exchange 2010 Hub Transport server and an
Exchange 2013 SP1 Edge Transport server, you need to install Exchange 2010 SP3 Update Rollup 5 or later on
the Exchange 2010 Hub Transport server.

Supported hybrid deployment scenarios

Exchange 2013 supports hybrid deployments with Office 365 tenants that have been upgraded to the latest
version of Office 365. For more information about specific hybrid deployments, see Hybrid deployment
prerequisites.

Network and directory servers

The following table lists the requirements for the network and the directory servers in your Exchange 2013
organization.
Network and directory server requirements for Exchange 2013

COMPONENT REQUIREMENT
COMPONENT REQUIREMENT

Schema master By default, the schema master runs on the first Active
Directory domain controller installed in a forest. The
schema master must be running one of the following:
Windows Server 2012 R2 Standard or
Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard or Enterprise
Windows Server 2008 R2 Datacenter RTM or
later
Windows Server 2008 Standard or Enterprise
(32-bit or 64-bit)
Windows Server 2008 Datacenter RTM or later
Windows Server 2003 Standard Edition with
Service Pack 2 (SP2) or later (32-bit or 64-bit)
Windows Server 2003 Enterprise Edition with
SP2 or later (32-bit or 64-bit)

Global catalog server In each Active Directory site where you plan to install
Exchange 2013, you must have at least one global
catalog server running one of the following:
Windows Server 2012 R2 Standard or
Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard or Enterprise
Windows Server 2008 R2 Datacenter RTM or
later
Windows Server 2008 Standard or Enterprise
(32-bit or 64-bit)
Windows Server 2008 Datacenter RTM or later
Windows Server 2003 Standard Edition with
Service Pack 2 (SP2) or later (32-bit or 64-bit)
Windows Server 2003 Enterprise Edition with
SP2 or later (32-bit or 64-bit)
For more information about global catalog servers, see
What is the Global Catalog.
 COMPONENT REQUIREMENT

Domain controller In each Active Directory site where you plan to install
Exchange 2013, you must have at least one writeable
domain controller running one of the following:
Windows Server 2012 R2 Standard or
Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard or Enterprise
SP1 or later
Windows Server 2008 R2 Datacenter RTM or
later
Windows Server 2008 Standard or Enterprise
SP1 or later (32-bit or 64-bit)
Windows Server 2008 Datacenter RTM or later
Windows Server 2003 Standard Edition with
Service Pack 2 (SP2) or later (32-bit or 64-bit)
Windows Server 2003 Enterprise Edition with
SP2 or later (32-bit or 64-bit)

Active Directory forest Active Directory must be at Windows Server 2003

forest functionality mode or higher2.

DNS namespace support Exchange 2013 supports the following domain name
system (DNS) namespaces:
Contiguous
Noncontiguous
Single label domains
Disjoint
For more information about DNS namespaces
supported by Exchange, see Microsoft Knowledge Base
article 2269838, Microsoft Exchange compatibility with
Single Label Domains, Disjoined Namespaces, and
Discontiguous Namespaces.

IPv6 support In Exchange 2013, IPv6 is supported only when IPv4 is

also installed and enabled. If Exchange 2013 is deployed
in this configuration, and the network supports IPv4
and IPv6, all Exchange servers can send data to and
receive data from devices, servers, and clients that use
IPv6 addresses. For more information, see IPv6 support
in Exchange 2013.

1 Windows Server 2012 R2 is supported only with Exchange 2013 SP1 or later.
2 Windows Server 2012 R2 forest functionality mode is supported only with Exchange 2013 SP1 or later.

Directory server architecture

The use of 64-bit Active Directory domain controllers increases directory service performance for Exchange
2013.

NOTE
In multi-domain environments, on Windows Server 2008 domain controllers that have the Active Directory language
locale set to Japanese, your servers might not receive some attributes that are stored on an object during inbound
replication. For more information, see Microsoft Knowledge Base article 949189, A Windows Server 2008 domain
controller that is configured with the Japanese language locale may not apply updates to attributes on an object during
inbound replication.

Installing Exchange 2013 on directory servers

For security and performance reasons, we recommend that you install Exchange 2013 only on member
servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer
running Exchange 2013. After Exchange 2013 is installed, changing its role from a member server to a
directory server, or vice versa, isn't supported.

Hardware
The recommended hardware requirements for Exchange 2013 servers vary depending on a number of factors
including the server roles that are installed and the anticipated load that will be placed on the servers.
For detailed information on how to properly size and configure your deployment, see Exchange 2013 Sizing
and Configuration Recommendations.
For information about deploying Exchange in a virtualized environment, see Exchange 2013 virtualization.
Hardware requirements for Exchange 2013

COMPONENT REQUIREMENT NOTES

Processor x64 architecture-based See the "Operating system"

computer with Intel section later in this topic for
processor that supports supported operating systems.
Intel 64 architecture
(formerly known as Intel
EM64T)
AMD processor that
supports the AMD64
platform
Intel Itanium IA64
processors not supported

Memory Varies depending on Exchange None.

roles that are installed:
Mailbox 8GB minimum
Client Access 4GB
minimum
Mailbox and Client
Access combined 8GB
minimum
Edge Transport 4GB
minimum
 COMPONENT REQUIREMENT NOTES

Paging file size The page file size minimum and For detailed pagefile
maximum must be set to physical recommendations, see the
RAM plus 10 MB, to a maximum "Pagefile" section in Exchange
size of 32778MB if you're using 2013 Sizing and Configuration
more than 32GB of RAM. Recommendations.

Disk space At least 30 GB on the drive For detailed information on

on which you install storage recommendations, see
Exchange Exchange 2013 storage
configuration options.
An additional 500 MB of
available disk space for
each Unified Messaging
(UM) language pack that
you plan to install
200 MB of available disk
space on the system drive
A hard disk that stores the
message queue database
on with at least 500 MB of
free space.

Drive DVD-ROM drive, local or network None.

accessible

Screen resolution 1024 x 768 pixels or higher None.

File format Disk partitions formatted as NTFS None.

file systems, which applies to the
following partitions:
System partition
Partitions that store
Exchange binary files or
files generated by
Exchange diagnostic
logging
Disk partitions containing the
following types of files can be
formatted as ReFS:
Partitions containing
transaction log files
Partitions containing
database files
Partitions containing
content indexing files

Operating system
The following table lists the supported operating systems for Exchange 2013.
 IMPORTANT
We don't support the installation of Exchange 2013 on a computer that's running in Windows Server Core mode. The
computer must be running the full installation of Windows Server. If you want to install Exchange 2013 on a computer
that's running in Windows Server Core mode, you must convert the server to a full installation of Windows Server by
doing one of the following:
Windows Server 2008 R2 Reinstall Windows Server and select the Full Installation option.
Windows Server 2012 R2 or Windows Server 2012 Convert your Windows Server Core mode server to a
full installation by running the following command.

Install-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart

Supported operating systems for Exchange 2013

COMPONENT REQUIREMENT

Mailbox, Client Access, and Edge Transport server roles One of the following:
Windows Server 2012 R2 Standard or
Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard with Service
Pack 1 (SP1)
Windows Server 2008 R2 Enterprise with Service
Pack 1 (SP1)
Windows Server 2008 R2 Datacenter RTM or
later

Management tools One of the following:

Windows Server 2012 R2 Standard or
Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard with SP1
Windows Server 2008 R2 Enterprise with SP1
Windows Server 2008 R2 Datacenter RTM or
later
64-bit edition of Windows 8.12
64-bit edition of Windows 8
64-bit edition of Windows 7 with Service Pack 1

1 Windows Server 2012 R2 is supported only with Exchange 2013 SP1 or later.
2 Windows 8.1 is supported only with Exchange 2013 SP1 or later.
Supported Windows Management Framework versions for Exchange 2013
Exchange 2013 only supports the version of Windows Management Framework that's built into the release of
Windows that you're installing Exchange on. Don't install versions of Windows Management Framework that
are made available as stand-alone downloads on servers running Exchange.
.NET Framework
We strongly recommend that you use the latest version of .NET Framework that's supported by the release of
Exchange you're installing.

.NET FRAMEWORK .NET FRAMEWORK .NET FRAMEWORK .NET FRAMEWORK

EXCHANGE VERSION 4.7.1 4.6.2 4.6.1 4.5.2

Exchange 2013 X X
CU19

Exchange 2013 X
CU16 - CU18

Supported clients
Exchange 2013 supports the following versions of Outlook and Entourage for Mac:
Outlook 2016
Outlook 2013
Outlook 2010
Outlook 2007
Entourage 2008 for Mac, Web Services Edition
Outlook for Mac for Office 365
Outlook for Mac 2011
For a list of Outlook releases that Exchange supports, see Outlook Updates.

IMPORTANT
We strongly recommend that you install the latest available service packs and updates available so that your users
receive the best possible experience when connecting to Exchange.

Outlook clients earlier than Outlook 2007 are not supported. Email clients on Mac operating systems that
require DAV, such as Entourage 2008 for Mac RTM and Entourage 2004, are not supported.
Outlook Web App supports several browsers on a variety of operating systems and devices. For detailed
information, see What's new for Outlook Web App in Exchange 2013.
 Exchange 2013 prerequisites
6/6/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic provides the steps for installing the necessary Windows Server 2012 R2, Windows Server 2012 and
Windows Server 2008 R2 with Service Pack 1 (SP1) operating system prerequisites for the Microsoft
Exchange 2013 Mailbox, Client Access, and Edge Transport server roles. It also provides the prerequisites
required to install the Exchange 2013 management tools on Windows 8, Windows 8.1, and Windows 7 client
computers.
What do you need to know before you begin?
Active Directory preparation
Windows Server 2012 R2 and Windows Server 2012 prerequisites
Mailbox or Client Access server roles
Edge Transport server role
Windows Server 2008 R2 SP1 prerequisites
Mailbox or Client Access server roles
Edge Transport server role
Windows 7 prerequisites (admin tools only)
Windows 8 and Windows 8.1 prerequisites (admin tools only)

What do you need to know before you begin?

The information in this topic is applicable to Service Pack 1 and later versions of Exchange 2013.
The Edge Transport server role is available starting with Exchange 2013 SP1.
Make sure that the functional level of your forest is at least Windows Server 2003, and that the schema
master is running Windows Server 2003 with Service Pack 2 or later. For more information about the
Windows functional level, see Managing Domains and Forests.
The full installation option of Windows Server 2012 R2, Windows Server 2012 and Windows Server
2008 R2 SP1 must be used for all servers running Exchange 2013 server roles or management tools.
You must first join the computer to the appropriate internal Active Directory forest and domain.
Some prerequisites require you to reboot the server to complete installation.
Install the latest Windows updates on your computer. For more information, see Deployment
security checklist.
 NOTE
If you're installing the Mailbox server role and you intend for the server to be a member of a database
availability group (DAG), you must be running Windows Server 2012 R2 Standard or Datacenter Edition,
Windows Server 2012 Standard or Datacenter Edition, or Windows Server 2008 R2 SP1 Enterprise
Edition. Windows Server 2008 R2 SP 1 Standard Edition doesn't support the features needed for DAGs.
You can't upgrade Windows when Exchange is installed on the server.
To upgrade to Microsoft Unified Communications Managed API (UCMA) 4.0, you must first uninstall any
previous versions of UCMA that are installed by using Add/Remove programs.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Active Directory preparation

The computer you want to use to prepare Active Directory for Exchange 2013 has specific prerequisites that
must be met.
Install the following software, in the order shown, on the computer that will be used to prepare Active
Directory:
1. .NET Framework 4.7.1
2. Windows Management Framework 4.0 (included with Windows Server 2012 R2)
After you've installed the software listed above, complete the following steps to install the Remote Tools
Administration Pack. After you've installed the Remote Tools Administration Pack you'll be able to use the
computer to prepare Active Directory. For more information about preparing Active Directory, see Prepare
Active Directory and domains.
1. Open Windows PowerShell.
2. Install the Remote Tools Administration Pack.
On a Windows Server 2012 R2 or Windows Server 2012 computer, run the following command.

Install-WindowsFeature RSAT-ADDS

On a Windows Server 2008 R2 SP1 computer, run the following command.

Add-WindowsFeature RSAT-ADDS

Windows Server 2012 R2 and Windows Server 2012 prerequisites

The prerequisites that are needed to install Exchange 2013 on a Windows Server 2012 R2 or Windows Server
2012 computer depends on which Exchange roles you want to install. Read the section below that matches the
roles you want to install.

Mailbox or Client Access server roles

Follow the instructions in this section to install the prerequisites on Windows Server 2012 R2 or Windows
Server 2012 computers where you want to do one of the following:
 Install only the Mailbox server role on a computer.
Install only the Client Access server role on a computer.
Install both the Mailbox and Client Access server roles on the same computer.
Do the following to install the required Windows roles and features:
1. Open Windows PowerShell.
2. Run the following command to install the required Windows components.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-

HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-
PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth,
Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-
Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase,
Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-
Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

After you've installed the operating system roles and features, install the following software in the order
shown:
1. .NET Framework 4.7.1

IMPORTANT
Exchange 2013 CU21 require .NET Framework 4.7.1. Upgrade your servers to .NET Framework 4.7.1 before you
install Exchange 2013 CU21 or you'll receive an error. If .NET Framework 4.6.2 is installed on your Exchange
servers, upgrade your servers to Exchange 2013 CU20 before installing .NET Framework 4.7.1.

2. Windows Management Framework 4.0 (included with Windows Server 2012 R2)
3. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
4. Visual C++ Redistributable Package for Visual Studio 2012
5. Visual C++ Redistributable Package for Visual Studio 2013

NOTE
Here you'll find an overview of the latest supported Visual C++ Redistributable versions

Edge Transport server role

Follow the instructions in this section to install the prerequisites on Windows Server 2012 R2 or Windows
Server 2012 computers where you want to install the Edge Transport server role on a computer.
Do the following to install the required Windows roles and features:
1. Open Windows PowerShell.
2. Run the following command to install the required Windows components.

Install-WindowsFeature ADLDS

Install the version of Microsoft .NET Framework that corresponds to the version of Exchange 2013 you're
installing:
1. .NET Framework 4.7.1

IMPORTANT
Exchange 2013 CU21 require .NET Framework 4.7.1. Upgrade your servers to .NET Framework 4.7.1 before you
install Exchange 2013 CU21 or you'll receive an error. If .NET Framework 4.6.2 is installed on your Exchange
servers, upgrade your servers to Exchange 2013 CU20 before installing .NET Framework 4.7.1.

2. Windows Management Framework 4.0 (included with Windows Server 2012 R2)
3. Visual C++ Redistributable Package for Visual Studio 2012

NOTE
Here you'll find an overview of the latest supported Visual C++ Redistributable versions

Windows Server 2008 R2 SP1 prerequisites

The prerequisites that are needed to install Exchange 2013 on a Windows Server 2008 R2 SP1 computer
depends on which Exchange roles you want to install. Read the section below that matches the roles you want
to install.

Mailbox or Client Access server roles

Follow the instructions in this section to install the prerequisites on Windows Server 2008 R2 SP1 computers
where you want to do one of the following:
Install only the Mailbox server role on a computer.
Install only the Client Access server role on a computer.
Install both the Mailbox and Client Access server roles on the same computer.
Do the following to install the required Windows roles and features:
1. Open Windows PowerShell.
2. Run the following command to load the Server Manager module.

Import-Module ServerManager

3. Run the following command to install the required Windows components.

Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy,

RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth,
Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-
Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase,
Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-
Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, RSAT-ADDS

After you've installed the operating system roles and features, install the following software in the order
shown:
1. .NET Framework 4.7.1
 IMPORTANT
Exchange 2013 CU21 require .NET Framework 4.7.1. Upgrade your servers to .NET Framework 4.7.1 before you
install Exchange 2013 CU21 or you'll receive an error. If .NET Framework 4.6.2 is installed on your Exchange
servers, upgrade your servers to Exchange 2013 CU20 before installing .NET Framework 4.7.1.

2. Windows Management Framework 4.0

3. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
4. Visual C++ Redistributable Package for Visual Studio 2012
5. Visual C++ Redistributable Package for Visual Studio 2013

NOTE
Here you'll find an overview of the latest supported Visual C++ Redistributable versions

6. Microsoft Knowledge Base article KB974405 (Windows Identity Foundation)

7. Knowledge Base article KB2619234 (Enable the Association Cookie/GUID that is used by RPC over
HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2)
8. Knowledge Base article KB2533623 (Insecure library loading could allow remote code execution)

NOTE
This hotfix may already be installed if you've configured Windows Update to install security updates on your
computer.

Edge Transport server role

Follow the instructions in this section to install the prerequisites on Windows Server 2008 R2 SP1 computers
where you want to install the Edge Transport server role on a computer.
Do the following to install the required Windows roles and features:
1. Open Windows PowerShell.
2. Run the following command to load the Server Manager module.

Import-Module ServerManager

3. Run the following command to install the required Windows components.

Add-WindowsFeature NET-Framework, ADLDS

After you've installed the operating system roles and features, install the following software in the order
shown:
1. .NET Framework 4.7.1
 IMPORTANT
Exchange 2013 CU21 require .NET Framework 4.7.1. Upgrade your servers to .NET Framework 4.7.1 before you
install Exchange 2013 CU21 or you'll receive an error. If .NET Framework 4.6.2 is installed on your Exchange
servers, upgrade your servers to Exchange 2013 CU20 before installing .NET Framework 4.7.1.

2. Windows Management Framework 4.0

3. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
4. Visual C++ Redistributable Package for Visual Studio 2012

NOTE
Here you'll find an overview of the latest supported Visual C++ Redistributable versions

Windows 7 prerequisites (admin tools only)

Follow the instructions in this section to install the prerequisites on domain-joined Windows 7 64-bit
computers where you want to install the Exchange management tools.
1. Open Control Panel, and then select Programs.
2. Click Turn Windows features on or off.
3. Navigate to Internet Information Services > Web Management Tools > IIS 6 Management
Compatibility.
4. Select the check box for IIS 6 Management Console, and then click OK.
After you've installed the operating system features, install the following software in the order shown:
1. .NET Framework 4.7.1
2. Windows Management Framework 4.0
3. Knowledge Base article KB974405 (Windows Identity Foundation)

Windows 8 and Windows 8.1 prerequisites (admin tools only)

.NET Framework 4.7.1
 Prepare Active Directory and domains
6/27/2019 • 12 minutes to read • Edit Online

Applies to: Exchange Server 2013

Before you install Microsoft Exchange Server 2013, you need to prepare your Active Directory forest and its
domains. Exchange needs to prepare Active Directory so that it can store information about your users'
mailboxes and the configuration of Exchange servers in the organization. If you aren't familiar with Active
Directory forests or domains, check out Active Directory Domain Services Overview.

NOTE
Whether this is the first installation of Exchange in your environment, or you already have earlier versions of Exchange
Server running, you need to prepare Active Directory for Exchange 2013. You can see Exchange 2013 Active Directory
schema changes for details on new schema classes and attributes that Exchange 2013 adds to Active Directory, including
those made by Service Packs (SPs) and Cumulative Updates (CUs).

There are a couple of ways you can prepare Active Directory for Exchange. The first is to let the Exchange 2013
Setup wizard do it for you. If you don't have a large Active Directory deployment, and you don't have a separate
team that manages Active Directory, we recommend using the wizard. The account you use will need to be a
member of both the Schema Admins and Enterprise Admins security groups. For more information about how
to use the Setup wizard, check out Install Exchange 2013 using the Setup wizard.
If you have a large Active Directory deployment, or if a separate team manages Active Directory, this topic is for
you. Following the steps in this topic gives you much more control over each stage of preparation, and who can
do each step. For example, Exchange administrators might not have the permissions needed to extend the
Active Directory schema.
What do you need to know before you begin?
1. Extend the Active Directory schema
2. Prepare Active Directory
3. Prepare Active Directory domains
How do you know this worked?
Curious about what's happening when Active Directory is being prepared for Exchange? Check out What
changes in Active Directory when Exchange 2013 is installed?

What do you need to know before you begin?

Estimated time to complete: 10-15 minutes or more (not including Active Directory replication),
depending on organization size and the number of child domains.
The computer you use to run these steps needs to meet the Exchange 2013 system requirements. Also,
your Active Directory forest needs to meet the requirements in the "Network and directory servers"
section in Exchange 2013 system requirements.
If your organization has multiple Active Directory domains, we recommend the following:
Do the steps below from an Active Directory site that has an Active Directory server from every
domain.
 Install the first Exchange server in an Active Directory site with a writeable global catalog server
from every domain.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

1. Extend the Active Directory schema

The first step in getting your organization ready for Exchange 2013 is to extend the Active Directory schema.
Exchange stores a lot of information in Active Directory but before it can do that, it needs to add and update
classes, attributes, and other items. If you're curious about what's changed when your schema is extended, check
out Exchange 2013 Active Directory schema changes.
Before you extend your schema, there are a few things to keep in mind:
The account you're logged in as needs to be a member of the Schema Admins and Enterprise Admins
security groups.
The computer where you'll run the command to extend the schema needs to be in the same Active
Directory domain and site as the schema master.
If you use the DomainController parameter, make sure to use the name of the domain controller that's
the schema master.
The only way to extend the schema for Exchange is to use the steps in this topic or use Exchange 2013
Setup. Other ways of extending the schema aren't supported.

TIP
If you don't have a separate team that manages your Active Directory schema, you can skip this step and go directly to
Step 2. Prepare Active Directory. If the schema isn't extended in step 1, the commands in step 2 will extend the schema for
you. If you decide to skip step 1, the information you need to keep in mind above still applies.

When you're ready, do the following to extend your Active Directory schema. If you have multiple Active
Directory forests, make sure you're logged into the right one.
1. Make sure the computer is ready to run Exchange 2013 Setup. To see what you need to run Setup, check
out the Active Directory preparation section in Exchange 2013 prerequisites.
2. Open a Windows Command Prompt window and go to where you downloaded the Exchange installation
files.
3. Run the following command to extend the schema.

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

After Setup finishes extending the schema, you'll need to wait while Active Directory replicates the changes to
all of your domain controllers. If you want to check on how replication is going, you can use the repadmin tool.
Repadmin is included as part of the Active Directory Domain Services Tools feature in Windows Server 2012
R2, Windows Server 2012, and Windows Server 2008 R2. For more information about how to use it, see
Repadmin.
2. Prepare Active Directory
Now that the Active Directory schema has been extended, you can prepare other parts of Active Directory for
Exchange 2013. During this step, Exchange will create containers, objects, and other items in Active Directory
that it'll use to store information. The collection of all of the Exchange containers, objects, attributes, and so on, is
called the Exchange organization.
Before you prepare Active Directory for Exchange, there are a few things to keep in mind:
The account you're logged in as needs to be a member of the Enterprise Admins security group. If you
skipped step 1 because you want the PrepareAD command to extend the schema, the account you use
also needs to be a member of the Schema Admins security group.
The computer where you'll run the command needs to be in the same Active Directory domain and site
as the schema master. It'll also need to contact all of the domains in the forest on TCP port 389.
Wait until Active Directory has replicated the changes made in step 1 to all of your domain controllers
before you do this step.
When you run the command below to prepare Active Directory for Exchange, you'll need to name the Exchange
organization. This name is used internally by Exchange and isn't normally seen by users. The name of the
company where Exchange is being installed is often used for the organization name. The name you use won't
affect the functionality of Exchange or determine what you can use for email addresses. You can name it
anything you want, as long as you keep the following in mind:
You can use any uppercase or lowercase letters from A to Z.
You can use numbers 0 to 9.
The name can contain spaces as long as they're not at the beginning or end of the name.
You can use a hyphen or dash in the name.
The name can be up to 64 characters but can't be blank.
The name can't be changed after it's set.
When you're ready, do the following to prepare Active Directory for Exchange. If the organization name you
want to use has spaces, enclose the name in quotation marks (").
1. Open a Windows Command Prompt window and go to where you downloaded the Exchange installation
files.
2. Run the following command:

Setup.exe /PrepareAD /OrganizationName:"<organization name>" /IAcceptExchangeServerLicenseTerms

IMPORTANT
If you've configured a hybrid deployment between your on-premises organization and Exchange Online, you need to
include the /TenantOrganizationConfig switch when you run the above command.

After Setup finishes preparing Active Directory for Exchange, you'll need to wait while Active Directory
replicates the changes to all of your domain controllers. If you want to check on how replication is going, you
can use the repadmin tool. repadmin is included as part of the Active Directory Domain Services Tools feature
in Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2. For more information
about how to use the tool, see Repadmin.
3. Prepare Active Directory domains
The final step to get Active Directory ready for Exchange is to prepare each of the Active Directory domains
where Exchange will be installed or where mail-enabled users will be located. This step creates additional
containers and security groups, and sets permissions so that Exchange can access them.
If you have multiple domains in your Active Directory forest, you have a couple of choices in how you prepare
them. Select the option that matches what you want to do. If you only have one domain, you can skip this step
because the PrepareAD command in step 2 already prepared the domain for you.

Prepare all of the domains in my Active Directory forest

To prepare all of your Active Directory domains, you can use the PrepareAllDomains parameter when you run
Setup. Setup will prepare every domain for Exchange in your Active Directory forest for you.
Before you prepare all of the domains in your Active Directory forest, keep the following in mind:
The account you use needs to be a member of the Enterprise Admins security group.
Wait until Active Directory has replicated the changes made in step 2 to all of your domain controllers. If
you don't, you might get an error when you try to prepare the domain.
When you're ready, do the following to prepare all of the domains in your Active Directory forest for Exchange.
1. Open a Windows Command Prompt window and go to where you downloaded the Exchange installation
files.
2. Run the following command:

Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Let me choose which Active Directory domains I want to prepare

If you want to choose which Active Directory domains you want to prepare, you can use the PrepareDomain
parameter when you run Setup. When you use the PrepareDomain parameter, you need to include the fully
qualified domain name (FQDN ) of the domain you want to prepare.
Before you prepare the domains in your Active Directory forest, keep the following in mind:
The account you use needs permissions depending on when the domain was created.
Domain created before PrepareAD was run: If the domain was created before you ran the
PrepareAD command in step 2 above, then the account you use needs to be a member of the
Domain Admins group in the domain you want to prepare.
Domain created after PrepareAD was run: If the domain was created after you ran the
PrepareAD command in step 2 above, then the account you use needs to 1) be a member of the
Organization Management role group and 2) be a member of the Domain Admins group in the
domain you want to prepare.
Wait until Active Directory has replicated the changes made in step 2 to all of your domain controllers. If
you don't, you might get an error when you try to prepare the domain.
You need to prepare every domain where an Exchange server will be installed. You'll also need to prepare
any domain that'll contain mail-enabled users, even if those domains won't contain any Exchange servers.
You don't need to run the PrepareDomain command in the domain where the PrepareAD command was
run. The PrepareAD command prepares that domain automatically.
When you're ready, do the following to prepare an individual domain in your Active Directory forest for
Exchange.
1. Open a Windows Command Prompt window and go to where you downloaded the Exchange installation
files.
2. Run the following command. Include the FQDN of the domain you want to prepare. If you want to
prepare the domain you're running the command in, you don't have to include the FQDN.

Setup.exe /PrepareDomain:<FQDN of the domain you want to prepare> /IAcceptExchangeServerLicenseTerms

3. Repeat the steps for each Active Directory domain where you'll install an Exchange server or where mail-
enabled users will be located.

How do you know this worked?

Once you've done all the steps above, you can check to make sure everything's gone smoothly. To do so, you'll
use a tool called Active Directory Service Interfaces Editor (ADSI Edit). ADSI Edit is included as part of the
Active Directory Domain Services Tools feature in Windows Server 2012 R2, Windows Server 2012, and
Windows Server 2008 R2. If you want to know more about it, check out ADSI Edit (adsiedit.msc).

WARNING
Never change values in ADSI Edit unless you're told to do so by Microsoft support. Changing values in ADSI Edit can
cause irreparable harm to your Exchange organization and Active Directory.

After Exchange extends your Active Directory schema and prepares Active Directory for Exchange, several
properties are updated to show that preparation is complete. Use the information in the following list to make
sure these properties have the right values. Each property needs to match the value in the table below for the
release of Exchange 2013 that you're installing.
In the Schema naming context, verify that the rangeUpper property on ms-Exch-Schema-Verision-
Pt is set to the value shown for your version of Exchange 2013 in the Exchange 2013 Active Directory
versions table.
In the Configuration naming context, verify that the objectVersion property in the CN=<your
organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container is set
to the value shown for your version of Exchange 2013 in the Exchange 2013 Active Directory versions
table.
In the Default naming context, verify that the objectVersion property in the Microsoft Exchange
System Objects container under DC=<root domain is set to the value shown for your version of
Exchange 2013 in the Exchange 2013 Active Directory versions table.
You can also check the Exchange setup log to verify that Active Directory preparation has completed
successfully. For more information, see Verify an Exchange 2013 installation. You won't be able to use the Get-
ExchangeServer cmdlet mentioned in the Verify an Exchange 2013 installation topic until you've completed
the installation of at least one Mailbox server role and one Client Access server role in an Active Directory site.

Exchange 2013 Active Directory versions

The following table shows you the Exchange 2013 objects in Active Directory that get updated each time you
install a new version of Exchange 2013. You can compare the object versions you see with the values in the table
below to verify that the version of Exchange 2013 you installed successfully updated Active Directory during
installation.

EXCHANGE VERSION RANGEUPPER OBJECTVERSION OBJECTVERSION

Naming context Schema Default Configuration

Container ms-Exch- Microsoft CN=<your

Schema-Version- Exchange System organization>,
Pt Objects CN=Microsoft
Exchange,
CN=Services,
CN=Configuratio
n, DC=
<domain>

Exchange 2013 15312 13237 16130

CU23

Exchange 2013 15312 13236 16133

CU22

Exchange 2013 15312 13236 16131

CU10-CU21

Exchange 2013 15312 13236 15965

CU9

Exchange 2013 15312 13236 15965

CU8

Exchange 2013 15312 13236 15965

CU7

Exchange 2013 15303 13236 15965

CU6

Exchange 2013 15300 13236 15870

CU5

Exchange 2013 15292 13236 15844

SP1

Exchange 2013 15283 13236 15763

CU3

Exchange 2013 15281 13236 15688

CU2
EXCHANGE VERSION RANGEUPPER OBJECTVERSION OBJECTVERSION

Exchange 2013 15254 13236 15614

CU1

Exchange 2013 15137 13236 15449

RTM
 Deploy a new installation of Exchange 2013
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Before you begin your installation of Microsoft Exchange Server 2013, see Planning and deployment for
important planning information, and information about system requirements and prerequisites.
The following topics provide information about deploying a new installation of Exchange 2013 in your
organization:
Checklist: Perform a new installation of Exchange 2013
Install Exchange 2013 using the Setup wizard
Install Exchange 2013 using unattended mode
Install the Exchange 2013 Edge Transport role using the Setup wizard
Delegate the installation of an Exchange 2013 server
After you've completed your installation, see Exchange 2013 post-Installation tasks.
 Checklist: Perform a new installation of Exchange
2013
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Use this checklist to deploy Microsoft Exchange Server 2013. Before you start working with this checklist, make
sure you're familiar with the concepts discussed in:
Planning and deployment
Deployment security checklist
This checklist is generic in that it provides guidance for a typical scenario.

NOTE
The Exchange Server Deployment Assistant provides you with customized step-by-step guidance about how to deploy
Exchange Server. The Deployment Assistant can help you deploy a new installation of Exchange Server 2013, upgrade a
previous version to Exchange 2013, or configure a hybrid deployment of Exchange 2013 and Exchange Online. To learn
more, see Exchange Server Deployment Assistant.

Checklist for a new installation of Exchange 2013

Done? Task Topic

1. Read the release notes. Release notes for Exchange 2013

2. Verify system requirements. Exchange 2013 system

requirements

3. Confirm prerequisite steps are Exchange 2013 prerequisites

done.

4. Configure disjoint namespace. Disjoint namespace scenarios

NOTE
This step is optional. It's only
necessary if your organization is
running a disjoint namespace.

5. Install the Mailbox server role. Install Exchange 2013 using the
Setup wizard
6. Install the Client Access server Install Exchange 2013 using the
role. Setup wizard

7. Install the Edge Transport server Install the Exchange 2013 Edge
role. Transport role using the Setup
wizard
NOTE
This step is optional. It's only
necessary if you want to install
an Edge Transport server. For
more information, see Edge
Transport servers.

8. Create an EdgeSync subscription. Configure Internet mail flow

through a subscribed Edge
This step is optional. It's only Transport server
necessary if you've installed an
Edge Transport server and want to
configure an EdgeSync subscription
between your Edge Transport
server and a Hub Transport server.
For more information, see Edge
Subscriptions.

9. Configure Transport. Create a Send connector

10. Add additional accepted Add additional accepted domains

domains.

11. Configure email address Configure the default email address

policies. policy

12. Configure settings on virtual Configure external URLs

directories, including the offline
address book, Exchange Web Configure internal URLs
Services, Exchange admin center
(EAC), Outlook Web App, and
Exchange ActiveSync virtual
directories.

NOTE
This step is necessary if you want
to use Exchange Web Services,
Outlook Anywhere, or the offline
address book. It also may be
required if you need to change
any of the default settings for
EAC, Outlook Web App, or
Exchange ActiveSync.
13. Add digital certificates on the Configure an SSL certificate
Client Access server.

14. Configure Unified Messaging. Deploying voice mail and UM

NOTE
This step is optional. It's only
necessary if you want to use
Unified Messaging in your
organization.

15. Configure additional Unified Deploying Exchange 2013 UM and

Messaging and Lync Server Lync Server overview
settings.

NOTE
This step is optional. It's only
necessary if you've configured
Unified Messaging in your
organization and want to
integrate it with Lync Server.

16. Post-installation tasks. Exchange 2013 post-Installation

tasks
 Install Exchange 2013 using the Setup wizard
6/14/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic explains how to use the Microsoft Exchange Server 2013 Setup wizard to install the Exchange 2013
Mailbox and Client Access roles on a computer. For more information about planning and deploying Exchange
2013, see Planning and deployment.
If you want to install the Exchange 2013 Edge Transport role on a computer, see Install the Exchange 2013
Edge Transport role using the Setup wizard. The Edge Transport role can't be installed on the same computer as
the Mailbox or Client Access server roles.

TIP
Have you heard about the Exchange Server Deployment Assistant? It's a free online tool that helps you quickly deploy
Exchange 2013 in your organization by asking you a few questions and creating a customized deployment checklist just
for you. If you want to learn more about it, go to Exchange Server Deployment Assistant.

NOTE
After you install any server roles on a computer running Exchange 2013, you can't use the Exchange 2013 Setup wizard
to add any additional server roles to this computer. If you want to add more server roles to a computer, you must either
use Add or Remove Programs from Control Panel or use Setup.exe from a Command Prompt window.

For information about tasks to complete after installation, see Exchange 2013 post-Installation tasks.

What do you need to know before you begin?

Estimated time to complete: 60 minutes
Make sure you've read the release notes prior to installing Exchange 2013. For more information, see
Release notes for Exchange 2013.
Each organization requires at a minimum one Client Access server and one Mailbox server in the Active
Directory forest. Additionally, each Active Directory site that contains a Mailbox server must also contain
at least one Client Access server. If you're separating your server roles, we recommend installing the
Mailbox server role first.
The computer you install Exchange 2013 on must have a supported operating system (such as Windows
Server 2008 R2 with Service Pack 1 (SP1) or Windows Server 2012), have enough disk space, be a
member of an Active Directory domain, and satisfy other requirements. For information about system
requirements, see Exchange 2013 system requirements.
To run Exchange 2013 setup, you must install Microsoft .NET Framework 4.5, Windows Management
Framework 3.0, and other required software. To understand the prerequisites for all server roles, see
Exchange 2013 prerequisites.
You must ensure the account you use is delegated membership in the Schema Admins group if you
haven't previously prepared the Active Directory schema. If you're installing the first Exchange 2013
server in the organization, the account you use must have membership in the Enterprise Admins group.
 If you've already prepared the schema and aren't installing the first Exchange 2013 server in the
organization, the account you use must be a member of the Exchange 2013 Organization Management
role group.
Administrators who are members of the Delegated Setup role group can deploy Exchange 2013 servers
that have been previously provisioned by a member of the Organization Management management role
group.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

WARNING
After you install Exchange on a server, you must not change the server name. Renaming a server after you have installed
an Exchange server role is not supported.

Install Exchange Server 2013

If you're installing the first Exchange 2013 server in the organization, and the Active Directory preparation
steps have not been performed, the account you use must have membership in the Enterprise Administrators
group. If you haven't previously prepared the Active Directory Schema, the account must also be a member of
the Schema Admins group. For information about preparing Active Directory for Exchange 2013, see Prepare
Active Directory and domains. If you have already performed the Schema and Active Directory preparation
steps, the account you use must be a member of the Delegated Setup management role group or the
Organization Management role group.

NOTE
To download the latest version of Exchange 2013, see Updates for Exchange 2013.

1. Log on to the computer on which you want to install Exchange 2013.

2. Navigate to the network location of the Exchange 2013 installation files.
3. Start Exchange 2013 Setup by double-clicking Setup.exe

IMPORTANT
If you have User Access Control (UAC) enabled, you must right-click Setup.exe and select Run as
administrator.

4. On the Check for Updates? page, choose whether you want Setup to connect to the Internet and
download product and security updates for Exchange 2013. If you select Connect to the Internet and
check for updates, Setup will download updates and apply them prior to continuing. If you select
Don't check for updates right now, you can download and install updates manually later. We
recommend that you download and install updates now. Click Next to continue.
5. The Introduction page begins the process of installing Exchange into your organization. It will guide
you through the installation. Several links to helpful deployment content are listed. We recommend that
you visit these links prior to continuing setup. Click Next to continue.
6. On the License Agreement page, review the software license terms. If you agree to the terms, select I
accept the terms in the license agreement, and then click Next.
 7. On the Recommended settings page, select whether you want to use the recommended settings. If
you select Use recommended settings, Exchange will automatically send error reports and
information about your computer hardware and how you use Exchange to Microsoft. If you select Don't
use recommended settings, these settings remain disabled but you can enable them at any time after
Setup completes. For more information about these settings and how information sent to Microsoft is
used, click ?.
8. On the Server Role Selection page, choose whether you want to install the Mailbox role, the Client
Access role, both roles, or just the Management Tools on this computer. You can add additional server
roles later if you choose not to install them during this installation. An organization must have at least
one Mailbox role and at least one Client Access server role installed. They can be installed on the same
computer or on separate computers. The management tools are installed automatically if you install any
server role.
Select Automatically install Windows Server roles and features that are required to install
Exchange Server to have the Setup wizard install required Windows prerequisites. You may need to
reboot the computer to complete the installation of some Windows features. If you don't select this
option, you must install the Windows features manually.

NOTE
This option installs only the Windows features required by Exchange. You must manually install other
prerequisites manually. For more information, see Exchange 2013 prerequisites.

Click Next to continue.

9. On the Installation Space and Location page, either accept the default installation location or click
Browse to choose a new location. Make sure that you have enough disk space available in the location
where you want to install Exchange. Click Next to continue.
10. If this is the first Exchange server in your organization, on the Exchange Organization page, type a
name for your Exchange organization. The Exchange organization name can contain only the following
characters:
A through Z
a through z
0 through 9
Space (not leading or trailing)
Hyphen or dash

NOTE
The organization name can't contain more than 64 characters. The organization name can't be blank.

If you want to use the Active Directory split permissions model, select Apply Active Directory split
permission security model to the Exchange organization.
 WARNING
Most organizations don't need to apply the Active Directory split permissions model. If you need to separate
management of Active Directory security principals and Exchange configuration, Role Based Access Control
(RBAC) split permissions might work for you. For more information, click ?.

Click Next to continue.

11. If you're installing the Mailbox role, on the Malware Protection Settings page, choose whether you
want to enable or disable malware scanning. If you disable malware scanning, it can be enabled in the
future. Click Next to continue.
12. On the Readiness Checks page, view the status to determine if the organization and server role
prerequisite checks completed successfully. If they haven't completed successfully, you must resolve any
reported errors before you can install Exchange 2013. You don't need to exit Setup when resolving some
of the prerequisite errors. After resolving a reported error, click back and then click Next to run the
prerequisite check again. Be sure to also review any warnings that are reported. If all readiness checks
have completed successfully, click Next to install Exchange 2013.
13. On the Completion page, click Finish.
14. Restart the computer after Exchange 2013 has completed.
15. Complete your deployment by performing the tasks provided in Exchange 2013 post-Installation tasks.

How do you know this worked?

To verify that you've successfully installed Exchange 2013, see Verify an Exchange 2013 installation.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Install Exchange 2013 using unattended mode
6/6/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

To perform an unattended setup, you must install Microsoft Exchange Server 2013 from the command prompt.
For more information about planning and deploying Exchange 2013, see Planning and deployment.
We recommend that the Edge Transport role be installed in a perimeter network outside of your organization's
internal Active Directory forest. While you can install the Edge Transport server role on a domain-joined computer,
doing so will only enable domain management of Windows features and settings. The Edge Transport role itself
doesn't use Active Directory. Instead, it uses the Active Directory Lightweight Directory Services (AD LDS )
Windows feature to store configuration and recipient information. For more information about the Edge Transport
role, see Edge Transport servers.

TIP
Have you heard about the Exchange Server Deployment Assistant? It's a free online tool that helps you quickly deploy
Exchange 2013 in your organization by asking you a few questions and creating a customized deployment checklist just for
you. If you want to learn more about it, go to Exchange Server Deployment Assistant.

NOTE
After you install any server roles on a computer running Exchange 2013, you can't use the Exchange 2013 Setup wizard to
add any additional server roles to this computer. If you want to add more server roles to a computer, you must either use
Add or Remove Programs from Control Panel or use Setup.exe from a Command Prompt window.
The Edge Transport role can't be installed on the same computer as the Mailbox or Client Access server roles.

For information about tasks to complete after installation, see Exchange 2013 post-Installation tasks.

What do you need to know before you begin?

The following information applies to all Exchange 2013 server roles.
Make sure you've read the release notes prior to installing Exchange 2013. For more information, see
Release notes for Exchange 2013.
The computer you install Exchange 2013 on must have a supported operating system (such as Windows
Server 2008 R2 with Service Pack 1 (SP1), Windows Server 2012 R2, or Windows Server 2012), have
enough disk space, and satisfy other requirements. For information about system requirements, see
Exchange 2013 system requirements.
To run Exchange 2013 setup, you must install Microsoft .NET Framework 4.5, Windows Management
Framework, and other required software. To understand the prerequisites for all server roles, see Exchange
2013 prerequisites.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
 WARNING
After you install Exchange on a server, you must not change the server name. Renaming a server after you have installed an
Exchange server role is not supported.

The following information applies to the Exchange 2013 Mailbox and Client Access server roles.
Estimated time to complete: 60 minutes
Each organization requires at a minimum one Client Access server and one Mailbox server in the Active
Directory forest. Additionally, each Active Directory site that contains a Mailbox server must also contain at
least one Client Access server. If you're separating your server roles, we recommend installing the Mailbox
server role first.
The computer you install Exchange 2013 on must be a member of an Active Directory domain.
You must ensure the account you use is delegated membership in the Schema Admins group if you haven't
previously prepared the Active Directory schema. If you're installing the first Exchange 2013 server in the
organization, the account you use must have membership in the Enterprise Admins group. If you've already
prepared the schema and aren't installing the first Exchange 2013 server in the organization, the account
you use must be a member of the Exchange 2013 Organization Management management role group.
Administrators who are members of the Delegated Setup role group can deploy Exchange 2013 servers
that have been previously provisioned by a member of the Organization Management role group.
The following information applies to the Exchange 2013 Edge Transport server role.
Estimated time to complete: 40 minutes
The Edge Transport role is available with Exchange 2013 SP1 or later.
You need to configure the primary DNS suffix on the computer. For example, if the fully qualified domain
name of your computer is edge.contoso.com, the DNS suffix for the computer is contoso.com. For more
information, see Primary DNS Suffix is missing.
Exchange 2007 and Exchange 2010 Hub Transport servers need an update before you can create an
EdgeSync Subscription between them and an Exchange 2013 Edge Transport server. If you don't install this
update, the EdgeSync Subscription won't work correctly. For more information, see the "Supported
coexistence scenarios" section in Exchange 2013 system requirements.
Make sure the account you use is a member of the local Administrators group on the computer you're
installing the Edge Transport role.

Use Setup.exe to install Exchange 2013 in unattended mode

NOTE
To download the latest version of Exchange 2013, see Updates for Exchange 2013.

1. Log on to the computer on which you want to install Exchange 2013.

2. Navigate to the network location of the Exchange 2013 installation files.
3. At the command prompt, run the applicable command for your organization.
 IMPORTANT
If you have User Access Control (UAC) enabled, you must run Setup.exe from an elevated command prompt.

Setup.exe [/Mode:<setup mode>] [/IAcceptExchangeServerLicenseTerms]

[/Roles:<server roles to install>] [/InstallWindowsComponents]
[/OrganizationName:<name for the new Exchange organization>]
[/TargetDir:<target directory>] [/SourceDir:<source directory>]
[/UpdatesDir:<directory from which to install updates>]
[/DomainController:<FQDN of domain controller>] [/DisableAMFiltering]
[/AnswerFile:<filename>] [/DoNotStartTransport]
[/EnableErrorReporting] [/CustomerFeedbackEnabled:<True | False>]
[/AddUmLanguagePack:<UM language pack name>]
[/RemoveUmLanguagePack:<UM language pack name>]
[/NewProvisionedServer:<server>] [/RemoveProvisionedServer:<server>]
[/MdbName:<mailbox database name>] [/DbFilePath:<Edb file path>]
[/LogFolderPath:<log folder path>] [/ActiveDirectorySplitPermissions:<True | False>]
[/TenantOrganizationConfig:<path>]

4. Setup copies the setup files locally to the computer on which you're installing Exchange 2013.
5. Setup checks the prerequisites, including all prerequisites specific to the server roles that you're installing. If
you haven't met all the prerequisites, Setup fails and returns an error message that explains the reason for
the failure. If you've met all the prerequisites, Setup installs Exchange 2013.
6. Restart the computer after Exchange 2013 has completed.
7. Complete your deployment by performing the tasks provided in Exchange 2013 post-Installation tasks.

Examples
The following are examples of using Setup.exe:
Setup.exe /mode:Install /role:ClientAccess,Mailbox /OrganizationName:MyOrg
/IAcceptExchangeServerLicenseTerms
This command creates an Exchange 2013 organization in Active Directory called MyOrg, installs the Client
Access server role, Mailbox server role, and the management tools and also accepts the Exchange 2013
licensing terms.
Setup.exe /mode:Install /role:ClientAccess,Mailbox /TargetDir:"C:\Exchange Server"
/IAcceptExchangeServerLicenseTerms
This command installs the Client Access server role, the Mailbox server role, and the management tools to
the "C:\Exchange Server" directory. This command assumes an Exchange 2013 organization has already
been prepared.
Setup.exe /mode:Install /r:CA,MB /IAcceptExchangeServerLicenseTerms
This command installs the Client Access server role, the Mailbox server role, and the management tools to
the default installation location.
Setup.exe /mode:Install /r:EdgeTransport /IAcceptExchangeServerLicenseTerms
This command installs the Edge Transport server role and the management tools to the default installation
location.
Setup.exe /mode:Install /r:ET /IAcceptExchangeServerLicenseTerms
 This command installs the Edge Transport server role and the management tools to the default installation
location.
Setup.exe /mode:Uninstall /IAcceptExchangeServerLicenseTerms
This command completely removes Exchange 2013 from the server and removes this server's Exchange
configuration from Active Directory.
Setup.exe /PrepareAD /on:"My Org" /IAcceptExchangeServerLicenseTerms
This command creates an Exchange organization called My Org and prepares Active Directory for
Exchange 2013.
C:\ExchangeServer\bin\Setup.exe /m:Install /r:ClientAccess /SourceDir:d:\amd64
/IAcceptExchangeServerLicenseTerms
This command adds the Client Access server role to an existing Exchange 2013 server using D:\amd64 as
the source directory.
Setup.exe /role:ClientAccess,Mailbox /UpdatesDir:"C:\ExchangeServer\New Patches"
/IAcceptExchangeServerLicenseTerms
This command updates ExchangeServer.msi with patches from the specified directory, and then installs the
Client Access server role, Mailbox server role, and the management tools. If a language pack bundle is
included in this directory, the language pack is also installed.
Setup.exe /mode:Install /role:ClientAccess,Mailbox /DomainController:DC01
/IAcceptExchangeServerLicenseTerms
This command uses the domain controller DC01 to query and make changes to Active Directory while
installing the Client Access server role, Mailbox server role, and the management tools.
Setup.exe /mode:Install /role:ClientAccess /AnswerFile:c:\ExchangeConfig.txt
/IAcceptExchangeServerLicenseTerms
This command installs the Client Access server role by using the settings in the ExchangeConfig.txt file.
Setup.exe /rprs:Exchange03 /IAcceptExchangeServerLicenseTerms
This command removes the object Exchange03 from Active Directory.
Setup.exe /AddUmLanguagePack:ko-KR /IAcceptExchangeServerLicenseTerms
This command installs the Korean Unified Messaging language pack from the
%ExchangeSourceDir%\ServerRoles\UnifiedMessaging directory.

How do you know this worked?

To verify that you've successfully installed Exchange 2013, see Verify an Exchange 2013 installation.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Install the Exchange 2013 Edge Transport role using
the Setup wizard
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic explains how to use the Microsoft Exchange Server 2013 Setup wizard to install the Exchange 2013
Edge Transport server role on a computer. The Edge Transport role is available with Exchange 2013 Service Pack
1 (SP1) or later. For more information about planning and deploying Exchange 2013, see Planning and
deployment.
We recommend that the Edge Transport role be installed in a perimeter network outside of your organization's
internal Active Directory forest. While you can install the Edge Transport server role on a domain-joined
computer, doing so will only enable domain management of Windows features and settings. The Edge Transport
role itself doesn't use Active Directory. Instead, it uses the Active Directory Lightweight Directory Services (AD
LDS ) Windows feature to store configuration and recipient information. For more information about the Edge
Transport role, see Edge Transport servers.
If you want to install the Exchange 2013 Mailbox or Client Access roles on a computer, see Install Exchange 2013
using the Setup wizard. The Edge Transport role can't be installed on the same computer as the Mailbox or Client
Access server roles.

TIP
Have you heard about the Exchange Server Deployment Assistant? It's a free online tool that helps you quickly deploy
Exchange 2013 in your organization by asking you a few questions and creating a customized deployment checklist just for
you. If you want to learn more about it, go to Exchange Server Deployment Assistant.

For information about tasks to complete after installation, see Exchange 2013 post-Installation tasks.

What do you need to know before you begin?

Estimated time to complete: 40 minutes
Make sure you've read the release notes prior to installing Exchange 2013. For more information, see
Release notes for Exchange 2013.
The computer you install Exchange 2013 on must have a supported operating system (such as Windows
Server 2008 R2 with SP1, Windows Server 2012 R2, or Windows Server 2012), have enough disk space,
and satisfy other requirements. For information about system requirements, see Exchange 2013 system
requirements.
To run Exchange 2013 setup, you must install Microsoft .NET Framework 4.5, Windows Management
Framework, and other required software. To understand the prerequisites for all server roles, see Exchange
2013 prerequisites.
You need to configure the primary DNS suffix on the computer. For example, if the fully qualified domain
name of your computer is edge.contoso.com, the DNS suffix for the computer is contoso.com. For more
information, see Primary DNS Suffix is missing.
Exchange 2007 and Exchange 2010 Hub Transport servers need an update before you can create an
 EdgeSync Subscription between them and an Exchange 2013 Edge Transport server. If you don't install this
update, the EdgeSync Subscription won't work correctly. For more information, see the "Supported
coexistence scenarios" section in Exchange 2013 system requirements.
Make sure the account you use is a member of the local Administrators group on the computer you're
installing the Edge Transport role.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

WARNING
After you install Exchange on a server, you must not change the server name. Renaming a server after you have installed
an Exchange server role is not supported.

Install Exchange Server 2013

NOTE
To download the latest version of Exchange 2013, see Updates for Exchange 2013.

1. Log on to the computer on which you want to install Exchange 2013.

2. Navigate to the network location of the Exchange 2013 installation files.
3. Start Exchange 2013 Setup by double-clicking Setup.exe

IMPORTANT
If you have User Access Control (UAC) enabled, you must right-click Setup.exe and select Run as administrator.

4. On the Check for Updates? page, choose whether you want Setup to connect to the Internet and
download product and security updates for Exchange 2013. If you select Connect to the Internet and
check for updates, Setup will download updates and apply them prior to continuing. If you select Don't
check for updates right now, you can download and install updates manually later. We recommend that
you download and install updates now. Click Next to continue.
5. The Introduction page begins the process of installing Exchange into your organization. It will guide you
through the installation. Several links to helpful deployment content are listed. We recommend that you
visit these links prior to continuing setup. Click Next to continue.
6. On the License Agreement page, review the software license terms. If you agree to the terms, select I
accept the terms in the license agreement, and then click Next.
7. On the Recommended settings page, select whether you want to use the recommended settings. If you
select Use recommended settings, Exchange will automatically send error reports and information
about your computer hardware and how you use Exchange to Microsoft. If you select Don't use
recommended settings, these settings remain disabled but you can enable them at any time after Setup
completes. For more information about these settings and how information sent to Microsoft is used, click
?.
8. On the Server Role Selection page, select Edge Transport. Remember that you can't add the Mailbox or
Client Access server roles to a computer that has the Edge Transport role installed. The management tools
are installed automatically if you install any server role.
 Select Automatically install Windows Server roles and features that are required to install
Exchange Server to have the Setup wizard install required Windows prerequisites. You may need to
reboot the computer to complete the installation of some Windows features. If you don't select this option,
you must install the Windows features manually.

NOTE
This option installs only the Windows features required by Exchange. You must install other prerequisites manually.
For more information, see Exchange 2013 prerequisites.

Click Next to continue.

9. On the Installation Space and Location page, either accept the default installation location or click
Browse to choose a new location. Make sure that you have enough disk space available in the location
where you want to install Exchange. Click Next to continue.
10. On the Readiness Checks page, view the status to determine if the organization and server role
prerequisite checks completed successfully. If they haven't completed successfully, you must resolve any
reported errors before you can install Exchange 2013. You don't need to exit Setup when resolving some
of the prerequisite errors. After resolving a reported error, click back and then click Next to run the
prerequisite check again. Be sure to also review any warnings that are reported. If all readiness checks
have completed successfully, click Next to install Exchange 2013.
11. On the Completion page, click Finish.
12. Restart the computer after Exchange 2013 has completed.
13. Complete your deployment by performing the tasks provided in Exchange 2013 post-Installation tasks.

How do you know this worked?

To verify that you've successfully installed Exchange 2013, see Verify an Exchange 2013 installation.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Delegate the installation of an Exchange 2013 server
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Exchange Server 2013 lets you delegate the installation of Exchange servers to people who aren't members of the
Exchange 2013 Organization Management role group. This is often helpful in large companies where the people
who install and set up servers aren't the same people who manage services, like Exchange. If this sounds like
something you want to do, this topic is for you.
Normally, when Exchange is installed, the people installing it need to be members of the Organization
Management role group. This is because when Exchange is installed, changes are made to Active Directory, and
only Exchange administrators, who are members of the Organization Management role group, can make those
changes. The following list shows the changes that are made:
A server object is created in the CN=Servers,CN=Exchange Administrative Group
(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Organization Name>,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<Root Domain> configuration partition.
The following access control entries (ACEs) are added to the server object within the configuration partition
for the Delegated Setup role group:
Full Control on the server object and its child objects
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

NOTE
Public folders are administered at an organizational level; therefore, the creation and deletion of public folder stores is
restricted to Exchange administrators.

The Active Directory computer account for the server is added to the Exchange Servers group.
The server is added as a provisioned server in the Exchange admin center.
In large companies, the people who install and set up new servers often aren't Exchange administrators. To enable
them to install Exchange, an Exchange administrator can provision the server in Active Directory. When a server is
provisioned, all of the changes needed for the new Exchange server to function are made to Active Directory
separately from the actual installation of Exchange on a computer. An Exchange administrator can provision a new
server in Active Directory hours or even days before Exchange is installed on the new computer. After a server has
been provisioned, the person doing the installation needs only to be a member of the Delegated Setup role group
to install Exchange. The Delegated Setup role group only allows members to install provisioned servers.
Keep the following in mind when thinking about using delegated setup:
At least one Exchange 2013 server has to already be installed before you can delegate the installation of
additional servers. The person who installs the first server needs to be an Exchange administrator. For more
information, check out Checklist: Perform a new installation of Exchange 2013.
A delegated user can't uninstall an Exchange server. To uninstall an Exchange server, you need to be an
 Exchange administrator.

How do I provision an Exchange 2013 server?

To provision a server for Exchange, you need to use Exchange 2013 command-line Setup. If you're not very
familiar with the Windows Command Prompt, don't worry. This topic steps you through exactly what you need to
do. Before we start, here are a couple of things to keep in mind:
You need to be a member of the Organization Management role group to provision a server.
You should have the latest release of Exchange 2013. You can get the download link from Updates for
Exchange 2013.
The command that you need to use to provision the server depends on whether you're running Setup from the
computer you're provisioning or whether you're running it from another computer. Choose the command in the
following steps that matches where you're running Setup:
1. Press the Windows key + 'R' to open the Run window.
2. In Open, typecmd.exe, and then press Enter to open a Windows Command Prompt.
3. Change directories to where you downloaded and expanded the Exchange 2013 install files. If the install
files are located in C:\Downloads\Exchange 2013 , use the following command.

CD "C:\Downloads\Exchange 2013"

4. Choose the command that matches where you're running Setup:

If you're running Setup on the computer that's being provisioned, run the following command:

Setup.exe /NewProvisionedServer /IAcceptExchangeServerLicenseTerms

If you're running Setup on another computer, run the following command:

Setup.exe /NewProvisionedServer:<ComputerName> /IAcceptExchangeServerLicenseTerms

5. After you provision the server, you need to make sure that you've added the users who should be able to
install Exchange on provisioned servers to the Delegated Setup role group. To see how to add users to a
role group, see Manage Role Group Members.
When you're done with these steps, the computer will be ready for Exchange to be installed. Exchange 2013 can be
installed on a provisioned server by using the steps in Install Exchange 2013 using the Setup wizard.

How do I know this worked?

To make sure the server was properly provisioned for Exchange, you can do the following:
1. Go to Start > Administrative Tools, and then open Active Directory Users and Computers.
2. Select Microsoft Exchange Security Groups, double-click Exchange Servers, and then select the
Members tab.
3. On the Members tab, check to see if the server you just provisioned is listed as a member of the security
group.
If your server is listed as a member of the Exchange Servers security group, it was properly provisioned. Someone
who's a member of the Delegated Setup role group can now install Exchange on that server.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Upgrade Exchange 2013 to the latest cumulative
update or service pack
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

If you have Microsoft Exchange Server 2013 installed, you can upgrade it to the latest Exchange 2013 cumulative
update or service pack. You can use the Exchange 2013 Setup wizard to upgrade your current version of Exchange
2013. For more information about the latest Exchange 2013 cumulative update or service pack, see Updates for
Exchange 2013. To learn more about Exchange 2013, see What's new in Exchange 2013.

WARNING
After you upgrade Exchange 2013 to a newer cumulative update or service pack, you can't uninstall the new version to
revert to the previous version. If you uninstall the new version, you remove Exchange from the server.

What do you need to know before you begin?

Estimated time to complete: 60 minutes
Make sure you read the release notes before you install Exchange 2013. For more information, see Release
notes for Exchange 2013.
Make sure that any server on which you plan to install the cumulative update or service pack meets the
system requirements and prerequisites. For more information, see Exchange 2013 system requirements
and Exchange 2013 prerequisites.

WARNING
Any customized per-server settings you make in Exchange XML application configuration files, for example,
web.config files on Client Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be overwritten
when you install an Exchange Cumulative Update (CU). Make sure that you save this information so you can easily
re-configure your server after the install. You must re-configure these settings after you install an Exchange CU.

After you install a cumulative update or service pack, you must restart the computer so that changes can be
made to the registry and operating system.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Install the Exchange 2013 cumulative update or service pack

You can install the cumulative update or service pack for Exchange 2013 by using either the Setup wizard or via
unattended mode. For specific instructions, see the following topics:
Install Exchange 2013 using the Setup wizard
Install Exchange 2013 using unattended mode
If the computer you've installed a service pack or cumulative update on is a member of a database availability
group (DAG ), follow the steps in Performing maintenance on DAG members section of the Managing database
availability groups topic.
 Upgrade from Exchange 2010 to Exchange 2013
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2010 and Exchange Server 2007 have multiple server roles: Client Access, Mailbox,
Hub Transport, Unified Messaging, and Edge Transport. With Exchange Server 2013, we reduced the number of
server roles from five to three: Client Access, Mailbox, and Edge Transport. Unified Messaging is now considered a
component or sub-feature of the voice-related features that are offered in Exchange 2013. (For more details about
the changes, see "Exchange 2013 architecture" in What's new in Exchange 2013.)
When you're upgrading your existing Exchange 2010 organization to Exchange 2013, there's a period of time
when Exchange 2010 and Exchange 2013 servers will coexist within your organization. You can maintain this
mode for an indefinite period of time, or you can immediately complete the upgrade to Exchange 2013 by moving
all resources from Exchange 2010 to Exchange 2013, and then decommissioning the Exchange 2010 servers. You
have a coexistence scenario if the following conditions are true:
Exchange 2013 is deployed in an existing Exchange organization.
More than one version of Microsoft Exchange provides messaging services to the organization.
You can't upgrade an existing Exchange 2003 organization directly to Exchange 2013. You must first upgrade the
Exchange 2003 organization to either an Exchange 2007 or Exchange 2010 organization, and then you can
upgrade the Exchange 2007 or Exchange 2010 organization to Exchange 2013. We recommend that you upgrade
your organization from Exchange 2003 to Exchange 2010, and then upgrade from Exchange 2010 to Exchange
2013.

WARNING
You need to remove all instances of Exchange 2003 from your organization before you can upgrade to Exchange 2013.

You can migrate all your Exchange 2003 mailboxes to Exchange Online. For more information about this
approach, see Ways to migrate multiple email accounts to Office 365.
The following table lists the scenarios in which coexistence between Exchange 2013 and earlier versions of
Exchange is supported.
Coexistence of Exchange 2013 and earlier versions of Exchange Server
EXCHANGE VERSION EXCHANGE ORGANIZATION COEXISTENCE

Exchange Server 2003 and earlier versions Not supported

 EXCHANGE VERSION EXCHANGE ORGANIZATION COEXISTENCE

Exchange 2007 Supported with the following minimum versions of

Exchange:
1Update Rollup 10 for Exchange 2007 Service
Pack 3 (SP3) on all Exchange 2007 servers in the
organization, including Edge Transport servers.
Exchange 2013 Cumulative Update 2 (CU2) or
later on all Exchange 2013 servers in the
organization.

Exchange 2010 Supported with the following minimum versions of

Exchange:
2 Exchange 2010 SP3 on all Exchange 2010
servers in the organization, including Edge
Transport servers.
Exchange 2013 CU2 or later on all Exchange 2013
servers in the organization.

Mixed Exchange 2010 and Exchange 2007 organization Supported with the following minimum versions of
Exchange:
1Update Rollup 10 for Exchange 2007 SP3 on all
Exchange 2007 servers in the organization,
including Edge Transport servers.
2 Exchange 2010 SP3 on all Exchange 2010
servers in the organization, including Edge
Transport servers.
Exchange 2013 CU2 or later on all Exchange 2013
servers in the organization.

1 If you want to create an EdgeSync Subscription between an Exchange 2007 Hub Transport server and an
Exchange 2013 SP1 Edge Transport server, you need to install Exchange 2007 SP3 Update Rollup 13 or later on
the Exchange 2007 Hub Transport server.
2 If you want to create an EdgeSync Subscription between an Exchange 2010 Hub Transport server and an
Exchange 2013 SP1 Edge Transport server, you need to install Exchange 2010 SP3 Update Rollup 5 or later on the
Exchange 2010 Hub Transport server.

Mixed mode coexistence of Exchange 2013 and Exchange 2007 with

Exchange 2010
If you have Active Directory sites with both Exchange 2010 and Exchange 2007 installed, follow the upgrade
instructions from both Exchange 2010 and Exchange 2007, and perform the upgrade steps required by both.

Overview of the upgrade process

To help you get an overview of the Exchange 2010 to Exchange 2013 upgrade process, we've gathered resources
related to each key task in the following table. For specific step-by-step guidance, see Checklist: Upgrade from
Exchange 2010.
TASK TOPIC

Learn about Exchange 2013 roles and components What's new in Exchange 2013
Client Access server
Mailbox server
Mail flow
Unified Messaging

Install Exchange 2013 Install Exchange 2013 using the Setup wizard
Install the Exchange 2013 Edge Transport role using the
Setup wizard (optional)
Verify an Exchange 2013 installation

Add digital certificates on the Client Access server Exchange 2013 Client Access server configuration
Digital certificates and SSL
Create a digital certificate request

Configure Exchange-related virtual directories Default settings for Exchange virtual directories

Move mailboxes from Exchange 2010 Mailbox moves in Exchange 2013

Configure transport components Edge Subscriptions (only necessary if you've installed an

Edge Transport server)
Mail routing
Shadow redundancy
Delivery reports for administrators

Configure and deploy UM Planning for Unified Messaging

Deploying voice mail and UM
 Checklist: Upgrade from Exchange 2010
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Use this checklist to upgrade from Microsoft Exchange 2010 to Exchange 2013. Before you start working with this
checklist, make sure you're familiar with the concepts discussed in:
Planning and deployment
What's new in Exchange 2013
This checklist is generic in that it provides guidance for a typical upgrade scenario.

NOTE
The Exchange Server Deployment Assistant provides you with customized step-by-step guidance about how to deploy
Exchange Server. The Deployment Assistant can help you deploy a new installation of Exchange Server 2013, upgrade a
previous version to Exchange 2013, or configure a hybrid deployment of Exchange 2013 and Exchange Online. To learn more,
see Exchange Server Deployment Assistant.

Checklist for upgrading from Exchange 2010 to Exchange 2013

Done? Task Topic(s)

1. Read the release notes. Release notes for Exchange 2013

2. Verify system requirements Exchange 2013 system

requirements

3. Confirm prerequisite steps are Exchange 2013 prerequisites

done
Deployment security checklist

4. Configure disjoint namespace Configure the DNS suffix search list

for a disjoint namespace
NOTE
This step is optional. It's only
necessary if your organization is
running a disjoint namespace.

5. Select an offline address book for Set mailbox database properties in

all Exchange 2010 mailbox Manage mailbox databases in
databases Exchange 2013
6. Install Exchange 2013 Install Exchange 2013 using the
Setup wizard
Install the Exchange 2013 Edge
Transport role using the Setup
wizard
Verify an Exchange 2013
installation

7. Create an Exchange 2013 Create user mailboxes

mailbox

8. Configure Exchange-related Exchange 2013 Client Access server

virtual directories configuration

NOTE
This step is necessary if you want
to use Exchange Web Services,
Outlook Anywhere, or the offline
address book. It also may be
required if you need to change
any of the default settings for
Exchange Control Panel,
Microsoft Office Outlook Web
App, or Exchange ActiveSync.

9. Add digital certificates on the Digital certificates and SSL

Client Access server

10. Move arbitration mailbox Move the Exchange 2010 system

mailbox to Exchange 2013

11. Configure Unified Messaging Upgrade Exchange 2010 UM to

Exchange 2013 UM
NOTE
This step is optional. It's only
necessary if you want to use
Unified Messaging in your
organization.

12. Configure Edge Transport Configure Internet mail flow

server through a subscribed Edge
Transport server
NOTE
This step is optional. It's only
necessary if your organization is
uses an Edge Transport server.
13. Enable and configure Outlook Outlook Anywhere
Anywhere

14. Configure service connection Exchange 2013 Client Access server

point configuration

15. Configure DNS records Configure DNS records for

Exchange 2010 multiple-server
install

16. Move mailboxes from Exchange Mailbox moves in Exchange 2013

2010 to Exchange 2013

17. Move public folder data from Public folders

Exchange 2013 to Exchange 2013
Use serial migration to migrate
public folders to Exchange 2013
from previous versions

18. Post-installation tasks Exchange 2013 post-Installation

tasks
 Upgrade from Exchange 2007 to Exchange 2013
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2010 and Exchange Server 2007 have multiple server roles: Client Access, Mailbox,
Hub Transport, Unified Messaging, and Edge Transport. With Exchange Server 2013, we reduced the number of
server roles from five to three: Client Access, Mailbox, and Edge Transport. Unified Messaging is now considered a
component or sub feature of the voice-related features that are offered in Exchange 2013. (For more details about
the changes, see "Exchange 2013 architecture" in What's new in Exchange 2013.)
When you're upgrading your existing Exchange 2007 organization to Exchange 2013, there's a period of time
when Exchange 2007 and Exchange 2013 servers will coexist within your organization. You can maintain this
mode for an indefinite period of time, or you can immediately complete the upgrade to Exchange 2013 by moving
all resources from Exchange 2007 to Exchange 2013, and then decommissioning the Exchange 2007 servers. You
have a coexistence scenario if the following conditions are true:
Exchange 2013 is deployed in an existing Exchange organization.
More than one version of Microsoft Exchange provides messaging services to the organization.
You can't upgrade an existing Exchange 2003 organization directly to Exchange 2013. You must first upgrade the
Exchange 2003 organization to either an Exchange 2007 or Exchange 2010 organization, and then you can
upgrade the Exchange 2007 or Exchange 2010 organization to Exchange 2013. We recommend that you upgrade
your organization from Exchange 2003 to Exchange 2010, and then upgrade from Exchange 2010 to Exchange
2013.

WARNING
You need to remove all instances of Exchange 2003 from your organization before you can upgrade to Exchange 2013.

You can migrate all your Exchange 2003 mailboxes to Exchange Online. For more information about this
approach, see Ways to migrate multiple email accounts to Office 365.
The following table lists the scenarios in which coexistence between Exchange 2013 and earlier versions of
Exchange is supported.
Coexistence of Exchange 2013 and earlier versions of Exchange Server
EXCHANGE VERSION EXCHANGE ORGANIZATION COEXISTENCE

Exchange Server 2003 and earlier versions Not supported

 EXCHANGE VERSION EXCHANGE ORGANIZATION COEXISTENCE

Exchange 2007 Supported with the following minimum versions of

Exchange:
1Update Rollup 10 for Exchange 2007 Service
Pack 3 (SP3) on all Exchange 2007 servers in the
organization, including Edge Transport servers.
Exchange 2013 Cumulative Update 2 (CU2) or
later on all Exchange 2013 servers in the
organization.

Exchange 2010 Supported with the following minimum versions of

Exchange:
2 Exchange 2010 SP3 on all Exchange 2010
servers in the organization, including Edge
Transport servers.
Exchange 2013 CU2 or later on all Exchange 2013
servers in the organization.

Mixed Exchange 2010 and Exchange 2007 organization Supported with the following minimum versions of
Exchange:
1Update Rollup 10 for Exchange 2007 SP3 on all
Exchange 2007 servers in the organization,
including Edge Transport servers.
2 Exchange 2010 SP3 on all Exchange 2010
servers in the organization, including Edge
Transport servers.
Exchange 2013 CU2 or later on all Exchange 2013
servers in the organization.

1 If you want to create an EdgeSync Subscription between an Exchange 2007 Hub Transport server and an
Exchange 2013 SP1 Edge Transport server, you need to install Exchange 2007 SP3 Update Rollup 13 or later on
the Exchange 2007 Hub Transport server.
2 If you want to create an EdgeSync Subscription between an Exchange 2010 Hub Transport server and an
Exchange 2013 SP1 Edge Transport server, you need to install Exchange 2010 SP3 Update Rollup 5 or later on the
Exchange 2010 Hub Transport server.

Mixed mode coexistence of Exchange 2013 and Exchange 2007 with

Exchange 2010
If you have Active Directory sites with both Exchange 2010 and Exchange 2007 installed, follow the upgrade
instructions from both Exchange 2010 and Exchange 2007, and perform the upgrade steps required by both.

Overview of the upgrade process

To help you get an overview of the Exchange 2007 to Exchange 2013 upgrade process, we've gathered resources
related to each key task in the following table. For specific step-by-step guidance, see Checklist: Upgrade from
Exchange 2007.
TASK TOPIC

Learn about Exchange 2013 roles and components What's new in Exchange 2013
Client Access server
Mailbox server
Mail flow
Unified Messaging

Install Exchange 2013 Install Exchange 2013 using the Setup wizard
Install the Exchange 2013 Edge Transport role using the
Setup wizard (optional)
Verify an Exchange 2013 installation

Add digital certificates on the Client Access server Exchange 2013 Client Access server configuration
Digital certificates and SSL
Create a digital certificate request

Configure Exchange-related virtual directories Default settings for Exchange virtual directories

Move mailboxes from Exchange 2010 Mailbox moves in Exchange 2013

Configure transport components Edge Subscriptions (only necessary if you've installed an

Edge Transport server)
Mail routing
Shadow redundancy
Delivery reports for administrators

Configure and deploy UM Planning for Unified Messaging

Deploying voice mail and UM
 Checklist: Upgrade from Exchange 2007
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Use this checklist to upgrade from Microsoft Exchange Server 2007 to Exchange Server 2013. Before you start
working with this checklist, make sure you're familiar with the concepts discussed in:
Planning and deployment
What's new in Exchange 2013
This checklist is generic in that it provides guidance for a typical upgrade scenario.

NOTE
The Exchange Server Deployment Assistant provides you with customized step-by-step guidance about how to deploy
Exchange Server. The Deployment Assistant can help you deploy a new installation of Exchange Server 2013, upgrade a
previous version to Exchange 2013, or configure a hybrid deployment of Exchange 2013 and Exchange Online. To learn more,
see Exchange Server Deployment Assistant.

Checklist for upgrading from Exchange 2007 to Exchange 2013

Done? Task Topic(s)

1. Read the release notes. Release notes for Exchange 2013

2. Verify system requirements Exchange 2013 system

requirements

3. Confirm prerequisite steps are Exchange 2013 prerequisites

done
Deployment security checklist

4. Configure disjoint namespace Configure the DNS suffix search list

for a disjoint namespace
NOTE
This step is optional. It's only
necessary if your organization is
running a disjoint namespace.

5. Select an offline address book for How to Provision Recipients for

all Exchange 2007 mailbox Offline Address Book Downloads
databases
6. Create legacy Exchange Create a legacy Exchange host
hostname name

7. Install Exchange 2013 Install Exchange 2013 using the

Setup wizard
Install the Exchange 2013 Edge
Transport role using the Setup
wizard
Verify an Exchange 2013
installation

8. Create an Exchange 2013 Create user mailboxes

mailbox

9. Configure Exchange-related Exchange 2013 Client Access server

virtual directories configuration

NOTE
This step is necessary if you want
to use Exchange Web Services,
Outlook Anywhere, or the offline
address book. It also may be
required if you need to change
any of the default settings for
Exchange Control Panel,
Microsoft Office Outlook Web
App, or Exchange ActiveSync.

10. Configure Exchange 2013 Digital certificates and SSL

certificates

11. Configure Exchange 2007 Managing SSL for a Client Access

certificates Server

12. Configure Edge Transport Configure Internet mail flow

server through a subscribed Edge
Transport server
NOTE
This step is optional. It's only
necessary if your organization is
uses an Edge Transport server.
13. Configure Unified Messaging Planning for Unified Messaging
Deploy Exchange 2013 UM
NOTE
This step is optional. It's only
necessary if you want to use
Unified Messaging in your
organization.

14. Enable and configure Outlook Outlook Anywhere

Anywhere

15. Configure service connection Exchange 2013 Client Access server

point configuration

16. Configure Exchange 2007 URLs Configure Exchange 2007 external

URLs

17. Configure DNS records Configure DNS records for

Exchange 2007 multiple-server
install

18. Move mailboxes from Exchange Mailbox moves in Exchange 2013

2007 to Exchange 2013

19. Move public folder data from Public folders

Exchange 2007 to Exchange 2013
Use serial migration to migrate
public folders to Exchange 2013
NOTE from previous versions
This step is optional. It's only
necessary if your organization is
uses public folders.

20. Post-installation tasks Exchange 2013 post-Installation

tasks
 Deploy multiple forest topologies for Exchange 2013
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic provides an overview of deploying Microsoft Exchange Server 2013 in multiple forest topologies. You'll
find information about the following subjects:
Supported multiple forest topologies: Exchange 2013 supports two types of multiple forest topologies:
cross-forest and resource forest.
GAL synchronization: If you have a cross-forest environment, you need to ensure that the GAL in any
given forest contains mail recipients from other forests.
Moving mailboxes across forests: The New-MoveRequest and New-MigrationBatch cmdlets in the
Exchange Management Shell can help move mailboxes from one forest to another.
Understanding multiple forest administration: Learn about the permissions model to configure and
manage the permissions between your forests.

Supported multiple forest topologies

Exchange 2013 supports the following types of multiple forest topologies:
Cross-forest: A cross-forest topology is one with multiple Exchange forests. Here is an overview of what
you need to do to deploy Exchange 2013 in a topology with a multiple forest:
1. You must first install Exchange 2013 in each forest. For more information, see Deploy a new
installation of Exchange 2013.
2. Next, you must synchronize the recipients in each of the forests, so that the Global Address List
(GAL ) in each forest contains users from all the synchronized forests. See the "GAL Synchronization"
section below for more details.
3. Finally, you must configure the Availability service so that users in one forest can view availability
data for users in another forest. For more information, see Configure the Availability service for
cross-forest topologies.
For details about deploying Exchange 2013 in a cross-forest topology, see Deploy Exchange 2013 in a
cross-forest topology.
Resource forest: A resource forest topology is one with an Exchange forest and one or more user accounts
forests. Here is an overview of what you need to do to deploy Exchange 2013 in a topology with a resource
forest:
1. You must have a forest with Exchange installed. In the Exchange forest, you must have disabled the
user accounts that have Exchange mailboxes.
2. You must have at least one forest that contains user accounts. This forest should not have Exchange
installed.
3. Then, you must associate the disabled user accounts in the Exchange forest with the user accounts in
the accounts forest.
For details about deploying Exchange 2013 in a resource forest topology, see Deploy Exchange 2013 in an
 Exchange resource forest topology.

GAL synchronization
By default, a GAL contains mail recipients from a single forest. If you have a cross-forest environment, we
recommend using Microsoft Identity Lifecycle Manager (ILM ) 2007 Feature Pack 1 (FP1) to ensure that the GAL in
any given forest contains mail recipients from other forests. ILM 2007 FP1 creates mail users that represent
recipients from other forests, thereby allowing users to view them in the GAL and send mail. For example, users in
Forest A appear as a mail user in Forest B and vice versa. Users in the target forest can then select the mail user
object that represents a recipient in another forest to send mail.
To enable GAL synchronization, you create management agents that import mail-enabled users, contacts, and
groups from designated Active Directory services into a centralized metadirectory. In the metadirectory, mail-
enabled objects are represented as mail users. Groups are represented as contacts without any associated
membership. The management agents then export these mail users to an organizational unit in the specified target
forest.
For more information about Forefront Identity Manager (FIM ), see Forefront Identity Manager 2010.

Moving mailboxes across forests

In a cross-forest topology, you may want to move mailboxes from one forest to another. To do this you must use
the New-MoveRequest or New-MigrationBatch cmdlet in the Exchange Management Shell. For more
information about moving mailboxes across forests, see the following topics:
Prepare mailboxes for cross-forest move requests
Prepare mailboxes for cross-forest moves using the Prepare-MoveRequest.ps1 script in the Shell
Prepare mailboxes for cross-forest moves using sample code

Understanding multiple forest administration

Exchange 2013 uses new permissions functionality to manage your multiple forest environments.
Exchange 2013 uses a Role Based Access Control (RBAC ) permissions model. The management role groups that
administrators are members of, and the management role assignment policies that end-users are assigned,
determine what each administrator and end-user can do. To understand multiple forest permissions, you need to
be familiar with RBAC. For more information about RBAC and role groups and role assignment policies in
particular, see Understanding Role Based Access Control.
You can use the RBAC permissions model to configure and manage the permissions between your forests. For
more information about multiple forest permissions, see the following topics:
Understanding multiple-forest permissions
Manage linked role groups
Create linked role groups that mirror built-in role groups
 Deploy Exchange 2013 in a cross-forest topology
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic explains how to deploy Exchange 2013 in a cross-forest topology using Microsoft Forefront Identity
Manager 2010 R2 SP1. To deploy Exchange 2013 in a cross-forest topology, you must first install Exchange 2013
in each forest, and then connect the forests so that users can see address and availability data across the forests.
The following figure illustrates user synchronization between two Exchange 2013 forests.
Example of Exchange 2013 cross-forest synchronization

This topic does not describe how to deploy Exchange 2013 in a dedicated Exchange forest (or resource forest)
topology. For more information about how to deploy Exchange 2013 in a resource forest topology, see Deploy
Exchange 2013 in an Exchange resource forest topology.

What do you need to know before you begin?

To perform the following procedure in Exchange 2013, confirm the following:
You have correctly configured Domain Name System (DNS ) for name resolution across forests in your
organization. To verify that DNS is configured correctly, use the Ping tool to test connectivity to each forest
from the other forests in your organization and from the server on which you will run the GALSync agent.
The GALSync management agent (MA) communicates with the Exchange 2013 forest using Windows
PowerShell V2.0 RTM. Make sure Windows PowerShell v1.0 isn't installed on this computer by going to
Control Panel, and then clicking Programs and Features.
Ensure that Windows Remote Management has not been installed by Windows Update.
Install Windows PowerShell and Windows Remote Management. For details, see Microsoft Knowledge
Base article 968930, Windows Management Framework Core package (Windows PowerShell 2.0 and
WinRM 2.0).
Download Forefront Identity Manager 2010 R2 SP1. See Download of Microsoft Forefront Identity
Manager 2010 R2 SP1.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
 TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Deploy Exchange 2013 in a cross-forest topology with Forefront

Identity Manager 2010 R2 SP1
1. In each forest, install Exchange 2013 separately. To install Exchange 2013, perform the same steps that you
would if you were installing Exchange 2013 in a single forest topology. For detailed steps, see one of the
following topics:
Deploy a new installation of Exchange 2013
Install Exchange 2013 using the Setup wizard

NOTE
This topic assumes that you don't have an existing Exchange 2007 or Exchange 2010 topology. If you do
have an existing Exchange topology and you want to upgrade, see Upgrade from Exchange 2010 to Exchange
2013 or Upgrade from Exchange 2007 to Exchange 2013.

2. In each forest, use Active Directory Users and Computers to create a container in which FIM 2010 R2 SP1
will create contacts for each mailbox from the other forest. We recommend that you name this container
FromFIM. To create the container, select the domain in which you want to create the container, right-click
the domain, select New > Organizational Unit. In New Object - Organizational Unit, type FromFIM,
and then click OK.
3. Create a GALSync management agent for each forest by using Forefront Identify Manager. This allows you
to synchronize the users in each forest and create a common GAL. For detailed steps, see the following
resources:
Configuring Global Address List (GAL ) Synchronization with Forefront Identity Manager (FIM ) 2010
Work with Management Agents
Forefront Identity Manager 2010 R2 Documentation Roadmap

IMPORTANT
While the resources discuss Exchange 2010, Exchange 2013 is supported for FIM 2010 R2 SP1. Make sure that you
configure Extensions in FIM 2010 R2 SP1 for Exchange 2013.

On the Configure Extensions page, under Configure partition display name(s), next to Provision for,
select Exchange 2013. You will see the Exchange 2013 RPS URI field. Enter the URI of an Exchange 2013
Client Access server to make sure the remote PowerShell connection is functioning. The Exchange 2013
RPS URI should be in the following format: http://CAS_Server_FQDN/Powershell. Click OK.

NOTE
Make sure that the administrator credentials used to connect to the Exchange 2013 forest can also make remote
PowerShell connections to that forest.
The following figure shows how to select provisioning for Exchange 2013.
 Provision GalSync Management Agent for Exchange 2013

4. Create an SMTP Send connector in each of the forests. For detailed steps, see Configure a cross-forest
Send connector.
5. In each forest, enable the Availability service so that users in each forest can view free/busy data about
users in the other forest. For more information, see Availability service in Exchange 2013.
6. If you want mail relayed through any forest in your organization, you must configure a domain in that forest
as an authoritative domain. For detailed steps, see Configure Exchange to accept mail for multiple
authoritative domains.
 Deploy Exchange 2013 in an Exchange resource forest
topology
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic explains how to deploy Microsoft Exchange 2013 in an Exchange resource forest topology. An Exchange
resource forest is also called a dedicated Exchange forest. This topic assumes that you don't have an existing
Exchange 2013 topology.
The following figure shows an Exchange organization with a resource forest.
Example of an Exchange organization with an Exchange resource forest

What do you need to know before you begin?

To perform the following procedure in Exchange 2013, confirm you have the following:
You have the following two Active Directory forests:
One forest contains the user accounts for your organization. In this procedure, this forest is called the
accounts forest.
One forest does not contain user accounts and does not yet have Exchange installed. In this
procedure, this forest is called the Exchange forest. You will use the procedure to install Exchange
2013 in this forest.
You have correctly configured Domain Name System (DNS ) for name resolution across forests in your
organization. To check that you have DNS configured correctly, ping each forest from the other forest or
forests in your organization. For more information about configuring DNS, see the DNS Servers
Operations Guide.

Deploy Exchange 2013 in an Exchange resource forest topology

1. From a domain controller in the Exchange forest, create a one-way outgoing trust so that the Exchange
forest trusts the accounts forest. For detailed steps, see Create a one-way, outgoing, forest trust for both
sides of the trust.
 NOTE
Although we recommend that you create a forest trust, you can create either a forest trust or an external trust. If you
create an external trust, when you create linked mailboxes in Step 3, on the Master Account page of the New
Mailbox wizard, you must specify a user account that can access the domain controller in the trusted forest. You can't
use the credentials with which you are currently logged on. If you create linked mailboxes by using the New-
Mailbox cmdlet, you must specify a user account that can access the domain controller in the trusted forest by
using the LinkedCredential parameter.

2. In the Exchange forest, install Exchange 2013. Install Exchange the same way that you would in a single
forest scenario. For detailed steps about how to install Exchange 2013, see one of the following topics:
Deploy a new installation of Exchange 2013
Install Exchange 2013 using the Setup wizard
3. In the Exchange forest, for each user in the accounts forest that will have a mailbox in the Exchange forest,
create a mailbox that is associated with an external account. For detailed steps, see Manage linked
mailboxes.
 Exchange 2013 post-Installation tasks
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

After you've completed the installation of Microsoft Exchange Server 2013, read the following topics to help
you configure your new Exchange 2013 organization.

TOPIC DESCRIPTION

Enter your Exchange 2013 product key Read this topic to license an Microsoft Exchange server.

Configure mail flow and client access Read this topic to configure mail flow to and from the
Internet and configure Microsoft Exchange to accept
client connections from the Internet.

Configure Internet mail flow through a subscribed Edge Read this topic if you're installing an Edge Transport
Transport server server and you want to configure an EdgeSync
Subscription between that server and a Hub Transport
server.

Verify an Exchange 2013 installation Read this topic to verify that Exchange 2013 was
installed successfully in your organization.

Install the Exchange 2013 management tools Read this topic to install the Exchange Management
Shell and Exchange Toolbox on client workstations or
other non-Exchange servers in your organization.

If you want to configure additional features, such as permissions, compliance, high availability, and more, see
Exchange Server 2013.
 Enter your Exchange 2013 product key
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

A product key tells Exchange Server 2013 that you've purchased a Standard or Enterprise Edition license. If the
product key you purchased is for an Enterprise Edition license, it lets you mount more than five databases per
server in addition to everything that's available with a Standard Edition license. If you want to read more about
Exchange licensing, see Exchange 2013: editions and versions.
If you don't enter a product key, your server is automatically licensed as a trial edition. The trial edition functions
just like an Exchange Standard Edition server and is helpful if you want to try out Exchange before you buy it, or to
run tests in a lab. The only difference is that you can only use an Exchange server licensed as a trial edition for up
to 180 days. If you want to keep using the server beyond 180 days, you'll need to enter a product key or the
Exchange admin center (EAC ) will start to show reminders that you need to enter a product key to license the
server.

TIP
We've noticed some visitors to this page are looking for information on how to install or activate Office. If that's you, check
out these pages:
Install Office
Need help with your Office product key?
If you want to enter a product key on an Exchange 2010 server, go to Enter an Exchange 2010 product key.
If you want to enter a product key on an Exchange 2013 server, you're in the right place! Read on.

What do you need to know before you begin?

Estimated time to complete this procedure: less than 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Product key" entry in the Exchange and Shell infrastructure permissions
topic.
If you're licensing an Exchange server that's running the Mailbox server role, you'll need to restart the
Microsoft Exchange Information Store service on the server after you enter the product key.
If you want to upgrade an Exchange server from a Standard Edition license to an Enterprise Edition license,
follow the steps in this topic.
If you want to downgrade an Exchange server from an Enterprise Edition license to a Standard Edition
license, you need to reinstall Exchange.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Use the EAC to enter the product key
1. Open the EAC by browsing to https://<Client Access server name>/ecp.
2. Enter your user name and password in Domain\user name and Password, and then click Sign in.
3. Go to Servers > Servers. Select the server you want to license, and then click Edit .
4. (Optional) If you want to upgrade the server from a Standard Edition license to an Enterprise Edition
license, on the General page, select Change product key. You'll only see this option if the server is already
licensed.
5. On the General page, enter your product key in the Enter a valid product key text boxes.
6. Click Save.
7. If you licensed an Exchange server running the Mailbox server role, do the following to restart the Microsoft
Exchange Information Store service:
a. Open Control Panel, go to Administrative Tools, and then open Services.
b. Right-click on Microsoft Exchange Information Store and click Restart.

Use the Shell to enter the product key

This example uses the set-ExchangeServer cmdlet to enter the product key.

NOTE
You can run this command again on the same server to upgrade it from a Standard Edition license to an Enterprise Edition
license.

Set-ExchangeServer ExServer01 -ProductKey aaaaa-aaaaa-aaaaa-aaaaa-aaaaa

For detailed syntax and parameter information, see Set-ExchangeServer.

If you licensed an Exchange server running the Mailbox server role, do the following to restart the Microsoft
Exchange Information Store service:
1. Open Control Panel, go to Administrative Tools, and then open Services.
2. Right-click Microsoft Exchange Information Store and click Restart.

How do you know this worked?

To use the EAC to verify that you've successfully licensed the server as Standard Edition or Enterprise Edition, do
the following:
1. Enter your user name and password in Domain\user name and Password, and then click Sign in.
2. Go to Servers > Servers.
3. Select the server you want to view, and then look in the server details pane. If the product key has been
accepted, Licensed will appear along with the Exchange 2013 edition.
To use the Shell to verify that you've successfully licensed the server as Standard Edition or Enterprise Edition, do
the following:
1. Open the Shell.
2. Run the following command to view the licensing status of a specific Exchange server.

Get-ExchangeServer ExServer01 | Format-Table Edition,*Trial*

3. (Optional) Run the following command to view the licensing status of all Exchange servers in your
organization.

Get-ExchangeServer | Format-Table Name, Edition, *Trial* -Auto

 Configure mail flow and client access
6/14/2019 • 19 minutes to read • Edit Online

Applies to: Exchange Server 2013

Post-installation tasks for Exchange Server 2013 mail flow and client access, including how to configure an SSL
certificate.
After you've installed Microsoft Exchange Server 2013 in your organization, you need to configure Exchange
Server 2013 for mail flow and client access. Without these additional steps, you won't be able to send mail to the
Internet and external clients such as Microsoft Outlook and Exchange ActiveSync devices won't be able to
connect to your Exchange organization.
The steps in this topic assume a basic Exchange deployment with a single Active Directory site and a single
simple mail transport protocol (SMTP ) namespace.

IMPORTANT
This topic uses example values such as Ex2013CAS, contoso.com, mail.contoso.com, and 172.16.10.11. Replace the
example values with the server names, FQDNs, and IP addresses for your organization.

For additional management tasks related to mail flow and clients and devices, see Mail flow and Clients and
mobile.

What do you need to know before you begin?

Estimated time to complete this task: 50 minutes
Procedures in this topic require specific permissions. See each procedure for its permissions information.
You might receive certificate warnings when you connect to the Exchange admin center (EAC ) website
until you configure a secure sockets layer (SSL ) certificate on the Client Access server. You'll be shown
how to do this later in this topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

IMPORTANT
Each organization requires at a minimum one Client Access server and one Mailbox server in the Active Directory forest.
Additionally, each Active Directory site that contains a Mailbox server must also contain at least one Client Access server. If
you're separating your server roles, we recommend installing the Mailbox server role first.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Create a Send connector

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Send connectors" entry in the Mail flow permissions topic.
Before you can send mail to the Internet, you need to create a Send connector on the Mailbox server. Do the
following.
1. Open the EAC by browsing to the URL of your Client Access server. For example,
https://Ex2013CAS/ECP.
2. Enter your user name and password in Domain\user name and Password and then click Sign in.
3. Go to Mail flow > Send connectors. On the Send connectors page, click New .
4. In the New send connector wizard, specify a name for the Send connector and then select Internet.
Click Next.
5. Verify that MX record associated with recipient domain is selected. Click Next.
6. Under Address space, click Add . In the Add domain window, make sure SMTP is selected in the
Type field. In the Fully Qualified Domain Name (FQDN ) field, enter *. Click Save.
7. Make sure Scoped send connector isn't selected and then click Next.
8. Under Source server, click Add . In the Select a Server window, select a Mailbox server. After you've
selected the server, click Add and then click OK.
9. Click Finish.

NOTE
A default inbound Receive connector is created when Exchange 2013 is installed. This Receive connector accepts
anonymous SMTP connections from external servers. You don't need to do any additional configuration if this is the
functionality you want. If you want to restrict inbound connections from external servers, modify the Default Frontend
<Client Access server> Receive connector on the Client Access server.

How do you know this step worked?

To verify that you have successfully created an outbound Send connector, do the following:
1. In the EAC, verify the new Send connector appears in Mail flow > Send connectors.
2. Open Outlook Web App and send an email message to an external recipient. If the recipient receives the
message, you've successfully configured the Send connector.

Step 2: Add additional accepted domains

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Accepted domains" entry in the Mail flow permissions topic.
By default, when you deploy a new Exchange 2013 organization in an Active Directory forest, Exchange uses the
domain name of the Active Directory domain where Setup /PrepareAD was run. If you want recipients to
receive and send messages to and from another domain, you must add the domain as an accepted domain. This
domain is also added as the primary SMTP address on the default email address policy in the next step.

IMPORTANT
A public Domain Name System (DNS) MX resource record is required for each SMTP domain for which you accept email
from the Internet. Each MX record should resolve to the Internet-facing server that receives email for your organization.

1. Open the EAC by browsing to the URL of your Client Access server. For example,
 https://Ex2013CAS/ECP.
2. Enter your user name and password in Domain\user name and Password and then click Sign in.
3. Go to Mail flow > Accepted domains. On the Accepted domains page, click New .
4. In the New accepted domain wizard, specify a name for the accepted domain.
5. In the Accepted domain field, specify the SMTP recipient domain you want to add. For example,
contoso.com.
6. Select Authoritative domain and then click Save.
How do you know this step worked?
In the EAC, verify the new accepted domain appears in Mail flow > Accepted domains.

Step 3: Configure the default email address policy

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Email address policies" entry in the Email address and address book permissions
topic.
If you added an accepted domain in the previous step and you want that domain to be added to every recipient
in the organization, you need to update the default email address policy.
1. Open the EAC by browsing to the URL of your Client Access server. For example,
https://Ex2013CAS/ECP.
2. Enter your user name and password in Domain\user name and Password and then click Sign in.
3. Go to Mail flow > Email address policies. On the Email address policies page, select Default Policy
and then click Edit .
4. On the Default Policy Email Address Policy page, click Email Address Format.
5. Under Email address format, click the SMTP address you want to change and then click Edit .
6. On the Email address format page in the Email address parameters field, specify the SMTP recipient
domain you want to apply to all recipients in the Exchange organization. This domain must match the
accepted domain you added in the previous step. For example, @contoso.com. Click Save.
7. Click Save
8. In the Default Policy details pane, click Apply.

NOTE
We recommend that you configure a user principal name (UPN) that matches the primary email address of each user. If
you don't provide a UPN that matches the email address of a user, the user will be required to manually provide their
domain\user name or UPN in addition to their email address. If their UPN matches their email address, Outlook Web App,
ActiveSync, and Outlook will automatically match their email address to their UPN.

How do you know this step worked?

To verify that you have successfully configured the default email address policy, do the following:
1. In the EAC, go to Recipients > Mailboxes.
2. Select a mailbox and then, in the recipient details pane, verify that the User mailbox field has been set to
<alias>@<new accepted domain>. For example, [email protected].
 3. Optionally, create a new mailbox and verify the mailbox is given an email address with the new accepted
domain by doing the following:
a. Go to Recipients > Mailboxes, click New and then select User mailbox.
b. On the new user mailbox page, provide the information required to create a new mailbox. Click
Save.
c. Select the new mailbox and then, in the recipient details pane, verify that the User mailbox field
has been set to <alias>@<new accepted domain>. For example, [email protected].

Step 4: Configure external URLs

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "<Service> virtual directory settings" entry in the Clients and mobile devices
permissions topic.
Before clients can connect to your new server from the Internet, you need to configure the external domains, or
URLs, on the Client Access server's virtual directories and then configure your public domain name service
(DNS ) records. The steps below configure the same external domain on the external URL of each virtual
directory. If you want to configure different external domains on one or more virtual directory external URLs,
you need to configure the external URLs manually. For more information, see Virtual directory management.
1. Open the EAC by browsing to the URL of your Client Access server. For example,
https://Ex2013CAS/ECP.
2. Enter your user name and password in Domain\user name and Password and then click Sign in.
3. Go to Servers > Servers, select the name of the Internet-facing Client Access server and then click Edit
.
4. Click Outlook Anywhere.
5. In the Specify the external hostname field, specify the externally accessible FQDN of the Client Access
server. For example, mail.contoso.com.
6. While you're here, let's also set the internally accessible FQDN of the Client Access server. In theSpecify
the internal hostname field, insert the FQDN you used in the previous step. For example,
mail.contoso.com.
7. Click Save.
8. Go to Servers > Virtual directories and then click Configure external access domain .
9. Under Select the Client Access servers to use with the external URL, click Add
10. Select the Client Access servers you want to configure and then click Add. After you've added all of the
Client Access servers you want to configure, click OK.
11. In Enter the domain name you will use with your external Client Access servers, type the external
domain you want to apply. For example, mail.contoso.com. Click Save.
 NOTE
Some organizations make the Outlook Web App FQDN unique to protect users against changes to underlying
server FQDN changes. Many organizations use owa.contoso.com for their Outlook Web App FQDN instead of
mail.contoso.com. If you want to configure a unique Outlook Web App FQDN, do the following after you
completed the previous step. This checklist assumes you have configured a unique Outlook Web App FQDN.
1. Select owa (Default Web Site) and click Edit .
2. In External URL, type https://, then the unique Outlook Web App FQDN you want to use, and then
append /owa. For example, https://owa.contoso.com/owa.
3. Click Save.
4. Select ecp (Default Web Site) and click Edit .
5. In External URL, type https://, then the same Outlook Web App FQDN that you specified in the previous
step, and then append /ecp. For example, https://owa.contoso.com/ecp.
6. Click Save.

After you've configured the external URL on the Client Access server virtual directories, you need to configure
your public DNS records for Autodiscover, Outlook Web App, and mail flow. The public DNS records should
point to the external IP address or FQDN of your Internet-facing Client Access server and use the externally
accessible FQDNs that you've configured on your Client Access server. The following are examples of
recommended DNS records that you should create to enable mail flow and external client connectivity.

FQDN DNS RECORD TYPE VALUE

Contoso.com MX Mail.contoso.com

Mail.contoso.com A 172.16.10.11

Owa.contoso.com CNAME Mail.contoso.com

Autodiscover.contoso.com CNAME Mail.contoso.com

How do you know this step worked?

To verify that you have successfully configured the external URL on the Client Access server virtual directories,
do the following:
1. In the EAC, go to Servers > Virtual directories.
2. In the Select server field, select the Internet-facing Client Access server.
3. Select a virtual directory and then, in the virtual directory details pane, verify that the External URL field
is populated with the correct FQDN and service as shown below:

VIRTUAL DIRECTORY EX TERNAL URL VALUE

Autodiscover No external URL displayed

ECP https://owa.contoso.com/ecp
 VIRTUAL DIRECTORY EX TERNAL URL VALUE

EWS https://mail.contoso.com/EWS/Exchange.asmx

Microsoft-Server-ActiveSync https://mail.contoso.com/Microsoft-Server-
ActiveSync

OAB https://mail.contoso.com/OAB

OWA https://owa.contoso.com/owa

PowerShell http://mail.contoso.com/PowerShell

To verify that you have successfully configured your public DNS records, do the following:
1. Open a command prompt and run nslookup.exe .
2. Change to a DNS server that can query your public DNS zone.
3. In nslookup , look up the record of each FQDN you created. Verify that the value that's returned for each
FQDN is correct.
4. In nslookup , type set type=mx and then look up the accepted domain you added in Step 1. Verify that
the value returned matches the FQDN of the Client Access server.

Step 5: Configure internal URLs

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "<Service> virtual directory settings" entry in the Clients and mobile devices
permissions topic.
Before clients can connect to your new server from yourintranet, you need to configure the internal domains, or
URLs, on the Client Access server's virtual directories and then configure your private domain name service
(DNS ) records.
The procedure below lets you choose whether you want users to use the same URL on your intranet and on the
Internet to access your Exchange server or whether they should use a different URL. What you choose depends
on the addressing scheme you have in place already or that you want to implement. If you're implementing a
new addressing scheme, we recommend that you use the same URL for both internal and external URLs. Using
the same URL makes it easier for users to access your Exchange server because they only have to remember
one address. Regardless of the choice you make, you need to make sure you configure a private DNS zone for
the address space you configure. For more information about administering DNS zones, see Administering
DNS Server.
For more information about internal and external URLs on virtual directories, see Virtual directory
management.
Configure internal and external URLs to be the same
1. Open the Exchange Management Shell on your Client Access server.
2. Store the host name of your Client Access server in a variable that will be used in the next step. For
example, Ex2013CAS.
 $HostName = "Ex2013CAS"

3. Run each of the following commands in the Shell to configure each internal URL to match the virtual
directory's external URL.

Set-EcpVirtualDirectory "$HostName\ECP (Default Web Site)" -InternalUrl ((Get-EcpVirtualDirectory

"$HostName\ECP (Default Web Site)").ExternalUrl)

Set-WebServicesVirtualDirectory "$HostName\EWS (Default Web Site)" -InternalUrl ((get-

WebServicesVirtualDirectory "$HostName\EWS (Default Web Site)").ExternalUrl)

Set-ActiveSyncVirtualDirectory "$HostName\Microsoft-Server-ActiveSync (Default Web Site)" -

InternalUrl ((Get-ActiveSyncVirtualDirectory "$HostName\Microsoft-Server-ActiveSync (Default Web
Site)").ExternalUrl)

Set-OabVirtualDirectory "$HostName\OAB (Default Web Site)" -InternalUrl ((Get-OabVirtualDirectory

"$HostName\OAB (Default Web Site)").ExternalUrl)

Set-OwaVirtualDirectory "$HostName\OWA (Default Web Site)" -InternalUrl ((Get-OwaVirtualDirectory

"$HostName\OWA (Default Web Site)").ExternalUrl)

Set-PowerShellVirtualDirectory "$HostName\PowerShell (Default Web Site)" -InternalUrl ((Get-

PowerShellVirtualDirectory "$HostName\PowerShell (Default Web Site)").ExternalUrl)

4. While we're in the Shell, let's also configure the Offline Address Book (OAB ) to allow Autodiscover to
select the right virtual directory for distributing the OAB. Run the following commands to do this.

Get-OfflineAddressBook | Set-OfflineAddressBook -GlobalWebDistributionEnabled $True -

VirtualDirectories $Null

After you've configured the internal URL on the Client Access server virtual directories, you need to configure
your private DNS records for Outlook Web App, and other connectivity. Depending on your configuration, you'll
need to configure your private DNS records to point to the internal or external IP address or fully qualified
domain name (FQDN ) of your Client Access server. The following are examples of recommended DNS records
that you should create to enable internal client connectivity.

FQDN DNS RECORD TYPE VALUE

Mail.contoso.com CNAME Ex2013CAS.corp.contoso.com

Owa.contoso.com CNAME Ex2013CAS.corp.contoso.com

How do you know this step worked?

To verify that you have successfully configured the internal URL on the Client Access server virtual directories,
do the following:
1. In the EAC, go to Servers > Virtual directories.
2. In the Select server field, select the Internet-facing Client Access server.
3. Select a virtual directory and then click Edit .
4. Verify that the Internal URL field is populated with the correct FQDN and service as shown below:
 VIRTUAL DIRECTORY INTERNAL URL VALUE

Autodiscover No internal URL displayed

ECP https://owa.contoso.com/ecp

EWS https://mail.contoso.com/EWS/Exchange.asmx

Microsoft-Server-ActiveSync https://mail.contoso.com/Microsoft-Server-
ActiveSync

OAB https://mail.contoso.com/OAB

OWA https://owa.contoso.com/owa

PowerShell http://mail.contoso.com/PowerShell

To verify that you have successfully configured your private DNS records, do the following:
1. Open a command prompt and run nslookup.exe .
2. Change to a DNS server that can query your private DNS zone.
3. In nslookup , look up the record of each FQDN you created. Verify that the value that's returned for each
FQDN is correct.

Configure different internal and external URLs

1. Open the EAC by browsing to the URL of your Client Access server. For example,
https://Ex2013CAS/ECP.
2. Go to Servers > Virtual directories.
3. In the Select server field, select the Internet-facing Client Access server.
4. Select the virtual directory you want to change and click Edit .
5. In Internal URL, replace the host name between https:// and the first forward slash ( / ) with the new
FQDN you want to use. For example, if you want to change the EWS virtual directory FQDN from
Ex2013CAS.corp.contoso.com to internal.contoso.com, change the internal URL from
https://Ex2013CAS.corp.contoso.com/ews/exchange.asmx to
https://internal.contoso.com/ews/exchange.asmx.
6. Click Save.
7. Repeat steps 5 and 6 for each virtual directory you want to change.

NOTE
The ECP and OWA virtual directory internal URLs must be the same.
You can't set an internal URL on the Autodiscover virtual directory.
8. Finally, we need to open the Shell and configure the Offline Address Book (OAB ) to allow Autodiscover
to select the right virtual directory for distributing the OAB. Run the following commands to do this.

Get-OfflineAddressBook | Set-OfflineAddressBook -GlobalWebDistributionEnabled $True -

VirtualDirectories $Null

After you've configured the internal URL on the Client Access server virtual directories, you need to configure
your private DNS records for Outlook Web App, and other connectivity. Depending on your configuration, you'll
need to configure your private DNS records to point to the internal or external IP address or FQDN of your
Client Access server. The following is an example of recommended DNS record that you should create to enable
internal client connectivity if you've configured your virtual directory internal URLs to use internal.contoso.com.

FQDN DNS RECORD TYPE VALUE

internal.contoso.com CNAME Ex2013CAS.corp.contoso.com

How do you know this step worked?

To verify that you have successfully configured the internal URL on the Client Access server virtual directories,
do the following:
1. In the EAC, go to Servers > Virtual directories.
2. In the Select server field, select the Internet-facing Client Access server.
3. Select a virtual directory and then click Edit .
4. Verify that the Internal URL field is populated with the correct FQDN. For example, you may have set
the internal URLs to use internal.contoso.com.

VIRTUAL DIRECTORY INTERNAL URL VALUE

Autodiscover No internal URL displayed

ECP https://internal.contoso.com/ecp

EWS https://internal.contoso.com/EWS/Exchange.asmx

Microsoft-Server-ActiveSync https://internal.contoso.com/Microsoft-Server-
ActiveSync

OAB https://internal.contoso.com/OAB

OWA https://internal.contoso.com/owa

PowerShell http://internal.contoso.com/PowerShell

To verify that you have successfully configured your private DNS records, do the following:
1. Open a command prompt and run nslookup.exe .
 2. Change to a DNS server that can query your private DNS zone.
3. In nslookup , look up the record of each FQDN you created. Verify that the value that's returned for each
FQDN is correct.

Step 6: Configure an SSL certificate

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Certificate management" entry in the Mail flow permissions topic.
Some services, such as Outlook Anywhere and Exchange ActiveSync, require certificates to be configured on
your Exchange 2013 server. The following steps show you how to configure an SSL certificate from a third-
party certificate authority (CA):
1. Open the EAC by browsing to the URL of your Client Access server. For example,
https://Ex2013CAS/ECP.
2. Enter your user name and password in Domain\user name and Password and then click Sign in.
3. Go to Servers > Certificates. On the Certificates page, make sure your Client Access server is selected
in the Select server field, and then click New .
4. In the New Exchange certificate wizard, select Create a request for a certificate from a
certification authority and then click Next.
5. Specify a name for this certificate and then click Next.
6. If you want to request a wildcard certificate, select Request a wild-card certificate and then specify the
root domain of all subdomains in the Root domain field. If you don't want to request a wildcard
certificate and instead want to specify each domain you want to add to the certificate, leave this page
blank. Click Next.
7. Click Browse and specify an Exchange server to store the certificate on. The server you select should be
the Internet-facing Client Access server. Click Next.
8. For each service in the list shown, verify that the external or internal server names that users will use to
connect to the Exchange server are correct. For example:
If you configured your internal and external URLs to be the same, Outlook Web App (when
accessed from the Internet) and Outlook Web App (when accessed from the Intranet)
should show owa.contoso.com. OAB (when accessed from the Internet) and OAB (when
accessed from the Intranet) should show mail.contoso.com.
If you configured the internal URLs to be internal.contoso.com, Outlook Web App (when
accessed from the Internet) should show owa.contoso.com and Outlook Web App (when
accessed from the Intranet) should show internal.contoso.com.
These domains will be used to create the SSL certificate request. Click Next.
9. Add any additional domains you want included on the SSL certificate.
10. Select the domain that you want to be the common name for the certificate, and then click Set as
common name. For example, contoso.com. Click Next.
11. Provide information about your organization. This information will be included with the SSL certificate.
Click Next.
12. Specify the network location where you want this certificate request to be saved. Click Finish.
After you've saved the certificate request, submit the request to your certificate authority (CA). This can be an
internal CA or a third-party CA, depending on your organization. Clients that connect to the Client Access
server must trust the CA that you use. After you receive the certificate from the CA, complete the following
steps:
1. On the Server > Certificates page in the EAC, select the certificate request you created in the previous
steps.
2. In the certificate request details pane, click Complete under Status.
3. On the complete pending request page, specify the path to the SSL certificate file and then click OK.
4. Select the new certificate you just added, and then click Edit .
5. On the certificate page, click Services.
6. Select the services you want to assign to this certificate. At minimum, you should select SMTP and IIS.
Click Save.
7. If you receive the warning Overwrite the existing default SMTP certificate?, click Yes.
How do you know this step worked?
To verify that you have successfully added a new certificate, do the following:
1. In the EAC, go to Servers > Certificates.
2. Select the new certificate and then, in the certificate details pane, verify that the following are true:
Status shows Valid
Assigned to services shows, at minimum, IIS and SMTP.

How do you know this task worked?

To verify that you have configured mail flow and external client access, do the following:
1. In Outlook, on an Exchange ActiveSync device, or on both, create a new profile. Verify that Outlook or the
mobile device successfully creates the new profile.
2. In Outlook, or on the mobile device, send a new message to an external recipient. Verify the external
recipient receives the message.
3. In the external recipient's mailbox, reply to the message you just sent from the Exchange mailbox. Verify
the Exchange mailbox receives the message.
4. Go to https://owa.contoso.com/owa and verify that there are no certificate warnings.
 Verify an Exchange 2013 installation
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

After you install Microsoft Exchange Server 2013, we recommend that you verify the installation by running the
Get-ExchangeServer cmdlet and by reviewing the setup log file. If the setup process fails or errors occur
during installation, you can use the setup log file to track down the source of the problem.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.

Run Get-ExchangeServer
To verify that Exchange 2013 installed successfully, run the Get-ExchangeServer cmdlet in the Exchange
Management Shell. A list is displayed of all Exchange 2013 server roles that are installed on the specified server
when this cmdlet is run.
For detailed syntax and parameter information, see Get-ExchangeServer.

Review the setup log file

You can also learn more about the installation and configuration of Exchange 2013 by reviewing the setup log
file created during the setup process.
During installation, Exchange Setup logs events in the Application log of Event Viewer on computers that are
running Windows Server 2008 R2 with Service Pack 1 (SP1) and Windows Server 2012. Review the
Application log, and make sure there are no warning or error messages related to Exchange setup. These log
files contain a history of each action that the system takes during Exchange 2013 setup and any errors that may
have occurred. By default, the logging method is set to Verbose . Information is available for each installed
server role.
You can find the setup log file at <system drive>\ExchangeSetupLogs\ExchangeSetup.log. The <system drive>
variable represents the root directory of the drive where the operating system is installed.
The setup log file tracks the progress of every task that is performed during the Exchange 2013 installation and
configuration. The file contains information about the status of the prerequisite and system readiness checks
that are performed before installation starts, the application installation progress, and the configuration changes
that are made to the system. Check this log file to verify that the server roles were installed as expected.
We recommend that you start your review of the setup log file by searching for any errors. If you find an entry
that indicates that an error occurred, read the associated text to determine the cause of the error.
 Install the Exchange 2013 management tools
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

With the Microsoft Exchange Server 2013 management tools, you can configure and manage your Exchange
organization remotely. Exchange 2013 management tools include the Exchange Management Shell and the
Exchange Toolbox. This topic explains how you can either use Setup.exe or unattended setup mode to install the
Exchange 2013 management tools.

NOTE
You don't need to perform this procedure to use the Exchange admin center (EAC) remotely. The EAC is a web-based console
that's hosted on computers running the Exchange 2013 Client Access server role. For more information about accessing the
EAC remotely, see Exchange admin center in Exchange 2013.

For more information about managing Exchange 2013, see Exchange admin center in Exchange 2013 and Using
PowerShell with Exchange 2013 (Exchange Management Shell).

What do you need to know before you begin?

Estimated time to complete: 10 minutes
Make sure you've read the release notes prior to installing Exchange 2013. For more information, see
Release notes for Exchange 2013.
The computer you install the management tools on must have a supported operating system (such as
Windows Server 2012 or Windows 8), have enough disk space, be a member of an Active Directory
domain, and satisfy other requirements. For information about system requirements, see Exchange 2013
system requirements.
To run Exchange 2013 Setup, you must install Microsoft .NET Framework 4.5, Windows Management
Framework 3.0, and other required software. To understand the prerequisites for all server roles, see
Exchange 2013 prerequisites.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use Setup to install the Exchange 2013 management tools

1. Log on to the computer on which you want to install Exchange 2013.
2. Navigate to the network location of the Exchange 2013 installation files.
3. Start Exchange 2013 Setup by double-clicking Setup.exe
 IMPORTANT
If you have User Access Control (UAC) enabled, you must right-click Setup.exe and select Run as administrator.

4. On the Check for Updates page, choose whether you want Setup to connect to the Internet and download
product and security updates for Exchange 2013. If you select Connect to the Internet and check for
updates, Setup will download updates and apply them prior to continuing. If you select Don't check for
updates right now, you can download and install updates manually later. We recommend that you
download and install updates now. Click Next to continue.
5. The Introduction page begins the process of installing Exchange into your organization. It will guide you
through the installation. Several links to helpful deployment content are listed. We recommend that you visit
these links prior to continuing setup. Click Next to continue.
6. On the License Agreement page, review the software license terms. If you agree to the terms, select I
accept the terms in the license agreement, and then click Next.
7. On the Recommended settings page, select whether you want to use the recommended settings. If you
select Use recommended settings, Exchange will automatically send error reports and information about
your computer hardware and how you use Exchange to Microsoft. If you select Don't use recommended
settings, these settings remain disabled but you can enable them at any time after Setup completes. For
more information about these settings and how information sent to Microsoft is used, click ?.
8. On the Server Role Selection page, verify that Management Tools is selected.
Select Automatically install Windows Server roles and features that are required to install
Exchange Server to have the Setup wizard install required Windows prerequisites. You may need to
reboot the computer to complete the installation of some Windows features. If you don't select this option,
you must install the Windows features manually.

NOTE
This option installs only the Windows features required by Exchange. You must manually install other prerequisites
manually. For more information, see Exchange 2013 prerequisites.

Click Next to continue.

9. On the Installation Space and Location page, either accept the default installation location or click
Browse to choose a new location. Make sure that you have enough disk space available in the location
where you want to install Exchange. Click Next to continue.
10. If this is the first time you've run Exchange 2013 Setup in your organization, on the Exchange
Organization page, type a name for your Exchange organization. The Exchange organization name can
contain only the following characters:
A through Z
a through z
0 through 9
Space (not leading or trailing)
Hyphen or dash
 NOTE
The organization name can't contain more than 64 characters. The organization name can't be blank.

If you want to use the Active Directory split permissions model, select Apply Active Directory split
permission security model to the Exchange organization.

WARNING
Most organizations don't need to apply the Active Directory split permissions model. If you need to separate
management of Active Directory security principals and Exchange configuration, Role Based Access Control (RBAC)
split permissions might work for you. For more information, click ?.

Click Next to continue.

11. On the Readiness Checks page, view the status to determine if the organization and server role
prerequisite checks completed successfully. If they haven't completed successfully, you must resolve any
reported errors before you can install Exchange 2013. You don't need to exit Setup when resolving some of
the prerequisite errors. After resolving a reported error, click back and then click Next to run the
prerequisite check again. Be sure to also review any warnings that are reported. If all readiness checks have
completed successfully, click Next to install Exchange 2013.
12. On the Completion page, click Finish.
13. Restart the computer after Exchange 2013 has completed.

Use unattended Setup mode to install the Exchange 2013

management tools
1. Log on to the computer on which you want to install the Exchange 2013 management tools.
2. Navigate to the network location of the Exchange 2013 installation files.
3. At the command prompt, run the following command.

IMPORTANT
If you have User Access Control (UAC) enabled, you must run Setup.exe from an elevated command prompt.

Setup.exe /Role:ManagementTools /IAcceptExchangeServerLicenseTerms

For more information, see Install Exchange 2013 using unattended mode.
 Exchange 2013 virtualization
6/11/2019 • 11 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can deploy Microsoft Exchange Server 2013 in a virtualized environment. This topic provides an overview of
the scenarios that are supported for deploying Exchange 2013 on hardware virtualization software.
Cold boot: When bringing a system from a power-off state into a clean start of the operating system, the
action is a cold boot. No operating system state has been persisted in this case.
Saved state: When a virtual machine is powered off, hypervisors typically have the ability to save the state
of the virtual machine, so when the machine is powered back on, it returns to that saved state rather than
going through a cold boot startup.
Planned migration: When a system administrator initiates the move of a virtual machine from one
hypervisor host to another, the action is a planned migration. The action could be a single migration, or a
system administrator could configure automation to move the virtual machine on a timed basis. A planned
migration could also be the result of some other event that occurs in the system, other than hardware or
software failure. The key point is the Exchange virtual machine is operating normally and needs to be
relocated for some reason. This relocation can be done via technology, like Live Migration or vMotion.
However, if the Exchange virtual machine or the hypervisor host where the virtual machine is located
experiences some sort of failure condition, the outcome isn't characterized as a planned migration.

Requirements for hardware virtualization

Microsoft supports Exchange 2013 in production on hardware virtualization software only when all the following
conditions are true:
The hardware virtualization software is running one of the following:
Any version of Windows Server with Hyper-V technology or Microsoft Hyper-V Server
Any third-party hypervisor that has been validated under the Windows Server Virtualization
Validation Program.

NOTE
Deployment of Exchange 2013 on Infrastructure-as-a-Service (IaaS) providers is supported if all supportability
requirements are met. In the case of providers who are provisioning virtual machines, these requirements include
ensuring that the hypervisor being used for Exchange virtual machines is fully supported, and that the infrastructure
to be utilized by Exchange meets the performance requirements that were determined during the sizing process.
Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases
and database transaction logs (including transport databases) are configured for Azure Premium Storage.

The Exchange guest virtual machine has the following conditions:

It's running Exchange 2013.
It's deployed on Windows Server 2008 R2 SP1 (or later versions), Windows Server 2012, or on
Windows Server 2012 R2.
For deployments of Exchange 2013:
All Exchange 2013 server roles are supported in a virtual machine.
Exchange server virtual machines (including Exchange Mailbox virtual machines that are part of a database
availability group, or DAG ), may be combined with host-based failover clustering and migration
technology, as long as the virtual machines are configured such that they won't save and restore state on
disk when moved or taken offline. All failover activity occurring at the hypervisor level must result in a cold
boot when the virtual machine is activated on the target node. All planned migration must either result in
shutdown and cold boot, or an online migration that makes use of a technology like Hyper-V Live
Migration. Hypervisor migration of virtual machines is supported by the hypervisor vendor; therefore, you
must ensure that your hypervisor vendor has tested and supports migration of Exchange virtual machines.
Microsoft supports Hyper-V Live Migration of these virtual machines.
Only management software (for example, antivirus software, backup software, or virtual machine
management software) can be deployed on the physical host machine. No other server-based applications
(for example, Exchange, SQL Server, Active Directory, or SAP ) should be installed on the host machine.
The host machine should be dedicated to running guest virtual machines.
Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots
capture the state of a virtual machine while it's running. This feature enables you to take multiple
snapshots of a virtual machine and then revert the virtual machine to any of the previous states by
applying a snapshot to the virtual machine. However, virtual machine snapshots aren't application aware,
and using them can have unintended and unexpected consequences for a server application that maintains
state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual
machine isn't supported.
Many hardware virtualization products allow you to specify the number of virtual processors that should
be allocated to each guest virtual machine. The virtual processors located in the guest virtual machine
share a fixed number of physical processor cores in the physical system. Exchange supports a virtual
processor-to-physical processor core ratio no greater than 2:1, although we recommend a ratio of 1:1. For
example, a dual processor system using quad core processors contains a total of 8 physical processor cores
in the host system. On a system with this configuration, don't allocate more than a total of 16 virtual
processors to all guest virtual machines combined.
When calculating the total number of virtual processors required by the host machine, you must also
account for both I/O and operating system requirements. In most cases, the equivalent number of virtual
processors required in the host operating system for a system hosting Exchange virtual machines is 2. This
value should be used as a baseline for the host operating system virtual processor when calculating the
overall ratio of physical cores to virtual processors. If performance monitoring of the host operating
system indicates you're consuming more processor utilization than the equivalent of 2 processors, you
should reduce the count of virtual processors assigned to guest virtual machines accordingly and verify
that the overall virtual processor-to-physical core ratio is no greater than 2:1.
The operating system for an Exchange guest machine must use a disk that has a size equal to at least
15 gigabytes (GB ) plus the size of the virtual memory that's allocated to the guest machine. This
requirement is necessary to account for the operating system and paging file disk requirements. For
example, if the guest machine is allocated 16 GB of memory, the minimum disk space needed for the guest
operating system disk is 31 GB.
In addition, it's possible that guest virtual machines may be prevented from directly communicating with
Fibre Channel or SCSI host bus adapters (HBAs) installed in the host machine. In this event, you must
configure the adapters in the host machine's operating system and present the logical unit numbers (LUNs)
to guest virtual machines as either a virtual disk or a pass-through disk.
The only supported way to send emails to external domains from Azure compute resources is via an SMTP
relay (otherwise known as an SMTP smart host). The Azure compute resource sends the email to the
 SMTP relay and then the SMTP relay provider delivers the email to the external domain. Microsoft
Exchange Online Protection is one provider of an SMTP relay, but there are a number of third party
providers as well. For more information, see the Microsoft Azure Support Team Blog post Sending E -mail
from Azure Compute Resource to External Domains.

Host machine storage requirements

The minimum disk space requirements for each host machine are as follows:
Host machines in some hardware virtualization applications may require storage space for an operating
system and its components. For example, when running Windows Server 2008 R2 with Hyper-V, you will
need a minimum of 10 GB to meet the requirements for Windows Server 2008. For more details, see
Windows Server 2008 R2 System Requirements. Additional storage space is also required to support the
operating system's paging file, management software, and crash recovery (dump) files.
Some hypervisors maintain files on the host machine that are unique to each guest virtual machine. For
example, in a Hyper-V environment, a temporary memory storage file (BIN file) is created and maintained
for each guest machine. The size of each BIN file is equal to the amount of memory allocated to the guest
machine. In addition, other files may also be created and maintained on the host machine for each guest
machine.
If your host machine is running Windows Server 2012 Hyper-V or Hyper-V 2012, and you are configuring
a host-based failover cluster that will host Exchange Mailbox servers in a database availability group, then
we recommend following the guidance documented in Microsoft Knowledge Base article, 2872325, Guest
Cluster nodes in Hyper-V may not be able to create or join.

Exchange storage requirements

Requirements for storage connected to a virtualized Exchange server are as follows:
Each Exchange guest machine must be allocated sufficient storage space on the host machine for the fixed
disk that contains the guest's operating system, any temporary memory storage files in use, and related
virtual machine files that are hosted on the host machine. In addition, for each Exchange guest machine,
you must also allocate sufficient storage for the message queues and sufficient storage for the databases
and log files on Mailbox servers.
The storage used by the Exchange guest machine for storage of Exchange data (for example, mailbox
databases and transport queues) can be virtual storage of a fixed size (for example, fixed virtual hard disks
(VHD or VHDX) in a Hyper-V environment), dynamic virtual storage when using VHDX files with Hyper-V,
SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that's
configured at the host level and dedicated to one guest machine. All storage used by an Exchange guest
machine for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support
the use of network attached storage (NAS ) volumes, other than in the SMB 3.0 scenario outlined later in
this topic. Also, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't
supported.
Fixed or dynamic virtual disks may be stored on SMB 3.0 files that are backed by block-level storage if the
guest machine is running on Windows Server 2012 Hyper-V (or a later version of Hyper-V ). The only
supported usage of SMB 3.0 file shares is for storage of fixed or dynamic virtual disks. Such file shares
can't be used for direct storage of Exchange data. When using SMB 3.0 file shares to store fixed or dynamic
virtual disks, the storage backing the file share should be configured for high availability to ensure the best
possible availability of the Exchange service.
Storage used by Exchange should be hosted in disk spindles that are separate from the storage that's
hosting the guest virtual machine's operating system.
 Configuring iSCSI storage to use an iSCSI initiator inside an Exchange guest virtual machine is supported.
However, there is reduced performance in this configuration if the network stack inside a virtual machine
isn't full-featured (for example, not all virtual network stacks support jumbo frames).

Exchange memory requirements and recommendations

Some hypervisors have the ability to oversubscribe or dynamically adjust the amount of memory available to a
specific guest machine based on the perceived usage of memory in the guest machine as compared to the needs
of other guest machines managed by the same hypervisor. This technology makes sense for workloads in which
memory is needed for brief periods of time and then can be surrendered for other uses. However, it doesn't make
sense for workloads that are designed to use memory on an ongoing basis. Exchange, like many server
applications with optimizations for performance that involve caching of data in memory, is susceptible to poor
system performance and an unacceptable client experience if it doesn't have full control over the memory
allocated to the physical or virtual machine on which it's running. As a result, using dynamic memory features for
Exchange isn't supported.

Host-based failover clustering and migration for Exchange

The following are answers to some frequently asked questions about host-based failover clustering and migration
technology with Exchange 2013 DAGs:
Does Microsoft support third-party migration technology?
Microsoft can't make support statements for the integration of third party hypervisor products using these
technologies with Exchange, because these technologies aren't part of the Server Virtualization Validation
Program (SVVP ). The SVVP covers the other aspects of Microsoft support for third-party hypervisors. You
need to ensure that your hypervisor vendor supports the combination of their migration and clustering
technology with Exchange. If your hypervisor vendor supports their migration technology with Exchange,
Microsoft supports Exchange with their migration technology.
How does Microsoft define host-based failover clustering?
Host-based failover clustering refers to any technology that provides the automatic ability to react to host-
level failures and start affected virtual machines on alternate servers. Use of this technology is supported
given that, in a failure scenario, the virtual machine is coming up from a cold boot on the alternate host.
This technology helps to make sure that the virtual machine never comes up from a saved state that's
persisted on disk because it will be stale relative to the rest of the DAG members.
What does Microsoft mean by migration support?
Migration technology refers to any technology that allows a planned move of a virtual machine from one
host machine to another host machine. This move could also be an automated move that occurs as part of
resource load balancing, but it isn't related to a failure in the system. Migrations are supported as long as
the virtual machines never come up from a saved state that's persisted on disk. This means that technology
that moves a virtual machine by transporting the state and virtual machine memory over the network with
no perceived downtime is supported for use with Exchange. A third-party hypervisor vendor must provide
support for the migration technology, while Microsoft provides support for Exchange when used in this
configuration.
 Integration with SharePoint and Lync
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 includes many features that integrate with Microsoft SharePoint 2013 and
Microsoft Lync 2013. Together, these products offer a suite of features that make scenarios such as enterprise
eDiscovery and collaboration using site mailboxes possible.

Archiving, hold, and eDiscovery

Archiving of email and documents, preserving them for the duration required to meet regulatory compliance and
business requirements, and ability to search them quickly to fulfill eDiscovery requests is critical in most
organizations. Exchange 2013, SharePoint 2013 and Lync Server 2013 together provide integrated archiving, hold
and eDiscovery functionality, allowing you to preserve important data in-place across Exchange mailboxes,
SharePoint documents and web sites, and archived Lync content. The eDiscovery Center in SharePoint 2013
allows authorized discovery managers to perform an eDiscovery search for content across these stores, preview
search results, and export the data for legal review.

Archive Lync Server 2013 content in Exchange 2013

With Lync Server 2013 deployed in an organization with Exchange 2013, you can configure Lync to archive instant
messaging and on-line meeting content such as shared presentations or documents in the user's Exchange 2013
mailbox. Archiving Lync data in Exchange 2013 allows you to apply retention policies to it. Archived Lync content
also surfaces in any eDiscovery searches. For more details about Lync Archiving and how to deploy it, see the
following topics:
Planning for Archiving
Deploying Archiving

Search Exchange, SharePoint and Lync data using the SharePoint 2013
eDiscovery Center
Exchange 2013 allows SharePoint 2013 to search Exchange mailbox content using Federated search API.
SharePoint 2013 provides an eDiscovery Center to allow authorized personnel to perform eDiscovery. Microsoft
Search Foundation provides a common indexing and search infrastructure to both Exchange 2013 and SharePoint
2013 and allows you to use the same query syntax across both applications. This ensures an eDiscovery search
performed in SharePoint 2013 will return the same Exchange 2013 content as the same search performed using
In-Place eDiscovery in Exchange 2013. SharePoint 2013 eDiscovery Center also allows you to export content
returned in an eDiscovery search, including export of Exchange 2013 content to a PST file.
For more details, see the following topics:
In-Place eDiscovery
In-Place Hold and Litigation Hold
Configure eDiscovery in SharePoint 2013
What's new in eDiscovery in SharePoint Server 2013
Configure Exchange for SharePoint eDiscovery Center
Site mailboxes
In many organizations, information resides in two different stores - email in Microsoft Exchange and documents in
SharePoint, with two different interfaces to access them. This causes a disjointed user experience and impedes
effective collaboration. Site mailboxes allow users to collaborate effectively by bringing together Exchange emails
and SharePoint documents. For users, a site mailbox serves as a central filing cabinet, providing a place to file
project emails and documents that can only be accessed and edited by site members. Site mailboxes are surfaced
in Outlook 2013 and give users easy access to the email and documents for the projects they care about.
Additionally, the same set of content can be accessed directly from the SharePoint site itself.
Under the covers of a site mailbox, the content is kept where it belongs. Exchange stores the email, providing users
with the same message view for email conversations that they use every day for their own mailboxes. SharePoint
stores the documents, bringing document coauthoring and versioning to the table. Exchange synchronizes just
enough metadata from SharePoint to create the document view in Outlook (e.g. document title, last modified date,
last modified author, size).
Site mailboxes are provisioned and managed from SharePoint 2013. For more details, see the following topics:.
Site mailboxes
Configure site mailboxes in SharePoint Server 2013

Unified contact store

Unified contact store (UCS ) is a feature that provides a consistent contact experience across Microsoft Office
products. This feature enables users to store all contact information in their Exchange 2013 mailbox so that the
same contact information is available globally across Lync, Exchange, Outlook and Outlook Web App.
After Lync Server 2013 is installed in an environment with Exchange 2013 and you have configured server-to-
server authentication between the two, users can initiate the migration of existing contacts from Lync Server 2013
to Exchange 2013. For details, see Planning and Deploying Unified Contact Store.

User photos
User photos is a feature that allows you to store high resolution user photos in Exchange 2013 that can be
accessed by client applications, including Outlook, Outlook Web App, SharePoint 2013, Lync 2013, and mobile
email clients. A low -resolution photo is also stored in Active Directory. As with Unified contact stores, user photos
allow your organization to maintain a consistent user profile photo that can be consumed by client applications
without requiring each application to have its own user photos and different ways to add and manage them. Users
can manage their own photos using Outlook Web App, SharePoint 2013 or Lync 2013. For detail about managing
photos on Outlook Web App, see My account.

Lync presence in Outlook Web App

In Exchange 2013 environments with Lync Server 2013 installed, you can configure them to enable users to see
presence information in Outlook Web App. Users can see their instant messaging contacts and groups in the
Navigation Pane of Outlook Web App, respond to or initiate instant messaging sessions from Outlook Web App
and manage their instant messaging contacts and groups.

OAuth authentication
Exchange 2013, SharePoint 2013 and Lync Server 2013 provide the rich cross-product functionality described
above using OAuth authorization protocol for server-to-server authentication. Using the same authentication
protocol allows these applications to seamlessly and securely authenticate to each other. The authentication
mechanism supports authentication as an application using the context of a linked account and user
impersonation where the access request is made in the user context.
OAuth is a standard authorization protocol used by many web sites and web services. It allows clients to access
resources provided by a resource server without having to provide a username and password. Authentication is
performed by an authorization server trusted by the resource owner, which provides the client with an access
token. The token grants access to a specific set of resources for a specified period. For more details about
Exchange 2013's implementation of OAuth, see [MS -XOAUTH]: OAuth 2.0 Authorization Protocol Extensions.
OAuth in on-premises deployments
Within an on-premises deployment, Exchange 2013, SharePoint 2013 and Lync Server 2013 do not require an
authorization server to issue tokens. Each of these applications issue self-signed tokens to access resources
provided by other application. The application that provides access to resources, for example Exchange 2013, must
trust the self-signed tokens presented by the calling application. Trust is established by creating a partner
application configuration for the calling application, which includes the calling application's ApplicationID,
certificate, and AuthMetadataUrl. Exchange 2013, SharePoint 2013 and Lync Server 2013 publish their auth
metadata document in a well-known URL.

Server AuthMetadataUrl

Exchange 2013 https://<serverfqdn>/autodiscover/metadata/json/1

Lync Server 2013 https://<serverfqdn>/metadata/json/1

SharePoint 2013 https://<serverfqdn>/_layouts/15/metadata/json/1

Exchange 2013 Server Auth Certificate

Exchange 2013 Setup creates a self-signed certificate with the friendly name Microsoft Exchange Server Auth
Certificate. The certificate is replicated to all front-end servers in the Exchange 2013 organization. The certificate's
thumbprint is specified in Exchange 2013's authorization configuration, along with its service name, a well-known
GUID that represents on-premises Exchange 2013. Exchange uses the authorization configuration to publish its
auth metadata document.

IMPORTANT
The default Server Auth Certificate created by Exchange 2013 is valid for five years. You must ensure the authorization
configuration includes a current certificate.

When Exchange 2013 receives an access request from a partner application via Exchange Web Services (EWS ), it
parses the www-authenticate header of the https request, which contains the access token signed by the calling
server using its private key. The auth module validates the access token using the partner application
configuration. It then grants access to resources based on the RBAC permissions granted to the application. If the
access token is on behalf of a user, the RBAC permissions granted to the user are checked. For example, if a user
performs an eDiscovery search using the eDiscovery Center in SharePoint 2013, Exchange checks whether the
user is a member of the Discovery Management role group or has the Mailbox Search role assigned and the
mailboxes being searched are within the scope of the RBAC role assignment. For more details, see Permissions.

Managing OAuth Authentication

In Exchange 2013, there are two configuration objects you must manage for OAuth authentication with partner
applications:
AuthConfig: The AuthConfig is created by Exchange 2013 Setup and is used to publish the auth metadata.
You don't need to manage the auth config except to provision a new certificate when the existing certificate
is close to expiration. When this happens, you can renew the existing certificate and configure the new
certificate as the next certificate in the AuthConfig along with its effective date. The new certificate is
automatically replicated to other Exchange 2013 in the organization, the auth metadata document is
refreshed with details of the new certificate, and the AuthConfig rolls over to the new certificate on the
effective date.
Partner applications: To enable partner applications to request access tokens from Exchange 2013, you
must create a partner application configuration. Exchange 2013 provides the
Configure-EnterprisePartnerApplication.ps1 script, which allows you to quickly and easily create partner
application configurations and minimize configuration errors. For details, see Configure OAuth
authentication with SharePoint 2013 and Lync 2013.
 Configure OAuth authentication with SharePoint 2013
and Lync 2013
6/6/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Exchange Server 2013 allows other applications to use OAuth to authenticate to Exchange. The applications must
be configured as partner applications in Exchange 2013.
In Exchange 2013, OAuth configuration with partner applications such as SharePoint 2013 and Lync Server 2013
is supported only by using the Configure-EnterpriseApplication.ps1 script. By automating the task, the script
makes it easier to configure authentication with partner applications and reduces configuration errors. The script
performs the following tasks:
1. Configures an Enterprise partner application that self-issues OAuth tokens to successfully authenticate to
Exchange.
2. Assigns Role Based Access Control (RBAC ) roles to the partner application to authorize it for calling specific
Exchange Web Services APIs.

What do you need to know before you begin?

Estimated time to complete: 5 minutes.
The partner application must publish an auth metadata document for Exchange 2013 to establish a direct
trust to this application and accept authentication requests.
Examples in this topic use the following default location of the \Scripts directory:
C:\Program Files\Microsoft\Exchange Server\V15\Scripts .

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Partner applications - configure" entry in the Sharing and collaboration
permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Configure OAuth authentication with a partner application

This procedure uses the Configure-EntepririseApplication.ps1 script to configure OAuth authentication with
partner applications. Access to resources depends on the permissions assigned to the partner application and/or
the user it impersonates by using RBAC.
After configuring OAuth authentication from Exchange, the partner application can use Exchange 2013 resources.
If Exchange 2013 also needs to access resources offered by the partner application, you must also configure
OAuth authentication in the partner application.
This example configures OAuth authentication for SharePoint 2013.
 Cd C:\Program Files\Microsoft\Exchange Server\V15\Scripts
Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl
https://sharepoint.contoso.com/_layouts/15/metadata/json/1 -ApplicationType SharePoint

This example configures OAuth authentication for Lync Server 2013.

Cd C:\Program Files\Microsoft\Exchange Server\V15\Scripts

Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl https://lync.contoso.com/metadata/json/1 -
ApplicationType Lync

How do you know this worked?

To verify that you have successfully configured an enterprise partner application to authenticate to Exchange 2013
, run the Get-PartnerApplication cmdlet in the Shell to retrieve the configuration. You can also run the Test-
OAuthConnectivity cmdlet to test OAuth connectivity with a partner application for a user.

More information
In hybrid deployments, you can use OAuth authentication between your on-premises Exchange 2013
organization and the Exchange Online organization. For more information, see Using OAuth authentication
to support eDiscovery in an Exchange hybrid deployment.
In on-premises deployments, you can configure server-to-server authentication between Exchange 2013
and SharePoint 2013 so administrators and compliance officers can use the eDiscovery Center in
SharePoint 2013 to search Exchange 2013 mailboxes. For more information, see Configure Exchange for
SharePoint eDiscovery Center.
 Deployment reference
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Exchange 2013: editions and versions
Exchange Server Updates: build numbers and release dates
Exchange Server Supportability Matrix
Exchange 2013 deployment permissions reference
Deployment security checklist
Exchange 2013 sizing and capacity planning
Exchange 2013 storage configuration options
IPv6 support in Exchange 2013
Exchange 2013 language support
Exchange 2013 readiness checks
 What changes in Active Directory when Exchange
2013 is installed?
5/28/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

When you install Exchange 2013, changes are made to your Active Directory forest and domains. Exchange does
this so that it can store information about the Exchange servers, mailboxes, and other objects related to Exchange
in your organization. These changes are made for you when you run the Exchange 2013 Setup wizard or when you
run the PrepareSchema, PrepareAD, and PrepareDomains commands (see how to use these commands in
Prepare Active Directory and domains) during Exchange 2013 command-line Setup. If you're curious about the
changes that Exchange makes to Active Directory, this topic is for you. It explains what Exchange does at each step
of Active Directory preparation.
There are three steps that need to be done to prepare Active Directory for Exchange:
Extend the Active Directory schema
Prepare Active Directory containers, objects, and other items
Prepare Active Directory domains
After all three steps are done, your Active Directory forest is ready for Exchange 2013. You can find out more about
how to install Exchange 2013 by reading Install Exchange 2013 using the Setup wizard.

Extend the Active Directory schema

Extending the Active Directory schema adds and updates classes, attributes, and other items. These changes are
needed so that Exchange can create containers and objects to store information about the Exchange organization.
Because Exchange makes a lot of changes to the Active Directory schema, there's a topic dedicated to this step. To
see all of the changes made to the schema, see Exchange 2013 Active Directory schema changes.
This step is done automatically when you run the Exchange 2013 Setup wizard on the first Exchange 2013 server
in the Active Directory forest. It's also done when you run Exchange 2013 command line Setup with the
PrepareSchema command (or optionally with the PrepareAD command) on the first Exchange 2013 server in the
forest. If you want to find out more information about how to extend the schema, see Extend the Active Directory
schema in Prepare Active Directory and domains.
After Exchange is finished extending the schema, it sets the schema version, which is stored in the ms-Exch-
Schema-Version-Pt attribute. If you want to make sure that the Active Directory schema was extended
successfully, you can check the value stored in this attribute. If the value in the attribute matches the schema
version listed for the release of Exchange 2013 you installed, extending the schema was successful. For a list of
Exchange releases and how to check the value of this attribute, check out the How do you know this worked?
section in Prepare Active Directory and domains.

Prepare Active Directory containers, objects, and other items

With the schema extended, the next step is to add all of the containers, objects, attributes, and other items that
Exchange uses to store information in Active Directory. Most of the changes made in this step are applied to the
entire Active Directory forest. A smaller set of changes are made to the local Active Directory domain where the
PrepareAD command was run during Setup.
These are the changes that are made to the Active Directory forest:
The Microsoft Exchange container is created under CN=Services,CN=Configuration,DC=<root domain> if
it doesn't already exist.
The following containers and objects are created under CN=<organization name>,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<root domain> if they don't already exist:
CN=Address Lists Container
CN=AddressBook Mailbox Policies
CN=Addressing
CN=Administrative Groups
CN=Approval Applications
CN=Auth Configuration
CN=Availability Configuration
CN=Client Access
CN=Connections
CN=ELC Folders Container
CN=ELC Mailbox Policies
CN=ExchangeAssistance
CN=Federation
CN=Federation Trusts
CN=Global Settings
CN=Hybrid Configuration
CN=Mobile Mailbox Policies
CN=Mobile Mailbox Settings
CN=Monitoring Settings
CN=OWA Mailbox Policies
CN=Provisioning Policy Container
CN=Push Notification Settings
CN=RBAC
CN=Recipient Policies
CN=Remote Accounts Policies Container
CN=Retention Policies Container
CN=Retention Policy Tag Container
CN=ServiceEndpoints
CN=System Policies
 CN=Team Mailbox Provisioning Policies
CN=Transport Settings
CN=UM AutoAttendant Container
CN=UM DialPlan Container
CN=UM IPGateway Container
CN=UM Mailbox Policies
CN=Workload Management Settings
The following containers and objects are created under CN=Transport Settings,CN=
<Organization Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain> if
they don't already exist:
CN=Accepted Domains
CN=ControlPoint Config
CN=DNS Customization
CN=Interceptor Rules
CN=Malware Filter
CN=Message Classifications
CN=Message Hygiene
CN=Rules
CN=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e
Permissions are set throughout the configuration partition in Active Directory.
The Rights.ldf file is imported. This file adds permissions that are needed to install Exchange and configure
Active Directory.
The Microsoft Exchange Security Groups organizational unit (OU ) is created in the root domain of the
forest, and permissions are assigned to it.
The following management role groups are created within the Microsoft Exchange Security Groups OU if
they don't already exist:
Compliance Management
Delegated Setup
Discovery Management
Help Desk
Hygiene Management
Organization Management
Public Folder Management
Recipient Management
Records Management
 Server Management
UM Management
View -Only Organization Management
The new management role groups (which appear as universal security groups (USGs) in Active Directory)
that were created in the Microsoft Exchange Security Groups OU are added to the
otherWellKnownObjects attribute stored on the CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<root domain> container.
The Unified Messaging Voice Originator contact is created in the Microsoft Exchange System Objects
container of the root domain.
The domain where the PrepareAD command was run is prepared for Exchange 2013. For information
about what's done to prepare the Active Directory domain for Exchange, check out Preparing Active
Directory domains.
The msExchProductId property on the Exchange organization object is set. If you want to make sure that
the Active Directory schema was extended successfully, you can check the value stored in this property. If
the value in the property matches the schema version listed for the release of Exchange 2013 you installed,
extending the schema was successful. For a list of Exchange releases and how to check the value of this
property, check out the How do you know this worked? section in Prepare Active Directory and domains.

Prepare Active Directory domains

The final step of preparing Active Directory for Exchange is to prepare all of the Active Directory domains where
Exchange servers will be installed or where mailbox-enabled users will be located. This step is done automatically
in the domain where the PrepareAD command was run.
These are the changes that are made to the Active Directory domains:
The Microsoft Exchange System Objects container is created in the root domain partition in Active Directory
if it doesn't already exist.
Permissions are set on the Microsoft Exchange System Objects container for the Exchange Servers,
Organization Management, and Authenticated Users security groups.
The Exchange Install Domain Servers domain global group is created in the current domain and placed in
the Microsoft Exchange System Objects container.
The Exchange Install Domain Servers group is added to the Exchange Servers USG in the root domain.
Permissions are assigned at the domain level for the Exchange Servers USG and the Organization
Management USG.
The objectVersion property in the Microsoft Exchange System Objects container under DC=<root
domain> is set. If you want to make sure that the Active Directory schema was extended successfully, you
can check the value stored in this property. If the value in the property matches the schema version listed
for the release of Exchange 2013 you installed, extending the schema was successful. For a list of Exchange
releases and how to check the value of this property, check out the How do you know this worked? section
in Prepare Active Directory and domains.
 Exchange 2013: editions and versions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 is available in two server editions: Standard Edition and Enterprise Edition.
Enterprise Edition can scale to 50 mounted databases per server in the Release to Manufacturing (RTM ) and
Cumulative Update 1 (CU1) versions, and 100 mounted databases per server in Cumulative Update 2 (CU2) and
later versions; Standard Edition is limited to 5 mounted databases per server. A mounted database is a database
that is in use. A mounted database can be an active mailbox database that is mounted for use by clients, or a
passive mailbox database that is mounted in recovery for log replication and replay. While you can create more
databases than the limits described above, you can only mount the maximum number specified above. The
recovery database does not count towards this limit.
These licensing editions are defined by a product key. When you enter a valid license product key, the supported
edition for the server is established. Product keys can be used for the same edition key swaps and upgrades only;
they can't be used for downgrades. You can use a valid product key to move from the evaluation version (Trial
Edition) of Exchange 2013 to either Standard Edition or Enterprise Edition. You can also use a valid product key to
move from Standard Edition to Enterprise Edition.
You can also license the server again using the same edition product key. For example, if you had two Standard
Edition servers with two keys, but you accidentally used the same key on both servers, you can change the key for
one of them to the other key that you were issued. You can take these actions without having to reinstall or
reconfigure anything. After you enter the product key and restart the Microsoft Exchange Information Store
service, the edition corresponding to that product key will be reflected.
No loss of functionality will occur when the Trial Edition expires, so you can maintain lab, demo, training, and other
non-production environments beyond 120 days without having to reinstall the Trial Edition of Exchange 2013.
As mentioned earlier, you can't use product keys to downgrade from Enterprise Edition to Standard Edition, nor
can you use them to revert to the Trial Edition. These types of downgrades can only be done by uninstalling
Exchange 2013, reinstalling Exchange 2013, and entering the correct product key.

Exchange 2013 versions

For a list of Exchange 2013 versions and information on how to download and upgrade to the latest version of
Exchange 2013, see the following topics:
Exchange Server Updates: build numbers and release dates
Upgrade Exchange 2013 to the latest cumulative update or service pack
To view the build number for the version of Exchange 2013 that you're running, run the following command in the
Exchange Management Shell.

Get-ExchangeServer | fl name,edition,admindisplayversion

Exchange 2013 license types

Exchange 2013 is licensed in the Server/Client Access License (CAL ) model similar to how Exchange 2010 was
licensed. Following are the types of licenses:
 Server licenses: A license must be assigned for each instance of the server software that is being run. The
Server license is sold in two server editions: Standard Edition and Enterprise Edition.
Client Access licenses (CALs): Exchange 2013 also comes in two client access license (CAL ) editions,
which are referred to as a Standard CAL and an Enterprise CAL. You can mix and match the server editions
with the CAL types. For example, you can use Enterprise CALs with Exchange 2013 Standard Edition.
Similarly, you can use Standard CALs with Exchange 2013 Enterprise Edition.
For more information about Exchange license types, see Licensing.
2 minutes to read
 Exchange 2013 deployment permissions reference
5/28/2019 • 37 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic describes the permissions that are required to set up a Microsoft Exchange Server 2013 organization. The
universal security groups (USGs) that are associated with management role groups, and other Windows security groups
and security principals, are added to the access control lists (ACLs) of various Active Directory objects. ACLs control what
operations can be performed on each object. By understanding what permissions are granted to each role group, security
group, or security principal, you can determine what minimum permissions are required to install Exchange 2013.
In some cases, the ACL isn't applied on the usual property, ntSecurityDescriptor, but on another property, such as
msExchMailboxSecurityDescriptor. The directory service can't enforce security that isn't specified in the Windows
security descriptor. In most cases, these ACLs are replicated to store ACLs on appropriate objects by the store service.
Unfortunately, there is no tool to view these ACLs as anything other than raw binary data.
The columns of each permissions table include the following information:
Account: The security principal granted or denied the permissions.
ACE type: Access control entry (ACE ) type
Allow ACE: An allow ACE allows the user or group associated with the ACE to access an item.
Deny ACE: A deny ACE prevents the user or group associated with the ACE from accessing an item.
Inheritance: The type of inheritance used for child objects.
All indicates that the permissions apply to the object and all sub-objects.
Desc indicates the permissions apply to the object class listed in the On Property/Applies To row.
None indicates those permissions only apply the object.
Permissions: The permissions granted to the account.
On Property/Applies To: In some cases, permissions apply only to a given property, property set, or object class.
These limited permissions are specified here.
Comments: When applicable, this column explains why the permissions are required or provides other
information about the permissions.
The permissions are generally listed in the table by the names that are used on the Active Directory Service Interfaces
(ADSI) Edit (AdsiEdit.msc) Security property page in the Advanced view on the View/Edit tab. The ADSI Edit Security
property page lists a much more condensed view of the permissions. The LDP tool (Ldp.exe) displays the access mask
directly as a numeric value. The setup code refers to the permissions by predefined constants.
The following table shows the relationships between these values.

ADSI EDIT ADVANCED VIEW, ACL ENTRIES APPLIED TO A BINARY VALUE (ACCESS MASK IN
ADSI EDIT SUMMARY PAGE VIEW/EDIT TAB GIVEN OBJECT LDP)
 ADSI EDIT ADVANCED VIEW, ACL ENTRIES APPLIED TO A BINARY VALUE (ACCESS MASK IN
ADSI EDIT SUMMARY PAGE VIEW/EDIT TAB GIVEN OBJECT LDP)

Full Control Full Control WRITE_OWNER | WRITE_DAC 0x000F01FF

| READ_CONTROL | DELETE
|
ACTRL_DS_CONTROL_ACCESS
| ACTRL_DS_LIST_OBJECT
| ACTRL_DS_DELETE_TREE
| ACTRL_DS_WRITE_PROP |
ACTRL_DS_READ_PROP |
ACTRL_DS_SELF |
ACTRL_DS_LIST |
ACTRL_DS_DELETE_CHILD |
ACTRL_DS_CREATE_CHILD

Read List Contents + Read All ACTRL_DS_LIST | 0x00020014

Properties + Read ACTRL_DS_READ_PROP |
READ_CONTROL
Permissions

Write Write All Properties + All ACTRL_DS_WRITE_PROP | 0x00000028

Validated Writes ACTRL_DS_SELF

List Contents ACTRL_DS_LIST 0x00000004

Read All Properties ACTRL_DS_READ_PROP 0x00000010

Write All Properties ACTRL_DS_WRITE_PROP 0x00000020

Delete DELETE 0x00010000

Delete Subtree ACTRL_DS_DELETE_TREE 0x00000040

Read Permissions READ_CONTROL 0x00020000

Modify Permissions WRITE_DAC 0x00040000

Modify Owner WRITE_OWNER 0x00080000

All Validated Writes ACTRL_DS_SELF 0x00000008

All Extended Rights ACTRL_DS_CONTROL_ACCESS 0x00000100

Create All Child Objects Create All Child Objects ACTRL_DS_CREATE_CHILD 0x00000001

Delete All Child Objects Delete All Child Objects ACTRL_DS_DELETE_CHILD 0x00000002

ACTRL_DS_LIST_OBJECT 0x00000080
Extended rights are custom rights specified by individual applications. They are specified in the ACL. However, they are
meaningless to Active Directory. The specific application enforces any extended rights. Examples of Exchange extended
rights are "Create public folder" or "Create named properties in the information store."
For information about permissions that are set during a Microsoft Exchange Server 2010 installation, see Exchange 2010
Deployment Permissions Reference.

Prepare Active Directory Permissions

The permissions tables in this section show the permissions set when you execute the Setup /PrepareAD command.

NOTE
The permissions described in this section are the default permissions that are configured when you deploy Exchange 2013 using the
shared permissions model. If you've deployed Exchange 2013 using the Active Directory split permissions model, the default
permission are different. For more information on the changes to the default permissions when using Active Directory split
permissions and the shared and split permissions models in general, see Active Directory split permissions in Understanding split
permissions. If you don't choose to use Active Directory split permissions when you install Exchange, Exchange will use shared
permissions.

Microsoft Exchange Container Permissions

The following table shows the permissions that are set on the Microsoft Exchange container within the configuration
partition.
Distinguished name of the object: CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Installation Allow ACE All Full Control This is the

Account account that is
used to run
/PrepareAD .

Organization Allow ACE All Full Control

Management

Exchange Allow ACE All Full Control

Trusted
Subsystem

Exchange Allow ACE All Read

Servers

Authenticated Allow ACE None Read Property

Users
List Contents

Exchange Allow ACE All Modify msExchSmtpRc

Trusted Permissions eiveConnector
Subsystem
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Public Folder Allow ACE All Read

Management
List Object

Delegated Allow ACE All Read

Setup
List Object

Microsoft Exchange Autodiscover Container Permissions

The following table shows the permissions set on the Microsoft Exchange Autodiscover container within the
configuration partition.
Distinguished name of the object: CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=
<domain>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Exchange Servers Allow ACE All Read

Microsoft Exchange Organization Container Permissions

The permissions tables in this section show the permissions set on the Microsoft Exchange Organization and sub-
containers within the configuration partition.
Distinguished name of the object: CN=<organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=
<domain>
ON PROPERTY/
ACCOUNT(S) ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Enterprise Deny ACE All Send As Windows

Admins administrators
Receive As aren't allowed
Root Domain to open
Admins mailboxes.
Installation
Account
Organization
Management

Enterprise Deny ACE All Exchange Web Extended right

Admins Services
Impersonation
Schema
Admins Exchange Web
Services Token
Root Domain Serialization
Admins
Installation
Account
Organization
Management
 ON PROPERTY/
ACCOUNT(S) ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Enterprise Deny ACE All Store

Admins Transport
Access
Schema
Admins Store
Constrained
Root Domain Delegation
Admins
Store Read
Installation Access
Account
Store Read
Write Access

Local System Allow All All Extended

Rights

Authenticated Deny ACE Desc Read Property msExchAvailabilityUserPassword

Users /
msExchAvailabilityAddressSpace

Authenticated Allow None Read

Users

Organization Allow ACE All Read

Management Permissions
List Contents
Read Property
List Object

Public Folder Allow ACE All Read

Management Permissions
List Contents
Read Property
List Object

NT Allow ACE All Read

Authority\Net
work Service

Managed Allow ACE All Read

Availability Permissions
Servers
List Contents
Read Property
List Object

Exchange Allow ACE All All Extended

Servers Rights
 ON PROPERTY/
ACCOUNT(S) ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property groupType

Servers

Exchange Allow ACE All Write Property msExchOwningServer

Servers

Exchange Allow ACE All Write Property msExchMailboxSecurityDescriptor

Servers

Exchange Allow ACE All Write Property msExchUMServerWritableFlags

Servers

Exchange Allow ACE All Write Property msExchDatabaseCreated

Servers

Exchange Allow ACE All Write Property msExchUserCulture

Servers

Exchange Allow ACE All Write Property msExchMobileMailboxFlags

Servers

Exchange Allow ACE All Write Property siteFolderGUID

Servers

Exchange Allow ACE All Write Property siteFolderServer

Servers

Exchange Allow ACE All Write Property msExchEDBOffline

Servers

Exchange Allow ACE All Write Property userCertificate

Servers

Exchange Allow ACE All Write Property msExchUMDtmfMap

Servers

Exchange Allow ACE All Write Property msExchBlockedSendersHash

Servers

Exchange Allow ACE All Write Property Personal

Servers Information

Exchange Allow ACE All Write Property Public

Servers Information
 ON PROPERTY/
ACCOUNT(S) ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property Exchange

Servers Information

Exchange Allow ACE All Write Property msExchPatchMDB

Servers

Exchange Allow ACE All Write Property publicDelegates

Servers

Exchange Allow ACE All Write Property msExchUMSpokenName

Servers

Exchange Allow ACE All Write Property msExchUMPinChecksum

Servers

Exchange Allow ACE All Write Property legacyExchangeDN

Servers

Exchange Allow ACE All Write Property msExchSafeSendersHash

Servers

Exchange Allow ACE All Write Property thumbnailPhoto

Servers

Organization Allow ACE All Create top

Management level public
folder

Public Folder Allow ACE All Create top

Management level public
folder

Organization Allow ACE All View

Management information
store status

Public Folder Allow ACE All View

Management information
store status

Organization Allow ACE All Administer

Management information
store

Public Folder Allow ACE All Administer

Management information
store
 ON PROPERTY/
ACCOUNT(S) ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Organization Allow ACE All Create named

Management properties in
the
information
store

Public Folder Allow ACE All Create named

Management properties in
the
information
store

Organization Allow ACE All Modify public

Management folder ACL

Public Folder Allow ACE All Modify public

Management folder ACL

Organization Allow ACE All Modify public

Management folder quotas

Public Folder Allow ACE All Modify public

Management folder quotas

Organization Allow ACE All Modify public

Management folder admin
ACL

Public Folder Allow ACE All Modify public

Management folder admin
ACL

Organization Allow ACE All Modify public

Management folder expiry

Public Folder Allow ACE All Modify public

Management folder expiry

Organization Allow ACE All Modify public

Management folder replica
list

Public Folder Allow ACE All Modify public

Management folder replica
list
 ON PROPERTY/
ACCOUNT(S) ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Organization Allow ACE All Modify public

Management folder deleted
item retention

Public Folder Allow ACE All Modify public

Management folder deleted
item retention

Organization Allow ACE All Create public

Management folder

Public Folder Allow ACE All Create public

Management folder

Public Folder Allow ACE All Mail Enable

Management Public Folder

Everyone Allow ACE All Create named

properties in
NT the
Authority\Ano information
nymous Logon store

Everyone Allow ACE All Create public

folder
NT
Authority\Ano
nymous Logon

Everyone Allow ACE Desc Read /

Permissions msExchPrivateMDB
NT
Authority\Ano List Contents
nymous Logon
Read Property
List Object

Everyone Allow ACE Desc Read /

Permissions msExchPublicMDB
NT
Authority\Ano List Contents
nymous Logon
Read Property
List Object

Exchange Allow ACE Desc Read /

Servers Permissions siteAddressing

List Contents
Read Property
List Object
Distinguished name of the object: CN=All Address Lists,CN=Address Lists Container,CN=<organization>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE All List Contents

Users

Organization Allow ACE All Write Property msExchLastAppliedRecipientFilter

Management
msExchRecipientFilterFlags

Public Folder Allow ACE All Write Property msExchLastAppliedRecipientFilter

Management
msExchRecipientFilterFlags

Distinguished name of the object: CN=Offline Address Lists,CN=Address Lists Container, CN=<organization>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE All Download Offline

Users Address Book

Distinguished name of the object: CN=Addressing,CN=<organization>

ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE All Read

users

Distinguished name of the object: CN=Recipient Policies,CN=<organization>

ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Write Property msExchLastAppliedRecipientFilter

Management
msExchRecipientFilterFlags

Public Folder Allow ACE All Write Property msExchLastAppliedRecipientFilter

Management
msExchRecipientFilterFlags

Configuration Partition Container Permissions

The permissions tables in this section show the permissions set by the Setup /PrepareAD command on various containers
within the configuration partition.
Distinguished name of the object: CN=Sites,CN=Configuration,DC=<domain>
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Write Property msExchVersion /

Management site

Exchange Trusted
Subsystem

Organization Allow ACE All Write Property msExchVersion /

Management site-link

Exchange Trusted
Subsystem

Organization Allow ACE All Write Property msExchPartnerId

Management / site

Exchange Trusted
Subsystem

Organization Allow ACE All Write Property msExchMinorPartnerId

Management / site

Exchange Trusted
Subsystem

Organization Allow ACE All Write Property msExchResponsibleforSites

Management / site

Exchange Trusted
Subsystem

Organization Allow ACE Write Property msExchTransportSiteFlags

Management / site

Exchange Trusted
Subsystem

Organization Allow ACE All Write Property msExchCost /

Management site-link

Exchange Trusted
Subsystem

Organization Allow ACE Desc Read Permissions /

Management msExchEdgeSyncEHFConnector
List Contents
Exchange Trusted
Subsystem Read Property

Local System List Object

Exchange Servers
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE Desc Read Permissions /

Management msExchEdgeSyncMservConnector
List Contents
Exchange Trusted
Subsystem Read Property

Local System List Object

Exchange Servers

Organization Allow ACE Children Create Child msExchEdgeSyncServiceConfig

Management / site
Delete Child
Exchange Trusted
Subsystem Delete Tree

Organization Allow ACE Desc Read Permissions /

Management msExchEdgeSyncServiceConfig
List Contents
Exchange Trusted
Subsystem Read Property

Local System List Object

Exchange Servers

Organization Allow ACE Children Create Child msExchEdgeSyncMservConnector

Management /
Delete Child msExchEdgeSyncServiceConfig
Exchange Trusted
Subsystem Delete Tree

Organization Allow ACE Children Create Child msExchEdgeSyncEHFConnector

Management /
Delete Child msExchEdgeSyncServiceConfig
Exchange Trusted
Subsystem Delete Tree

Distinguished name of the object: CN=Deleted Objects,CN=Configuration,DC=<domain>

ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All List Contents

Servers

Organization Allow ACE All Read

Administration
List Object
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Installation Allow ACE All Read This is the

Account Permission account that is
used to run
Write /PrepareAD .
Permission
List Contents
Read Property
List Object

Exchange Allow ACE All Read

Trusted
Subsystem List Object

Network Allow ACE All List Contents

Service

Exchange Administrative Group Permissions

The Setup /PrepareAD command also configures the following permissions on the administrative groups within the
organization.
Distinguished name of the object: CN=<admin group>,CN=Administrative Groups,CN=<organization>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Organization Allow ACE Desc Access msExchExchangeServerAllows

Management Recipient Exchange
Update Service Recipient
Administrators
to stamp
recipients with
proxy address
information.

Local System Allow ACE Desc Access msExchExchangeServerAllows the

Recipient servers to
Update Service stamp
recipients with
proxy address
information.

Public Folder Allow ACE Desc Access msExchExchangeServerAllows

Management Recipient Exchange
Update Service Public Folder
Administrators
to stamp
recipients with
proxy address
information.

Distinguished name of the object: CN=Advanced Security Settings,CN=<admin group>,CN=Administrative

Groups,CN=<organization>
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE None List Contents

Users

Distinguished name of the object: CN=Encryption,CN=Advanced Security Settings,CN=<admin

group>,CN=Administrative Groups,CN=<organization>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE None Read Property

Users

Distinguished name of the object: CN=Arrays,CN=<admin group>,CN=Administrative Groups,CN=<organization>

ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE None List Contents

Users

Distinguished name of the object: CN=Database Availability Groups,CN=<admin group>,CN=Administrative

Groups,CN=<organization>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE None List Contents

Users

Distinguished name of the object: CN=Databases,CN=<admin group>,CN=Administrative Groups,CN=

<organization>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE None List Contents

Users

Distinguished name of the object: CN=Servers,CN=<admin group>,CN=Administrative Groups,CN=<organization>

ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Deny ACE All Receive As Exchange

Servers Servers aren't
allowed to
open
mailboxes.

Authenticated Allow ACE None List Contents

Users
Microsoft Exchange Security Groups Container Permissions
The permissions tables in this section show the permissions set on the Microsoft Exchange Security Groups container
within the root domain partition.
Distinguished name of the object: OU=Microsoft Exchange Security Groups,DC=<root domain>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Full Control

Management

Exchange Trusted Allow ACE All Create Child / Group

Subsystem

Exchange Trusted Allow ACE Desc Delete / group

Subsystem

Exchange Trusted Allow ACE Desc Write Property Member / group

Subsystem

Distinguished name of the object: CN=Organization Management,OU=Microsoft Exchange Security Groups,DC=

<root domain>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Full Control

Management

Distinguished name of the object: CN=Public Folder Management,OU=Microsoft Exchange Security Groups,DC=
<root domain>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Full Control

Management

Distinguished name of the object: CN=ExchangeLegacyInterop,OU=Microsoft Exchange Security Groups,DC=<root

domain>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Full Control

Management

Distinguished name of the object: CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=<root

domain>
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Full Control

Management

Root Domain Allow ACE All Read Members

Administrators
Write Members

Child Domain Allow ACE All Read Members

Administrators
Write Members

Prepare Domain
The following tables show the permissions set when you execute the Setup /PrepareDomain command.

NOTE
The permissions described in this section are the default permissions that are configured when you deploy Exchange 2013 using the
shared permissions model. If you've deployed Exchange 2013 using the Active Directory split permissions model, the default
permission are different. For more information on the changes to the default permissions when using Active Directory split
permissions and the shared and split permissions models in general, see Active Directory split permissions in Understanding split
permissions. If you don't choose to use Active Directory split permissions when you install Exchange, Exchange will use shared
permissions.

Distinguished name of the object: DC=<domain>

ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Authenticated Allow ACE All Read Property Exchange

Users Information

NT Allow ACE All Read Property Exchange Grants

AUTHORITY\N Personal Transport
Information
ETWORK service read
permissions.

Exchange Allow ACE All Write Property groupType

Servers

Exchange Allow ACE All Write Property msExchMailboxSecurityDescriptor

Servers

Exchange Allow ACE All Write Property msExchUMServerWritableFlags

Servers
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Read Property Exchange

Servers Personal
Information

Exchange Allow ACE All Read Property Exchange

Servers Information

Exchange Allow ACE All Write Property msExchUserCultulre

Servers

Exchange Allow ACE All Read Property memberOf

Servers

Exchange Allow ACE All Read Property garbageCollPeriod

Servers

Exchange Allow ACE All Read Property userAccountControl

Servers

Exchange Allow ACE All Read Property canonicalName

Servers

Exchange Allow ACE All Replication Extended right

Servers Synchronizatio
n

Exchange Allow ACE All Create Child msExchActiveSyncDevices

Servers / User
Delete Chile
List Children

Exchange Allow ACE All Create Child msExchActiveSyncDevices

Servers / inetOrgPerson
Delete Child
List Children

Exchange Allow ACE All Write Property msExchSafeSendersHash

Servers

Exchange Allow ACE All Write Property msExchPublicDelegates

Servers

Exchange Allow ACE All Write Property msExchMobileMailboxFlags

Servers
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property msExchSafeRecipientsHash

Servers

Exchange Allow ACE All Write Property userCertificate

Servers

Exchange Allow ACE All Write Property msExchUMDtmfMap

Servers

Exchange Allow ACE All Write Property msExchBlockedSendersHash

Servers

Exchange Allow ACE All Write Property msExchUMSpokenName

Servers

Exchange Allow ACE All Write Property msExchUMPinChecksum

Servers

Exchange Allow ACE All Write Property thumbnailPhoto

Servers

Organization Allow ACE All Read

Management
List Object

Organization Allow ACE All Write Property Exchange

Management Information

Organization Allow ACE All Write Property garbageCollPeriod

Management

Organization Allow ACE All Write Property legacyExchangeDN

Management

Organization Allow ACE All Write Property msExchPublicDelegates

Management

Organization Allow ACE All Write Property textEncodedORAddress

Management

Organization Allow ACE All Write Property proxyAddresses

Management

Organization Allow ACE All Write Property mail

Management
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Organization Allow ACE All Write Property displayNamePrintable

Management

Organization Allow ACE All Write Property showInAddressBook

Management

Organization Allow ACE All Write Property Exchange

Management Personal
Information

Organization Allow ACE All Full Control /

Management msExchDynamicDistributionList

Organization Allow ACE All Write Property adminDisplayName

Management

Organization Allow ACE All Write Property displayName

Management

Exchange Allow ACE All Read

Trusted
Subsystem List Object

Exchange Allow ACE All Write Property displayName

Trusted
Subsystem

Exchange Allow ACE All Write Property Public

Trusted Information
Subsystem

Exchange Allow ACE All Write Property msExchPublicDelegates

Trusted
Subsystem

Exchange Allow ACE All Write Property adminDisplayName

Trusted
Subsystem

Exchange Allow ACE All Full Control /

Trusted msExchDynamicDistributionList
Subsystem

Exchange Allow ACE All Write Property Exchange

Trusted Information
Subsystem
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property Exchange

Trusted Personal
Information
Subsystem

Exchange Allow ACE All Write Property garbageCollPeriod

Trusted
Subsystem

Exchange Allow ACE All Write Property textEncodedORAddress

Trusted
Subsystem

Exchange Allow ACE All Write Property showInAddressBook

Trusted
Subsystem

Exchange Allow ACE All Write Property legacyExchangeDN

Trusted
Subsystem

Exchange Allow ACE All Write Property Personal

Trusted Information
Subsystem

Exchange Allow ACE All Write Property proxyAddresses

Trusted
Subsystem

Exchange Allow ACE All Write Property displayNamePrintable

Trusted
Subsystem

Exchange Allow ACE All Write Property mail

Trusted
Subsystem

Exchange Allow ACE All Write Property pwdLastSet

Windows
Permissions

Exchange Allow ACE All WriteDACL / user

Windows
Permissions

Exchange Allow ACE All WriteDACL /

Windows inetOrgPerson
Permissions
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Delete Tree / user

Windows
Permissions

Exchange Allow ACE All Delete Tree /

Windows inetOrgPerson
Permissions

Exchange Allow ACE All Write Property sAMAccountName

Windows
Permissions

Exchange Allow ACE All Create Child / contact

Windows
Permissions Delete

Exchange Allow ACE All Create Child /

Windows inetOrgPerson
Permissions Delete

Exchange Allow ACE All Create Child / user

Windows
Permissions Delete

Exchange Allow ACE All Create Child /

Windows organizationUnit
Permissions Delete

Exchange Allow ACE All Create Child / group

Windows
Permissions Delete

Exchange Allow ACE All Create Child / computer

Windows
Permissions Delete Child

Exchange Allow ACE All Write Property Member

Windows
Permissions

Exchange Allow ACE All Write Property wwwHomePage

Windows
Permissions

Exchange Allow ACE All Write Property countryCode

Windows
Permissions
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property userAccountControl

Windows
Permissions

Exchange Allow ACE All Write Property managedBy

Windows
Permissions

Exchange Allow ACE All Reset Extended right

Windows Password on
Permissions Next Logon

Exchange Allow ACE All Change / user Extended right

Windows Password
Permissions

Delegated Allow ACE All Read Property User Account

Setup Restrictions

Distinguished name of the object: CN=AdminSDHolder,CN=System,DC=<domain>

ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Authenticated Allow ACE All Read Property Exchange

Users Information

NT Allow ACE All Read Property Exchange Grants

AUTHORITY\N Personal Transport
Information
ETWORK service read
permissions.

Exchange Allow ACE All Write Property groupType

Servers

Exchange Allow ACE All Write Property msExchMailboxSecurityDescriptor

Servers

Exchange Allow ACE All Write Property msExchUMServerWritableFlags

Servers

Exchange Allow ACE All Read Property Exchange

Servers Personal
Information

Exchange Allow ACE All Read Property Exchange

Servers Information
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property msExchUserCultulre

Servers

Exchange Allow ACE All Read Property memberOf

Servers

Exchange Allow ACE All Read Property garbageCollPeriod

Servers

Exchange Allow ACE All Read Property userAccountControl

Servers

Exchange Allow ACE All Read Property canonicalName

Servers

Exchange Allow ACE All Replication Extended right

Servers Synchronizatio
n

Exchange Allow ACE All Create Child msExchActiveSyncDevices

Servers / User
Delete Chile
List Children

Exchange Allow ACE All Create Child msExchActiveSyncDevices

Servers / inetOrgPerson
Delete Child
List Children

Exchange Allow ACE All Write Property msExchSafeSendersHash

Servers

Exchange Allow ACE All Write Property msExchPublicDelegates

Servers

Exchange Allow ACE All Write Property msExchMobileMailboxFlags

Servers

Exchange Allow ACE All Write Property msExchSafeRecipientsHash

Servers

Exchange Allow ACE All Write Property userCertificate

Servers

Exchange Allow ACE All Write Property msExchUMDtmfMap

Servers
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property msExchBlockedSendersHash

Servers

Exchange Allow ACE All Write Property msExchUMSpokenName

Servers

Exchange Allow ACE All Write Property msExchUMPinChecksum

Servers

Exchange Allow ACE All Write Property thumbnailPhoto

Servers

Organization Allow ACE All Read

Management
List Object

Organization Allow ACE All Write Property Exchange

Management Information

Organization Allow ACE All Write Property garbageCollPeriod

Management

Organization Allow ACE All Write Property legacyExchangeDN

Management

Organization Allow ACE All Write Property msExchPublicDelegates

Management

Organization Allow ACE All Write Property textEncodedORAddress

Management

Organization Allow ACE All Write Property proxyAddresses

Management

Organization Allow ACE All Write Property mail

Management

Organization Allow ACE All Write Property displayNamePrintable

Management

Organization Allow ACE All Write Property showInAddressBook

Management

Organization Allow ACE All Write Property Exchange

Management Personal
Information
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Organization Allow ACE All Full Control /

Management msExchDynamicDistributionList

Organization Allow ACE All Write Property adminDisplayName

Management

Organization Allow ACE All Write Property displayName

Management

Exchange Allow ACE All Read

Trusted
Subsystem List Object

Exchange Allow ACE All Write Property displayName

Trusted
Subsystem

Exchange Allow ACE All Write Property Public

Trusted Information
Subsystem

Exchange Allow ACE All Write Property msExchPublicDelegates

Trusted
Subsystem

Exchange Allow ACE All Write Property adminDisplayName

Trusted
Subsystem

Exchange Allow ACE All Full Control /

Trusted msExchDynamicDistributionList
Subsystem

Exchange Allow ACE All Write Property Exchange

Trusted Information
Subsystem

Exchange Allow ACE All Write Property Exchange

Trusted Personal
Information
Subsystem

Exchange Allow ACE All Write Property garbageCollPeriod

Trusted
Subsystem

Exchange Allow ACE All Write Property textEncodedORAddress

Trusted
Subsystem
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property showInAddressBook

Trusted
Subsystem

Exchange Allow ACE All Write Property legacyExchangeDN

Trusted
Subsystem

Exchange Allow ACE All Write Property Personal

Trusted Information
Subsystem

Exchange Allow ACE All Write Property proxyAddresses

Trusted
Subsystem

Exchange Allow ACE All Write Property displayNamePrintable

Trusted
Subsystem

Exchange Allow ACE All Write Property mail

Trusted
Subsystem

Exchange Allow ACE All Write Property pwdLastSet

Windows
Permissions

Exchange Allow ACE All Write Property sAMAccountName

Windows
Permissions

Exchange Allow ACE All Write Property Member

Windows
Permissions

Exchange Allow ACE All Write Property wwwHomePage

Windows
Permissions

Exchange Allow ACE All Write Property countryCode

Windows
Permissions

Exchange Allow ACE All Write Property userAccountControl

Windows
Permissions
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property managedBy

Windows
Permissions

Delegated Allow ACE All Read Property User Account

Setup Restrictions

Distinguished name of the object: CN=Deleted Objects,DC=<domain>

ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Exchange Servers Allow ACE All List Contents

Distinguished name of the object: CN=Microsoft Exchange System Objects,DC=<domain>

ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

NT Allow ACE All Read Property

AUTHORITY\NETW
ORK List Contents
Read Permissions

Authenticated Allow ACE All Read Permissions

Users

Authenticated Allow ACE All Read Property garbageCollPeriod

Users

Authenticated Allow ACE All Read Property adminDisplayName

Users

Authenticated Allow ACE All Read Property modifyTimeStamp

Users

Exchange Servers Deny ACE All Delete Tree

Exchange Servers Allow ACE All Read Permissions

List Contents
Read
PropertyDelete
Tree

Exchange Servers Allow ACE All Create Child /

msExchSystemMailbox
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Exchange Servers Allow ACE All Create Child / publicFolder

Delete Child

Exchange Servers Allow ACE All Create Child / user

Exchange Servers Allow ACE All Delete Child /

msExchSystemMailbox

Exchange Servers Allow ACE All Delete Child / user

Exchange Servers Allow ACE Desc Write Property / publicFolder

Exchange Servers Allow ACE Desc Write Property /

msExchSystemMailbox

Exchange Servers Allow ACE Desc Write Property / user

Exchange Servers Allow ACE Desc Change Password / user

Reset Password on
Next Logon

Organization Allow ACE All Read Permissions

Management
List Contents
Read Property

Organization Allow ACE Desc Write Property /

Management msExchSystemMailbox

Organization Allow ACE All Create Child /

Management msExchSystemMailbox
Delete Child

Organization Allow ACE Desc Write Property / user

Management

Organization Allow ACE All Create Child / user

Management
Delete Child

Organization Allow ACE Desc Read Property mail /

Management publicFolder
Write Property
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE Desc Read Property displayNamePrintable

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property displayName /

Management publicFolder
Write Property

Organization Allow ACE Desc Read Property textEncodedORAddress

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property proxyAddresses

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property cn /

Management publicFolder
Write Property

Organization Allow ACE Desc Read Property showInAddressBook

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property Exchange

Management Information /
Write Property publicFolder

Organization Allow ACE Desc Read Property legacyExchangeDN

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property Exchange

Management Personal
Write Property Information /
publicFolder

Organization Allow ACE Desc Read Property msDSPhoneticDisplayName

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property msExchPFContacts

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property garbageCollPeriod

Management / publicFolder
Write Property

Organization Allow ACE Desc Read Property name /

Management publicFolder
Write Property
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE Desc Read Property msExchPublicDelegates

Management / publicFolder
Write Property

Public Folder Allow ACE All Read Permissions

Management
List Contents
Read Property

Public Folder Allow ACE Desc Read Property mail /

Management publicFolder
Write Property

Public Folder Allow ACE Desc Read Property displayNamePrintable

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property displayName /

Management publicFolder
Write Property

Public Folder Allow ACE Desc Read Property textEncodedORAddress

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property proxyAddresses

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property cn /

Management publicFolder
Write Property

Public Folder Allow ACE Desc Read Property showInAddressBook

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property Exchange

Management Information /
Write Property publicFolder

Public Folder Allow ACE Desc Read Property legacyExchangeDN

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property Exchange

Management Personal
Write Property Information /
publicFolder

Public Folder Allow ACE Desc Read Property msDSPhoneticDisplayName

Management / publicFolder
Write Property
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Public Folder Allow ACE Desc Read Property msExchPFContacts

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property garbageCollPeriod

Management / publicFolder
Write Property

Public Folder Allow ACE Desc Read Property name /

Management publicFolder
Write Property

Public Folder Allow ACE Desc Read Property msExchPublicDelegates

Management / publicFolder
Write Property

Exchange Trusted Allow ACE All Read Permissions

Subsystem
List Contents
Read Property

Exchange Trusted Allow ACE Desc Read Property mail /

Subsystem publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property displayNamePrintable

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property displayName /

Subsystem publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property textEncodedORAddress

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property proxyAddresses

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property cn /

Subsystem publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property showInAddressBook

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property Exchange

Subsystem Information /
Write Property publicFolder
 ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Exchange Trusted Allow ACE Desc Read Property legacyExchangeDN

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property Exchange

Subsystem Personal
Write Property Information /
publicFolder

Exchange Trusted Allow ACE Desc Read Property msDSPhoneticDisplayName

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property msExchPFContacts

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property garbageCollPeriod

Subsystem / publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property name /

Subsystem publicFolder
Write Property

Exchange Trusted Allow ACE Desc Read Property msExchPublicDelegates

Subsystem / publicFolder
Write Property

Distinguished name of the object: CN=Exchange Install Domain Servers,CN=Microsoft Exchange System
Objects,DC=<domain>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Organization Allow ACE All Full Control

Management

Server Role Installation

During installation of the Client Access and Mailbox server roles, Setup adds the Organization Management USG to the
administrator security group on the local computer so that members of the management role group named Organization
Management can manage the server.
The following permissions table shows the permissions set when you install the Client Access or Mailbox server roles.
Distinguished name of the object: CN=<server>,CN=Servers,CN=<admin group>,CN=Administrative Groups,CN=
<organization>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

MACHINE$ Allow ACE All Read

Permissions
List Contents
Read Property
List Object

MACHINE$ Allow ACE None Write Property msExchServerSite

msExchEdgeSyncCredential

Exchange Allow ACE All Store Extended

Servers Transport rights
Access
Store
Constrained
Delegation
Store Read
Only Access
Store Read
and Write
Access

NT Allow ACE All Exchange Web Extended right

AUTHORITY\N Services Token
ETWORK Serialization Only granted
on Mailbox
server role
objects.

NT Allow ACE All Read

AUTHORITY\N Permissions
ETWORK
List Contents
Read Property
List Object

Local System Allow ACE All Read

Permissions
List Contents
Read Property
List Object

Delegated Allow ACE All Full Control

Setup

Delegated Deny ACE All Create Child /

Setup msExchPublicMDB
Delete Child
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Authenticated Allow ACE All Read Property

Users

Delegated Deny ACE All Receive As Extended right

Setup
Send As

Database Availability Groups

The permissions tables in this section show the permissions set with regards to the database availability groups and its
members.
Distinguished name of the object: CN=<DAGName>,CN=Database Availability Groups,CN=<admin
group>,CN=Administrative Groups,CN=<organization>
ON PROPERTY/ APPLIES
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS TO

Authenticated Allow ACE None Read Property

Users

Edge Transport
If you install an Edge Transport server and establish an Edge Subscription with the Exchange organization, the
permissions in the following permissions table are set when the Edge Transport server is instantiated into the
organization.
Distinguished name of the object: CN=<server>,CN=Servers,CN=<admin group>,CN=Administrative Groups,CN=
<organization>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Write Property

Servers

Authenticated Allow ACE None Read ACE is defined

Users Properties in schema for
msExchExchangeServer
class objects
defaultSecurityDescriptor
.

Mailbox Server Installation

During installation of the first Mailbox server, the following containers are created, if they do not already exist. The
following permissions table shows the permissions that are applied.
Distinguished name of the object: CN=Availability Configuration,CN=<organization>
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE Desc Read Property Extended right

msExchAvailabilityUserPassword /
Servers msExchAvailabilityAddressSpaceObjects

Distinguished name of the object: CN=Default <Server>,CN=SMTP Receive Connectors,CN=Protocols,CN=

<Server>,CN=Servers,CN=<admin group>,CN=<organization>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

ExchangeLegac Deny ACE All Accept Forest

yInterop Headers

ExchangeLegac Deny ACE All Accept

yInterop Organization
Headers

Exchange Allow ACE All Accept Any

Servers Sender

ExchangeLegac Allow ACE All Accept Any

yInterop Sender

S-1-9- Allow ACE All Accept Any This is the

1419165041- Sender well-known
1139599005- security
3936102811- identifier (SID)
1022490595- for Mailbox
21 servers.

S-1-9- Allow ACE All Accept Any This is the

1419165041- Sender well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept Any This is the

1419165041- Sender well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers EXCH50

ExchangeLegac Allow ACE All Accept

yInterop EXCH50
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept This is the

1419165041- EXCH50 well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- EXCH50 well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- EXCH50 well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Submit

Servers Messages to
any Recipient

ExchangeLegac Allow ACE All Submit

yInterop Messages to
any Recipient

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- any Recipient SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- any Recipient SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- any Recipient SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers XShadow
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept This is the

1419165041- XShadow well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept

Servers Routing
Headers

ExchangeLegac Allow ACE All Accept

yInterop Routing
Headers

S-1-9- Allow ACE All Accept This is the

1419165041- Routing well-known
1139599005- Headers SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Routing well-known
1139599005- Headers SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- Routing well-known
1139599005- Headers SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers XSessionPara
ms

S-1-9- Allow ACE All Accept This is the

1419165041- XSessionPara well-known
1139599005- ms SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- XSessionPara well-known
1139599005- ms SID for
3936102811- Mailbox
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Accept Forest

Servers Headers

S-1-9- Allow ACE All Accept Forest This is the

1419165041- Headers well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Forest This is the

1419165041- Headers well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept xAttr

Servers

S-1-9- Allow ACE All Accept xAttr This is the

1419165041- well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept xAttr This is the

1419165041- well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept

Servers XProxyFrom

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XProxyFrom well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XProxyFrom well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Accept

Servers XSysProbe

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XSysProbe well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XSysProbe well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Send

Servers XMessageCon
text Extended
Properties

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Extended SID for
3936102811- Properties Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Extended SID for Edge
3936102811- Properties Transport
1022490595- servers.
22

Exchange Allow ACE All Send

Servers XMessageCon
text Fast Index

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Fast Index SID for
3936102811- Mailbox
1022490595- servers.
21
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Fast Index SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Send

Servers XMessageCon
text AD
Recipient
Cache

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text AD SID for
3936102811- Recipient Mailbox
1022490595- Cache servers.
21

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text AD SID for Edge
3936102811- Recipient Transport
1022490595- Cache servers.
22

Exchange Allow ACE All Accept

Servers Authentication
Flag

ExchangeLegac Allow ACE All Accept

yInterop Authentication
Flag

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Bypass Anti-

Servers Spam

ExchangeLegac Allow ACE All Bypass Anti-

yInterop Spam

S-1-9- Allow ACE All Bypass Anti- This is the

1419165041- Spam well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Bypass Anti- This is the

1419165041- Spam well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Bypass Anti- This is the

1419165041- Spam well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Bypass

Servers Message Size
Limit

ExchangeLegac Allow ACE All Bypass

yInterop Message Size
Limit

S-1-9- Allow ACE All Bypass This is the

1419165041- Message Size well-known
1139599005- Limit SID for
3936102811- Mailbox
1022490595- servers.
21
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Bypass This is the

1419165041- Message Size well-known
1139599005- Limit SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Bypass This is the

1419165041- Message Size well-known
1139599005- Limit SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers Organization
Headers

S-1-9- Allow ACE All Accept This is the

1419165041- Organization well-known
1139599005- Headers SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Organization well-known
1139599005- Headers SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Submit

Servers Messages to
Server

ExchangeLegac Allow ACE All Submit

yInterop Messages to
Server

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- Server SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- Server SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- Server SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers Authoritative
Domain
Sender

ExchangeLegac Allow ACE All Accept

yInterop Authoritative
Domain
Sender

S-1-9- Allow ACE All Accept This is the

1419165041- Authoritative well-known
1139599005- Domain SID for
3936102811- Sender Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Authoritative well-known
1139599005- Domain SID for Edge
3936102811- Sender Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- Authoritative well-known
1139599005- Domain SID for
3936102811- Sender externally
1022490595- secured
23 servers.

Authenticated Allow ACE All Submit

Users Messages to
any Recipient

Authenticated Allow ACE All Accept

Users Routing
Headers

Authenticated Allow ACE All Bypass Anti-

Users Spam

Authenticated Allow ACE All Submit

Users Messages to
Server
Distinguished name of the object: CN=Client <Server>,CN=SMTP Receive Connectors,CN=Protocols,CN=
<Server>,CN=Servers,CN=<admin group>,CN=<organization>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Authenticated Allow ACE All Submit

Users Messages to
any Recipient

Authenticated Allow ACE All Accept

Users Routing
Headers

Authenticated Allow ACE All Bypass Anti-

Users Spam

Authenticated Allow ACE All Submit

Users Messages to
Server

Exchange Allow ACE All Accept

Servers XSessionPara
ms

S-1-9- Allow ACE All Accept This is the

1419165041- XSessionPara well-known
1139599005- ms SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- XSessionPara well-known
1139599005- ms SID for
3936102811- Mailbox
1022490595- servers.
22

Exchange Allow ACE All Accept Any

Servers Sender

S-1-9- Allow ACE All Accept Any This is the

1419165041- Sender well-known
1139599005- security
3936102811- identifier (SID)
1022490595- for Mailbox
21 servers.

S-1-9- Allow ACE All Accept Any This is the

1419165041- Sender well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept Any This is the

1419165041- Sender well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

S-1-9- Allow ACE All Accept Exch50 This is the

1419165041- well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Exch50 This is the

1419165041- well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept Exch50 This is the

1419165041- well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept Exch50

Servers

Exchange Allow ACE All Submit

Servers Messages to
any Recipient

ExchangeLegac Allow ACE All Submit

yInterop Messages to
any Recipient

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- any Recipient SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- any Recipient SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- any Recipient SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers XShadow

S-1-9- Allow ACE All Accept This is the

1419165041- XShadow well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept

Servers Routing
Headers

ExchangeLegac Allow ACE All Accept

yInterop Routing
Headers

S-1-9- Allow ACE All Accept This is the

1419165041- Routing well-known
1139599005- Headers SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Routing well-known
1139599005- Headers SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- Routing well-known
1139599005- Headers SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept Forest

Servers Headers
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept Forest This is the

1419165041- Headers well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Forest This is the

1419165041- Headers well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept xAttr

Servers

S-1-9- Allow ACE All Accept xAttr This is the

1419165041- well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept xAttr This is the

1419165041- well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept

Servers XProxyFrom

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XProxyFrom well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XProxyFrom well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Accept

Servers Authentication
Flag
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers XSysProbe

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XSysProbe well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept Forest This is the

1419165041- XSysProbe well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- Authentication well-known
1139599005- Flag SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Bypass Anti-

Servers Spam
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Bypass Anti- This is the

1419165041- Spam well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Bypass Anti- This is the

1419165041- Spam well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Bypass Anti- This is the

1419165041- Spam well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Send

Servers XMessageCon
text Extended
Properties

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Extended SID for
3936102811- Properties Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Extended SID for Edge
3936102811- Properties Transport
1022490595- servers.
22

Exchange Allow ACE All Send

Servers XMessageCon
text Fast Index

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Fast Index SID for
3936102811- Mailbox
1022490595- servers.
21
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text Fast Index SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Bypass

Servers Message Size
Limit

S-1-9- Allow ACE All Bypass This is the

1419165041- Message Size well-known
1139599005- Limit SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Bypass This is the

1419165041- Message Size well-known
1139599005- Limit SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Bypass This is the

1419165041- Message Size well-known
1139599005- Limit SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers Organization
Headers

S-1-9- Allow ACE All Accept This is the

1419165041- Organization well-known
1139599005- Headers SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Organization well-known
1139599005- Headers SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

Exchange Allow ACE All Send

Servers XMessageCon
text AD
Recipient
Cache

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text AD SID for
3936102811- Recipient Mailbox
1022490595- Cache servers.
21

S-1-9- Allow ACE All Send This is the

1419165041- XMessageCon well-known
1139599005- text AD SID for Edge
3936102811- Recipient Transport
1022490595- Cache servers.
22

Exchange Allow ACE All Submit

Servers Messages to
Server

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- Server SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- Server SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Submit This is the

1419165041- Messages to well-known
1139599005- Server SID for
3936102811- externally
1022490595- secured
23 servers.

Exchange Allow ACE All Accept

Servers Authoritative
Domain
Sender
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Accept This is the

1419165041- Authoritative well-known
1139599005- Domain SID for
3936102811- Sender Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Accept This is the

1419165041- Authoritative well-known
1139599005- Domain SID for Edge
3936102811- Sender Transport
1022490595- servers.
22

S-1-9- Allow ACE All Accept This is the

1419165041- Authoritative well-known
1139599005- Domain SID for
3936102811- Sender externally
1022490595- secured
23 servers.

SMTP Send Connector Creation

The following table shows the permissions set when you create Send connectors.
Distinguished name of the object: CN=<Connector Name>,CN=Connections,CN=<routing group>,CN=Routing
Groups, CN=<admin group>,CN=<organization>
ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

NT Allow ACE All Send Routing

AUTHORITY\A Headers
NONYMOUS
LOGON

Exchange Allow ACE All Send

Servers Organization
Headers

S-1-9- Allow ACE All Send This is the

1419165041- Organization well-known
1139599005- Headers SID for
3936102811- Mailbox
1022490595- servers.
21
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Send This is the

1419165041- Organization well-known
1139599005- Headers SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Send Forest This is the

Servers Headers well-known
SID for
Mailbox
servers.

S-1-9- Allow ACE All Send Forest This is the

1419165041- Headers well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Send Forest This is the

1419165041- Headers well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Send XShadow

Servers

S-1-9- Allow ACE All Send XShadow This is the

1419165041- well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Send XShadow This is the

1419165041- well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

Exchange Allow ACE All Send Routing

Servers Headers
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Send Routing This is the

1419165041- Headers well-known
1139599005- SID for
3936102811- partner
1022490595- servers.
10

S-1-9- Allow ACE All Send Routing This is the

1419165041- Headers well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Send Routing This is the

1419165041- Headers well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22

S-1-9- Allow ACE All Send Routing This is the

1419165041- Headers well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

S-1-9- Allow ACE All Send Routing This is the

1419165041- Headers well-known
1139599005- SID for Legacy
3936102811- Exchange
1022490595- Servers.
24

Exchange Allow ACE All Send Exch50

Servers

S-1-9- Allow ACE All Send Exch50 This is the

1419165041- well-known
1139599005- SID for
3936102811- Mailbox
1022490595- servers.
21

S-1-9- Allow ACE All Send Exch50 This is the

1419165041- well-known
1139599005- SID for Edge
3936102811- Transport
1022490595- servers.
22
 ON PROPERTY/
ACCOUNT ACE TYPE INHERITANCE PERMISSIONS APPLIES TO COMMENTS

S-1-9- Allow ACE All Send Exch50 This is the

1419165041- well-known
1139599005- SID for
3936102811- externally
1022490595- secured
23 servers.

S-1-9- Allow ACE All Send Exch50 This is the

1419165041- well-known
1139599005- SID for Legacy
3936102811- Exchange
1022490595- Servers.
24
 Deployment security checklist
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 features are designed to help improve the security of your messaging
environment. Generally, for Exchange 2013, the following conditions are true:
Accounts that are used by Exchange 2013 have the minimum rights that are required to perform the given
task sets.
By default, services are started only when they are required.
Access control list (ACL ) rights for Exchange objects are minimized.
Administrative permissions are set according to the scope of change on the object that a given
modification requires.
By default, all internal default message paths are encrypted.
This topic lists steps that we recommend you take to harden the messaging environment before you install
Microsoft Exchange. We recommend that you refer to this checklist every time that you install a new Exchange
server role.
Before installing Exchange 2013, perform the following procedures.

PROCEDURE DONE?

Run Microsoft Update.

Run the Microsoft Windows Malicious Software Removal

Tool. The Malicious Software Removal Tool is included
with Microsoft Update. More information about the tool
can be found at Malicious Software Removal Tool.

Run the Microsoft Baseline Security Analyzer.

 Exchange 2013 sizing and capacity planning
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sizing and capacity planning for Exchange Server 2013 is an important part of your Exchange 2013 deployment.
Configuring a system for optimum performance is an iterative process. Take the time to understand all the
variables that affect your system, including user profile, architecture, and hardware. With this knowledge, you can
establish baseline metrics for your systems and make adjustments to improve system performance. For more
information and guidance about sizing and capacity planning for your Exchange organization, see the Exchange
Team blog article Ask the Perf Guy: Sizing Exchange 2013 Deployments and Exchange Server 2013 Performance
Recommendations.
 Exchange 2013 storage configuration options
6/11/2019 • 21 minutes to read • Edit Online

Applies to: Exchange Server 2013

Understanding storage options and requirements for the Mailbox server role in Microsoft Exchange Server 2013
is an important part of your Mailbox server storage design solution.

Storage architectures
The following table describes supported storage architectures and provides best practice guidance for each type of
storage architecture where appropriate.
Supported storage architectures
STORAGE ARCHITECTURE DESCRIPTION BEST PRACTICE

Direct-attached storage (DAS) DAS is a digital storage system Not available.

directly attached to a server or
workstation, without a storage
network in between. For example,
DAS transports include Serial
Attached Small Computer System
Interface (SCSI) and Serial Attached
Advanced Technology Attachment
(ATA).

Storage area network (SAN): SAN is an architecture to attach Don't share physical disks backing
Internet Small Computer System remote computer storage devices up Exchange data with other
Interface (iSCSI) (such as disk arrays and tape applications.
libraries) to servers in such a way
that the devices appear as locally Use dedicated storage networks.
attached to the operating system Use multiple network paths for
(for example, block storage). iSCSI stand-alone configurations.
SANs encapsulate SCSI commands
within IP packets and use standard
networking infrastructure as the
storage transport (for example,
Ethernet).

SAN: Fibre Channel Fibre Channel SANs encapsulate Don't share physical disks backing
SCSI commands within Fibre up Exchange data with other
Channel packets and generally applications.
utilize specialized Fibre Channel
networks as the storage transport. Use multiple Fibre Channel network
paths for stand-alone
configurations.
Follow storage vendor's best
practices for tuning Fibre Channel
host bus adapters (HBAs), for
example, Queue Depth and Queue
Target.

A network-attached storage (NAS ) unit is a self-contained computer connected to a network, with the sole
purpose of supplying file-based data storage services to other devices on the network. The operating system and
other software on the NAS unit provide the functionality of data storage, file systems, and access to files, and the
management of these functionalities (for example, file storage).
All storage used by Exchange for storage of Exchange data must be block-level storage because Exchange 2013
doesn't support the use of NAS volumes, other than in the SMB 3.0 scenario outlined in the topic Exchange 2013
virtualization. Also, in a virtualized environment, NAS storage that's presented to the guest as block-level storage
via the hypervisor isn't supported.
Using storage tiers is not recommended, as it could adversely affect system performance. For this reason, do not
allow the storage controller to automatically move the most accessed files to "faster" storage.

Physical disk types

The following table provides a list of supported physical disk types and provides best practice guidance for each
physical disk type where appropriate.
Supported physical disk types
PHYSICAL DISK TYPE DESCRIPTION SUPPORTED OR BEST PRACTICE

Serial ATA (SATA) SATA is a serial interface for ATA Supported: 512-byte sector disks
and integrated device electronics for Windows Server 2008 and
(IDE) disks. SATA disks are available Windows Server 2008 R2. In
in a variety of form factors, speeds, addition, 512e disks are supported
and capacities. for Windows Server 2008 R2 with
the following:
In general, choose SATA disks for
Exchange 2013 mailbox storage The hotfix described in
when you have the following Microsoft Knowledge Base
design requirements: article 982018, An update
that improves the
High capacity compatibility of Windows 7
Moderate performance and Windows Server 2008
R2 with Advanced Format
Moderate power utilization Disks is available.
Windows Server 2008 R2
with Service Pack 1 (SP1)
and Exchange Server 2010
SP1.
Exchange 2013 and later supports
native 4-kilobyte (KB) sector disks
and 512e disks. Support requires
that all copies of a database reside
on the same physical disk type. For
example, it is not a supported
configuration to host one copy of a
given database on a 512-byte
sector disk and another copy of
that same database on a 512e disk
or 4K disk.
Best practice: Consider enterprise
class SATA disks, which generally
have better heat, vibration, and
reliability characteristics.
PHYSICAL DISK TYPE DESCRIPTION SUPPORTED OR BEST PRACTICE

Serial Attached SCSI Serial Attached SCSI is a serial Supported: 512-byte sector disks
interface for SCSI disks. Serial for Windows Server 2008 and
Attached SCSI disks are available in Windows Server 2008 R2. In
a variety of form factors, speeds, addition, 512e disks are supported
and capacities. for Windows Server 2008 R2 with
the following:
In general, choose Serial Attached
SCSI disks for Exchange 2013 The hotfix described in
mailbox storage when you have the Microsoft Knowledge Base
following design requirements: article 982018, An update
that improves the
Moderate capacity compatibility of Windows 7
High performance and Windows Server 2008
R2 with Advanced Format
Moderate power utilization Disks is available.
Windows Server 2008 R2
with Service Pack 1 (SP1)
and Exchange Server 2010
SP1.
Exchange 2013 and later supports
native 4-kilobyte (KB) sector disks
and 512e disks. Support requires
that all copies of a database reside
on the same physical disk type. For
example, it is not a supported
configuration to host one copy of a
given database on a 512-byte
sector disk and another copy of
that same database on a 512e disk
or 4K disk.
Best practice: Physical disk-write
caching must be disabled when
used without a UPS.
PHYSICAL DISK TYPE DESCRIPTION SUPPORTED OR BEST PRACTICE

Fibre Channel Fibre Channel is an electrical Supported: 512-byte sector disks

interface used to connect disks to for Windows Server 2008 and
Fibre Channel-based SANs. Fibre Windows Server 2008 R2. In
Channel disks are available in a addition, 512e disks are supported
variety of speeds and capacities. for Windows Server 2008 R2 with
the following:
In general, choose Fibre Channel
disks for Exchange 2013 mailbox The hotfix described in
storage when you have the Microsoft Knowledge Base
following design requirements: article 982018, An update
that improves the
Moderate capacity compatibility of Windows 7
High performance and Windows Server 2008
R2 with Advanced Format
SAN connectivity Disks is available.
Windows Server 2008 R2
with Service Pack 1 (SP1)
and Exchange Server 2010
SP1.
Exchange 2013 and later supports
native 4-kilobyte (KB) sector disks
and 512e disks. Support requires
that all copies of a database reside
on the same physical disk type. For
example, it is not a supported
configuration to host one copy of a
given database on a 512-byte
sector disk and another copy of
that same database on a 512e disk
or 4K disk.
Best practice: Physical disk-write
caching must be disabled when
used without a UPS.
 PHYSICAL DISK TYPE DESCRIPTION SUPPORTED OR BEST PRACTICE

Solid-state drive (SSD) (flash disk) An SSD is a data storage device Supported: 512-byte sector disks
that uses solid-state memory to for Windows Server 2008 and
store persistent data. An SSD Windows Server 2008 R2. In
emulates a hard disk drive interface. addition, 512e disks are supported
SSD disks are available in a variety for Windows Server 2008 R2 with
of speeds (different I/O the following:
performance capabilities) and
capacities. The hotfix described in
Microsoft Knowledge Base
In general, choose SSD disks for article 982018, An update
Exchange 2013 mailbox storage that improves the
when you have the following compatibility of Windows 7
design requirements: and Windows Server 2008
R2 with Advanced Format
Low capacity Disks is available.
Extremely high performance Windows Server 2008 R2
with Service Pack 1 (SP1)
and Exchange Server 2010
SP1.
Exchange 2013 and later supports
native 4-kilobyte (KB) sector disks
and 512e disks. Support requires
that all copies of a database reside
on the same physical disk type. For
example, it is not a supported
configuration to host one copy of a
given database on a 512-byte
sector disk and another copy of
that same database on a 512e disk
or 4K disk.
Best practice: Physical disk-write
caching must be disabled when
used without a UPS.
In general, Exchange 2013 Mailbox
servers don't require the
performance characteristics of SSD
storage.

Factors to consider when choosing disk types

There are several trade-offs when choosing disk types for Exchange 2013 storage. The correct disk is one that
balances performance (both sequential and random) with capacity, reliability, power utilization, and capital cost.
The following table of supported physical disk types provides information to help you when considering these
factors.
From a performance perspective, using large, slower disks for Exchange storage is okay, provided the disks can
maintain an average read and write latency of 20ms or less under load.
Factors in disk type choice
SEQUENTIAL
DISK SPEED DISK FORM INTERFACE OR RANDOM I/O I/O POWER
(RPM) FACTOR TRANSPORT CAPACITY PERFORMANCE PERFORMANCE UTILIZATION

5,400 2.5-inch SATA Average Poor Poor Excellent

 SEQUENTIAL
DISK SPEED DISK FORM INTERFACE OR RANDOM I/O I/O POWER
(RPM) FACTOR TRANSPORT CAPACITY PERFORMANCE PERFORMANCE UTILIZATION

5,400 3.5-inch SATA Excellent Poor Poor Above

average

7,200 2.5-inch SATA Average Average Average Excellent

7,200 2.5-inch Serial Average Average Above Excellent

Attached average
SCSI

7,200 3.5-inch SATA Excellent Average Above Above

average average

7,200 3.5-inch Serial Excellent Average Above Above

Attached average average
SCSI

7,200 3.5-inch Fibre Excellent Average Above Average

Channel average

10,000 2.5-inch Serial Below Excellent Above Above

Attached average average average
SCSI

10,000 3.5-inch SATA Average Average Above Above

average average

10,000 3.5-inch Serial Average Above Above Below

Attached average average average
SCSI

10,000 3.5-inch Fibre Average Above Above Below

Channel average average average

15,000 2.5-inch Serial Poor Excellent Excellent Average

Attached
SCSI

15,000 3.5-inch Serial Average Excellent Excellent Below

Attached average
SCSI

15,000 3.5-inch Fibre Average Excellent Excellent Poor

Channel
 SEQUENTIAL
DISK SPEED DISK FORM INTERFACE OR RANDOM I/O I/O POWER
(RPM) FACTOR TRANSPORT CAPACITY PERFORMANCE PERFORMANCE UTILIZATION

SSD: Not SATA, Poor Excellent Excellent Excellent

enterprise applicable Serial
class Attached
SCSI, Fibre
Channel

Best practices for supported storage configurations

This section provides best practice information about supported disk and array controller configurations.
Redundant Array of Independent Disks (RAID ) is often used to both improve the performance characteristics of
individual disks (by striping data across several disks) as well as to provide protection from individual disk failures.
With the advancements in Exchange 2013 high availability, RAID is not a required component for Exchange 2013
storage design. However, RAID is still an essential component of Exchange 2013 storage design for standalone
servers as well as solutions that require storage fault tolerance.
Operating System, System, or Pagefile Volume
The recommended configuration for an operating system, system or pagefile volume is to utilize RAID technology
to protect this data type. The recommended RAID configuration is either RAID -1 or RAID -1/0, however all RAID
types are supported.
Separated Mailbox Database and Log Volumes
If you are deploying a standalone Mailbox server role architecture, RAID technology is required for the mailbox
database and log volumes. The recommended RAID configuration for mailbox volumes is RAID -1/0 (especially if
you are using 5.4K or 7.2K disks); however all RAID types are supported. For log volumes, RAID -1 or RAID -1/0 is
the recommended RAID configuration.
When using RAID -5 or RAID -6 configurations for the operating system, pagefile, or Exchange data volumes, note
the following:
RAID -5 configurations, including variations such as RAID -50 and RAID -51, should have no more than 7
disks per array group and array controller high-priority scrubbing and surface scanning enabled.
RAID -6 configurations should have array controller high-priority scrubbing and surface scanning enabled.
While JBOD is supported in high availability architectures that have 3 or more highly available database copies,
because the log and mailbox database volumes are separated, JBOD is not recommended.
Mailbox Database and Log Volume Co-Location
Mailbox database and log volume co-location is not recommended in standalone architectures. In high availability
architectures, there are two possibilities for this scenario:
1. Single database per volume
2. Multiple databases per volume
Single Database Per Volume
From an Exchange perspective, JBOD means having both the database and its associated logs stored on a single
disk. To deploy on JBOD, you must deploy a minimum of three highly available database copies. Utilizing a single
disk is a single point of failure, because when the disk fails, the database copy residing on that disk is lost. Having a
minimum of three database copies ensures fault tolerance by having two additional copies in the event that one
copy (or one disk) fails. However, placement of three highly available database copies, as well as the use of lagged
database copies, can affect storage design. The following table shows guidelines for RAID or JBOD
considerations.
RAID or JBOD Considerations
TWO OR MORE
TWO HIGHLY THREE HIGHLY HIGHLY TWO OR MORE
DATACENTER AVAILABLE COPIES AVAILABLE COPIES AVAILABLE COPIES LAGGED COPIES
SERVERS (TOTAL) (TOTAL) PER DATACENTER ONE LAGGED COPY PER DATACENTER

Primary RAID RAID or RAID or RAID RAID or

datacenter JBOD (2 JBOD JBOD
servers copies)

Secondary RAID RAID (1 RAID or RAID RAID or

datacenter copy) JBOD JBOD
servers

To deploy on JBOD with the primary datacenter servers, you need three or more highly available database copies
within the DAG. If mixing lagged copies on the same server hosting highly available database copies (for example,
not using dedicated lagged database copy servers), you need at least two lagged database copies.
For the secondary datacenter servers to use JBOD, you should have at least two highly available database copies
in the secondary datacenter. The loss of a copy in the secondary datacenter won't result in requiring a reseed
across the WAN or having a single point of failure in the event the secondary datacenter is activated. If mixing
lagged database copies on the same server hosting highly available database copies (for example, not using
dedicated lagged database copy servers), you need at least two lagged database copies.
For dedicated lagged database copy servers, you should have at least two lagged database copies within a
datacenter to use JBOD. Otherwise, the loss of disk results in the loss of the lagged database copy, as well as the
loss of the protection mechanism.
Multiple Databases Per Volume
Multiple databases per volume is a new JBOD scenario available in Exchange 2013 that allows for active and
passive copies (including lagged copies) to be mixed on a single disk, enabling better disk utilization. However, to
deploy lagged copies in this manner, automatic lagged copy log file play down must be enabled. The following
table shows guidelines for JBOD considerations for multiple databases per volume.
JBOD Considerations
DATACENTER SERVERS 3 OR MORE COPIES (TOTAL) TWO OR MORE COPIES PER DATACENTER

Primary datacenter servers JBOD JBOD

Secondary datacenter servers N/A JBOD

The following table provides guidance about storage array configurations for Exchange 2013.
Supported RAID types for the Exchange 2013 Mailbox server role
RAID TYPE DESCRIPTION SUPPORTED OR BEST PRACTICE
 RAID TYPE DESCRIPTION SUPPORTED OR BEST PRACTICE

Disk array RAID stripe size (KB) The stripe size is the per disk unit of Best practice: 256 KB or greater.
data distribution within a RAID set. Follow storage vendor best
Stripe size is also referred to as practices.
block size.

Storage array cache settings The cache settings are provided by Best practice: 100 percent write
a battery-backed caching array cache (battery or flash-backed
controller. cache) for DAS storage controllers
in either a RAID or JBOD
configuration. 75 percent write
cache, 25 percent read cache
(battery or flash-backed cache) for
other types of storage solutions
such as SAN. If your SAN vendor
has different best practices for
cache configuration on their
platform, follow the guidance of
your SAN vendor.

Physical disk write caching The settings for the cache are on Supported: Physical disk write
each individual disk. caching must be disabled when
used without a UPS.

The following table provides guidance about database and log file choices.
Database and log file choices for the Exchange 2013 Mailbox server role
HIGH AVAILABILITY:
DATABASE AND LOG FILE STAND-ALONE: SUPPORTED SUPPORTED OR BEST
OPTIONS DESCRIPTION OR BEST PRACTICE PRACTICE

File placement: database Database per log Best practice: For Supported: Isolation of
per log isolation isolation refers to recoverability, move logs and databases isn't
placing the database file database (.edb) file and required.
and logs from the same logs from the same
mailbox database onto database to different
different volumes volumes backed by
backed by different different physical disks.
physical disks.

File placement: database Database files per Best practice: Based on Supported: When using
files per volume volume refers to how your backup JBOD, create a single
you distribute database methodology. volume with separate
files within or across disk directories for
volumes. database(s) and for log
files.
 HIGH AVAILABILITY:
DATABASE AND LOG FILE STAND-ALONE: SUPPORTED SUPPORTED OR BEST
OPTIONS DESCRIPTION OR BEST PRACTICE PRACTICE

File placement: log Log streams per volume Best practice: Based on Supported: When using
streams per volume refers to how you your backup JBOD, create a single
distribute database log methodology. volume with separate
files within or across disk directories for
volumes. database(s) and for log
files.
Best practice: When
using JBOD, leverage
multiple databases per
volume.

Database size Database size refers to Supported: Supported:

the disk database (.edb) Approximately Approximately
file size. 16 terabytes. 16 terabytes.
Best practice: Best practice:
200 gigabytes 2 terabytes or
(GB) or less. less.
Provision for 120 Provision for 120
percent of percent of
calculated calculated
maximum maximum
database size. database size.

Log truncation method Log truncation method Best practice: Best practice:
is the process for
truncating and deleting Use backups for Enable circular
old database log files. log truncation logging for
There are two (for example, deployments
mechanisms: circular logging that use
disabled). Exchange native
Circular logging, data protection
in which Provision for features.
Exchange deletes three days of log
the logs. generation Provision for
capacity. three days
Log truncation, beyond replay
which occurs lag setting of log
after a successful generation
full or capacity.
incremental
Volume Shadow
Copy Service
(VSS) backup.

The following table provides guidance about Windows disk types.

Windows disk types for the Exchange 2013 Mailbox server role
HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
WINDOWS DISK TYPE DESCRIPTION OR BEST PRACTICE PRACTICE
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
WINDOWS DISK TYPE DESCRIPTION OR BEST PRACTICE PRACTICE

Basic disk A disk initialized for Supported. Supported.

basic storage is called a
basic disk. A basic disk Best practice: Use basic Best practice: Use basic
contains basic volumes, disks. disks.
such as primary
partitions, extended
partitions, and logical
drives.

Dynamic disk A disk initialized for Supported. Supported.

dynamic storage is
called a dynamic disk. A
dynamic disk contains
dynamic volumes, such
as simple volumes,
spanned volumes,
striped volumes,
mirrored volumes, and
RAID-5 volumes.

The following table provides guidance on volume configurations.

Volume configurations for the Exchange 2013 Mailbox server role
HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

GUID partition table GPT is a disk Supported. Supported.

(GPT) architecture that
expands on the older Best practice: Use GPT Best practice: Use GPT
master boot record partitions. partitions.
(MBR) partitioning
scheme. The maximum
NTFS formatted
partition size is
256 terabytes.

MBR An MBR, or partition Supported. Supported.

sector, is the 512-byte
boot sector that is the
first sector (LBA Sector
0) of a partitioned data
storage device such as a
hard disk. The maximum
NTFS formatted
partition size is
2 terabytes.

Partition alignment Partition alignment Supported: The Supported: The

refers to aligning Windows Server 2008 Windows Server 2008
partitions on sector R2 and Windows Server R2 and Windows Server
boundaries for optimal 2012 default is 2012 default is 1 MB.
performance. 1 megabyte (MB).
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

Volume path Volume path refers to Supported: Drive letter Supported: Drive letter
how a volume is or mount point. or mount point.
accessed.
Best practice: Mount Best practice: Mount
point host volume must point host volume must
be RAID enabled. be RAID-enabled.

File system File system is a method Supported: NTFS and Supported: NTFS and
for storing and ReFS. ReFS.
organizing computer
files and the data they
contain to make it easy
to find and access the
files.

NTFS defragmentation NTFS defragmentation is Supported. Supported.

a process that reduces
the amount of Best practice: Not Best practice: Not
fragmentation in required and not required and not
Windows file systems. It recommended. On recommended. On
does this by physically Windows Server 2012, Windows Server 2012,
organizing the contents we also recommend we also recommend
of the disk to store the disabling the automatic disabling the automatic
pieces of each file close disk optimization and disk optimization and
together and defragmentation defragmentation
contiguously. feature. feature.

NTFS allocation unit size NTFS allocation unit size Supported: All allocation Supported: All allocation
represents the smallest unit sizes. unit sizes.
amount of disk space
that can be allocated to Best practice: 64 KB for Best practice: 64 KB for
hold a file. both .edb and log file both .edb and log file
volumes. volumes.

NTFS compression NTFS compression is the Supported: Not Supported: Not

process of reducing the supported for Exchange supported for Exchange
actual size of a file database or log files. database or log files.
stored on the hard disk.

NTFS Encrypting File EFS enables users to Supported: Not Not supported for
System (EFS) encrypt individual files, supported for Exchange Exchange database or
folders, or entire data database or log files. log files.
drives. Because EFS
provides strong
encryption through
industry-standard
algorithms and public
key cryptography,
encrypted files are
confidential even if an
attacker bypasses
system security.
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

Windows BitLocker Windows BitLocker is a Supported: All Exchange Supported: All Exchange
(volume encryption) data protection feature database and log files. database and log files.
in Windows Server Windows failover
2008. BitLocker protects clusters require
against data theft or Windows Server 2008
exposure on computers R2 or Windows Server
that are lost or stolen, 2008 R2 SP1 and the
and it offers more following hotfix: You
secure data deletion cannot enable BitLocker
when computers are on a disk volume in
decommissioned. Windows Server 2008
R2 if the computer is a
failover cluster node.
Exchange volumes with
Bitlocker enabled are
not supported on
Windows failover
clusters running earlier
versions of Windows.
For more information
about Windows 7
BitLocker encryption,
see BitLocker Drive
Encryption in Windows
7: Frequently Asked
Questions.
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

Server Message Block The Server Message Limited Support. Limited Support.
(SMB) 3.0 Block (SMB) protocol is a Supported scenario is a Supported scenario is a
network file sharing hardware virtualized hardware virtualized
protocol (on top of deployment where the deployment where the
TCP/IP or other network disks are hosted on disks are hosted on
protocols) that allows VHDs on an SMB 3.0 VHDs on an SMB 3.0
applications on a share. These VHDs are share. These VHDs are
computer to access files presented to the host presented to the host
and resources on a via a hypervisor. For via a hypervisor. For
remote server. It also more information, see more information, see
allows applications to Exchange 2013 Exchange 2013
communicate with any virtualization. virtualization.
server program that is
set up to receive an
SMB client request.
Windows Server 2012
introduces the new 3.0
version of the SMB
protocol with the
following features:
SMB Transparent
failover
SMB Scaleout
SMB
Multichannel
SMB Direct
SMB Encryption
VSS for SMB file
shares
SMB Directory
Leasing
SMB PowerShell
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

Storage Spaces Storage Spaces is a new Supported. Same Supported. Same

storage solution that restrictions as for restrictions as for
delivers virtualization physical disk types physical disk types
capabilities for Windows outlined in this topic. outlined in this topic.
Server 2012. Storage
Spaces allow you to
organize physical disks
into storage pools,
which can be easily
expanded by simply
adding disks. These
disks can be connected
either through USB,
SATA or SAS. It also
utilizes virtual disks
(spaces), which behave
just like physical disks,
with associated powerful
capabilities such as thin
provisioning, as well as
resiliency to failures of
underlying physical
media. For more
information on Storage
Spaces, see Storage
Spaces Overview.
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

Resilient File System ReFS is a newly Supported for volumes Supported for volumes
(ReFS) engineered file system containing Exchange containing Exchange
for Windows Server database files, log files database files, log files
2012 that is built on the and content indexing and content indexing
foundations of NTFS. files. If deploying on files. If deploying on
ReFS maintains high Windows Server 2012, Windows Server 2012,
degree of compatibility ensure the following ensure the following
with NTFS while hotfixes are installed on hotfixes are installed on
providing enhanced Windows Server 2012: Windows Server 2012:
data verification and
auto-correction Windows 8 and Windows 8 and
techniques as well as an Windows Server Windows Server
integrated end-to-end 2012 update 2012 update
resiliency to corruptions rollup: April 2013 rollup: April 2013
especially when used in Virtual Disk Virtual Disk
conjunction with the Service or Service or
storage spaces feature. applications that applications that
For more information on use the Virtual use the Virtual
ReFS, see Resilient File Disk Service Disk Service
System Overview. crash or freeze in crash or freeze in
Windows Server Windows Server
2012 2012
Windows 8- Windows 8-
based or based or
Windows Server Windows Server
2012-based 2012-based
computer freezes computer freezes
when you run when you run
the 'dir' the 'dir'
command on an command on an
ReFS volume ReFS volume
ReFS is not supported ReFS is not supported
for OS volumes. for OS volumes.
Best practice: Data Best practice: Data
integrity features must integrity features must
be disabled for the be disabled for the
Exchange database Exchange database
(.edb) files or the volume (.edb) files or the volume
that hosts these files. that hosts these files.
 HIGH AVAILABILITY:
STAND-ALONE: SUPPORTED SUPPORTED OR BEST
VOLUME CONFIGURATION DESCRIPTION OR BEST PRACTICE PRACTICE

Data De-Duplication Data deduplication is a Not Supported for Not Supported for
new technique to Exchange database files. Exchange database files.
optimize storage Note: Can be used for Note: Can be used for
utilization for Windows Exchange database files Exchange database files
Server 2012. It is a that are completely that are completely
method of finding and offline (used as backups offline (used as backups
removing duplication or archives). or archives).
within data without
compromising its fidelity
or integrity. The goal is
to store more data in
less space by
segmenting files into
small variable-sized
chunks, identifying
duplicate chunks, and
maintaining a single
copy of each chunk.
Redundant copies of the
chunk are replaced by a
reference to the single
copy, the chunks are
organized into container
files, and the containers
are compressed for
further space
optimization.
 IPv6 support in Exchange 2013
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP ). IPv6 is intended to
correct many of the shortcomings of IPv4, which was the previous version of the IP.
In Microsoft Exchange Server 2013, IPv6 is supported only when IPv4 is also installed and enabled. If Exchange
2013 is deployed in this configuration, and the network supports IPv4 and IPv6, all Exchange servers can send
data to and receive data from devices, servers, and clients that use IPv6 addresses.
This topic discusses IPv6 addressing in Exchange 2013. For additional background information about IPv6, see
IPv6.

IPv6 support in Exchange 2013 components

The following table describes the components in Exchange 2013 that are affected by IPv6.
Exchange 2013 features and IPv6
FEATURE IPV6 SUPPORTED COMMENTS

IP Allow list and IP Block list in the Yes

Connection Filtering agent

IP Allow List providers and IP Block No Currently, there is no widely

List providers in the Connection accepted industry standard
Filtering agent. protocol for looking up IPv6
addresses. Most IP Block List
providers don't support IPv6
addresses. If you allow anonymous
connections from unknown IPv6
addresses on a Receive connector,
you increase the risk that
spammers will bypass IP Block List
providers and successfully deliver
spam into your organization.

Sender reputation in the Protocol No The Protocol Analysis agent doesn't

Analysis agent compute the sender reputation
level (SRL) for messages that
originate from IPv6 senders. For
more information about sender
reputation, see Sender reputation
and the Protocol Analysis agent.

Sender ID Yes For more information, see Sender

ID.
FEATURE IPV6 SUPPORTED COMMENTS

Receive connectors Yes IPv6 addresses are accepted for the

following components:
Local IP address bindings
Remote IP addresses
IP address ranges
We strongly recommend against
configuring Receive connectors to
accept anonymous connections
from unknown IPv6 addresses. If
your organization must receive mail
from senders who use IPv6
addresses, create a dedicated
Receive connector that restricts the
remote IP addresses to the specific
IPv6 addresses that those senders
use.
For more information, see Receive
connectors.

Send connectors Yes IPv6 addresses are accepted for the

following components:
Smart host IP addresses
The SourceIPAddress
parameter for Send
connectors configured on
Edge Transport servers

NOTE
If you want to specify an IPv6
address for the SourceIPAddress
parameter, make sure that the
appropriate DNS AAAA and mail
exchange (MX) records are
configured correctly. This helps
ensure message delivery if a
remote messaging server tries
any kind of reverse lookup test
on the specified IPv6 address.

For more information, see Send

connectors.
 FEATURE IPV6 SUPPORTED COMMENTS

Incoming message rate limits Partial Incoming message rate limits that
you can set on a Receive connector,
such as the
MaxInboundConnectionPercentage
PerSource parameter, the
MaxInboundConnectionPerSource
parameter, and the TarpitInterval
parameter, only apply to a global
IPv6 address. Link local IPv6
addresses and site local IPv6
addresses aren't affected by any
specified incoming message rate
limits.

Unified Messaging Yes For more information, see IPv6

support in Unified Messaging.

Database availability group (DAG) Yes Static IPv6 addresses are supported
member by Windows Server and the Cluster
service. However, using static IPv6
addresses goes against best
practices. Exchange 2013 doesn't
support the configuration of static
IPv6 addresses during setup.
Failover clusters support Intra-site
Automatic Tunnel Addressing
Protocol (ISATAP). They support
only IPv6 addresses that allow for
dynamic registration in DNS. Link
local addresses can't be used in a
cluster.
For more information about DAG
network requirements, see the
"Network requirements" section in
Planning for high availability and
site resilience.

Enable or disable protocols in the operating system

Exchange 2013 servers fully support IPv6 networks. Therefore, even if you aren't using IPv6, you don't need to
disable IPv6 on your Exchange servers.
IPv6 support in Exchange 2013 requires IPv4 to be installed and enabled on all Exchange 2013 servers.
Uninstalling IPv4 from your Exchange 2013 servers isn't supported.
To learn more about IPv6 support in Microsoft Windows, see IPv6 for Microsoft Windows: Frequently Asked
Questions.

IPv6 address basics

An IPv6 address is 128-bits long. The address is described by using colon-hexadecimal notation. Colon-
hexadecimal notation describes the 128-bit address by using eight 16-bit, 4-digit hexadecimal numbers separated
by the colon character (:). An example of an IPv6 address in colon-hexadecimal notation is
2001:0DB8:0000:0000:02AA:00FF:C0A8:640A.
You can express an IPv6 address by using the following methods:
Suppress leading zeros: You can omit the leading zeros in any of the eight 4-digit hexadecimal numbers
in an IPv6 address.
Double-colon compression: You can use two colons (::) to represent contiguous 16-bit hexadecimal digits
that contain all zeros. These all-zero digits may exist at the beginning, middle, or end of the IPv6 address.
You can only use double-colon compression one time in an IPv6 address.
Trailing dotted-decimal notation: You may express the last 32 bits at the end of an IPv6 address in
dotted-decimal notation by separating the 8-bit digits with a period (.). Trailing dotted-decimal notation is
frequently used with IPv4-compatible addresses.
The following table provides examples of the IPv6 address notation and the equivalent IPv6 address syntax.
IPv6 address notation and syntax
IPV6 ADDRESS NOTATION IPV6 ADDRESS SYNTAX

Full IPv6 address 2001:0DB8:0000:0000:02AA:00FF:C0A8:640A

IPv6 address that uses suppressed leading zeros 2001:DB8:0:0:2AA:FF:C0A8:640A

IPv6 address that uses double-colon compression 2001:DB8::2AA:FF:C0A8:640A

IPv6 address that uses trailing dotted-decimal notation 2001:DB8::2AA:FF:192.168.100.10

IPv6 addresses are categorized into the following types:

Unicast address: A packet is delivered to one interface.
Multicast address: A packet is delivered to multiple interfaces.
Anycast address: A packet is delivered to the nearest of multiple interfaces. The distance between
interfaces is defined by the routing cost.
IPv6 unicast addresses have the following possible scopes:
Link local: The scope of the IPv6 address is the local subnet. IPv6 link local addresses are comparable to
IPv4 link local addresses used in Automatic Private IP Addressing (APIPA).
Site local: The scope of the IPv6 address is the local organization. Site local addresses were deprecated by
RFC 3879 and replaced by unique local addresses as defined in RFC 4193. IPv6 site local addresses and
IPv6 unique local addresses are comparable to IPv4 private IP addresses.
Global: The scope of the IPv6 address is the whole world. IPv6 global addresses are comparable to IPv4
public IP addresses.
The following table provides a comparison of IPv4 elements and IPv6 elements.
IPv4 vs. IPv6 elements
ITEM IPV4 IPV6
 ITEM IPV4 IPV6

Private IP address 10.0.0.0/8 FD00::/8

172.16.0.0/12
192.168.0.0/16

Link local address 169.254.0.0/16 FE80::/64

Loopback address 127.0.0.1 ::1

Unspecified address 0.0.0.0 ::

Address resolution Address Resolution Protocol (ARP) Neighbor Discovery (ND)

Domain Name System (DNS) host Address record (A record) AAAA record or A6 record
name resolution

For more information about IPv6 addressing, see IPv6 Address Types.

Supported IPv6 Address Input Formats

The following types of IPv6 address input formats are supported in Exchange 2013:
A single IPv6 address
An IPv6 address range
An IPv6 address together with a subnet mask
An IPv6 address together with a subnet mask that uses Classless Interdomain Routing (CIDR ) notation
The following table provides examples of the acceptable IPv6 address input formats in Exchange 2013.
IPv6 address examples
TYPE EXAMPLE OF AN IPV6 ADDRESS

Single address 2001:DB8::2AA:FF:C0A8:640A

Address range 2001:DB8::2AA:FF:C0A8:640A-

2001:DB8::2AA:FF:C0A8:6414

Address together with subnet mask 2001:DB8::2AA:FF:C0A8:640A(FFFF:FFFF:FFFF:FFFF::)

Address together with subnet mask that uses CIDR 2001:DB8::2AA:FF:C0A8:640A/64

notation

In Exchange 2013, the following input formats are supported:

Suppression of leading zeros
Double-colon compression
Trailing dotted-decimal notation
 Exchange 2013 language support
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 has enhanced language support for both servers and clients. This topic lists the
languages that are available for both servers and clients in Exchange 2013.

Supported server languages for Exchange 2013

The following server languages are supported and available for Exchange 2013:
Chinese (Simplified)
Chinese (Traditional)
English
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish

Supported client languages for Exchange 2013

The following client languages are supported and available for Exchange 2013:
Amharic
Arabic
Basque (Basque)
Bengali (India)
Bulgarian
Catalan
Chinese (Simplified)
Chinese (Traditional)
Croatian
Czech
Danish
Dutch
English
Estonian
Filipino (Philippines)
Finnish
French
Galician
German
Greek
Gujarati
Hebrew
Hindi
Hungarian
Icelandic
Indonesian
Italian
Japanese
Kannada
Kazakh
Kiswahili
Korean
Latvian
Lithuanian
Malay (Brunei Darussalam)
Malay (Malaysia)
Malayalam
Marathi
Norwegian (Bokmål)
Norwegian (Nynorsk)
Oriya
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Romanian
Russian
Serbian (Cyrillic, Serbia)
Serbian (Latin)
Slovak
Slovenian
Spanish
Swedish
Tamil
Telugu
Thai
Turkish
Ukrainian
Urdu
Vietnamese
Welsh
 Exchange 2013 readiness checks
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The topics in this section provide details about the readiness checks Microsoft Exchange Server 2013 is
performing when Exchange is installed. Readiness checks ensure that your Active Directory forest and Exchange
servers are ready for Exchange 2013. Each readiness check topic describes the actions that you can take to resolve
issues that are found when the readiness checks are run. You should only perform the steps outlined in a readiness
check topic if that readiness check was displayed during setup.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 AD LDS directory exists in default location
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the attempt to install Active Directory Lightweight
Directory Services (AD LDS ) failed.
An older installation of AD LDS exists in the default location. Setup can't perform a new AD LDS install in an
existing AD LDS directory structure.
To resolve this issue, remove the existing AD LDS directory and then run Setup again.
For more information about AD LDS directory management, see Administering AD LDS Directory Partitions.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Duplicate Microsoft Exchange System Objects
container exists in Active Directory
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it found a duplicate Microsoft Exchange System
Objects container in Active Directory Domain Naming context. When Setup finds a duplicate Microsoft Exchange
System Objects container, you must delete the duplicate container before Setup can continue. When a duplicate
Microsoft Exchange System Objects container exists, you can't solve the problem by running DomainPrep again.
You must identify and delete the duplicate Microsoft Exchange System Objects container.
To resolve this issue, do the following:
1. Log on to the domain controller with administrative credentials.
2. In Administrative Tools, click Active Directory Users and Computers.
3. In the Active Directory Users and Computers management console pane, click View from the toolbar
menu and then select Advanced Features.
4. Locate the duplicate Microsoft Exchange System Objects container.
5. Verify the duplicate Microsoft Exchange System Objects container doesn't contain valid Active Directory
objects.
6. Right-click the duplicate Microsoft Exchange System Objects container, and then click Delete.
7. Confirm the deletion by clicking Yes in the Active Directory dialog box.

NOTE
If you want the change to be replicated immediately, you must manually initiate replication between domain controllers.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Failover Cluster Command Interface Windows feature
not installed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the local computer is missing a required Windows
feature. You'll need to install this Windows feature before Exchange 2013 can continue.
Exchange 2013 Setup requires that the Failover Cluster Command Interface Windows feature be installed on
the computer before installation can continue.
Do the following to install the Windows feature on this computer. If the feature requires a reboot to complete
installation, you'll need to exit Exchange 2013 Setup, reboot, and then start Setup again.

NOTE
Additional Windows features or updates might need to be installed before Exchange 2013 Setup can continue. For a
complete list of required Windows features and updates, check out Exchange 2013 prerequisites.

1. Open Windows PowerShell on the local computer.

2. Run the following command to install the required Windows feature.

Install-WindowsFeature RSAT-Clustering-CmdInterface

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Client Access server role is already installed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup has detected that you're attempting to install the Client Access server role;
however, the role is already installed on the computer.
If you want to reinstall the Client Access server role, you must first uninstall Exchange and then install the Client
Access server role.
You may also receive this message if a previous installation of Exchange didn't complete successfully. If this
happens, uninstall Exchange and then reinstall the Client Access server role. If the installation continues to fail, do
the following:
Make sure that your organization and the computer you're installing Exchange on meet the Exchange 2013
system requirements.
Make sure that you've installed all the prerequisites required by Exchange, as described in Exchange 2013
prerequisites.
Read the Release notes for Exchange 2013.
View the Exchange Setup log located in <installation drive>:\ExchangeSetupLogs\ExchangeSetup.log, and
look for errors or warnings that may have occurred during Setup.
Search the Exchange Server forums. In your search query, specify the title of this topic.
Search the Internet using your favorite search engine. Be sure to include the title of this topic in your search.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Active Directory does not exist or cannot be
contacted
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it can't contact a valid Active Directory directory
service site. Setup requires that the server you're installing Exchange on is able to locate the configuration naming
context in Active Directory.
To resolve this issue, verify that the user account running Exchange Setup is an Active Directory user and then run
Setup again. If this doesn't resolve the issue, follow the guidance about using the dcdiag.exe and repadmin.exe
support tools from the topics below to further diagnose the problem.
For more information about Active Directory troubleshooting and configuration for Exchange, see the following
topics:
Prepare Active Directory and domains
Troubleshooting Active Directory Domain Services
Configuring a Computer for Troubleshooting
Troubleshooting Active Directory Replication Problems
Monitoring and Troubleshooting Active Directory Replication Using Repadmin
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 The local computer isn't joined to an Active Directory
domain
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected that the local computer isn't a member of
an Active Directory domain. You must join the local computer to an Active Directory domain before you can install
Exchange Server 2013. You may also see this message if you log into a local user account on the computer instead
of a domain user account with sufficient administrative rights to install Exchange 2013.
For more information, see Exchange 2013 system requirements.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation of the first Exchange server in the
organization can't be delegated
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to install the first Exchange 2013 server in the organization.
Although Exchange 2013 Setup allows using delegation to install successive server roles, Setup requires that the
user who is logged on is a member of the Enterprise Admins Windows security group when the first Exchange
2013 server in the organization is installed. This is required because Exchange 2013 Setup creates and configures
objects in the Exchange Organization container in Active Directory during installation.

NOTE
If you haven't prepared the Active Directory schema for Exchange 2013, the logged-on user must also be a member of the
Schema Admins Windows security group. Alternately, another user who's a member of the Schema Admins Windows group
can prepare the Active Directory schema before Exchange 2013 is installed.

To resolve this issue, add the logged-on user as a member of the Enterprise Admins security group. Or, log on to
an account that's a member of the Enterprise Admins security group. Then run Exchange 2013 Setup again.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation of the first Exchange server in the
organization can't be delegated
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to install the first Exchange 2013 server in the organization.
Although Exchange 2013 Setup allows using delegation to install successive server roles, Setup requires that the
user who is logged on is a member of the Enterprise Admins Windows security group when the first Exchange
2013 server in the organization is installed. This is required because Exchange 2013 Setup creates and configures
objects in the Exchange Organization container in Active Directory during installation.

NOTE
If you haven't prepared the Active Directory schema for Exchange 2013, the logged-on user must also be a member of the
Schema Admins Windows security group. Alternately, another user who's a member of the Schema Admins Windows group
can prepare the Active Directory schema before Exchange 2013 is installed.

To resolve this issue, add the logged-on user as a member of the Enterprise Admins security group. Or, log on to
an account that's a member of the Enterprise Admins security group. Then run Exchange 2013 Setup again.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation of the first Exchange server in the
organization can't be delegated
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to install the first Exchange 2013 server in the organization.
Although Exchange 2013 Setup allows using delegation to install successive server roles, Setup requires that the
user who is logged on is a member of the Enterprise Admins Windows security group when the first Exchange
2013 server in the organization is installed. This is required because Exchange 2013 Setup creates and configures
objects in the Exchange Organization container in Active Directory during installation.

NOTE
If you haven't prepared the Active Directory schema for Exchange 2013, the logged-on user must also be a member of the
Schema Admins Windows security group. Alternately, another user who's a member of the Schema Admins Windows group
can prepare the Active Directory schema before Exchange 2013 is installed.

To resolve this issue, add the logged-on user as a member of the Enterprise Admins security group. Or, log on to
an account that's a member of the Enterprise Admins security group. Then run Exchange 2013 Setup again.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation of the first Exchange server in the
organization can't be delegated
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to install the first Exchange 2013 server in the organization.
Although Exchange 2013 Setup allows using delegation to install successive server roles, Setup requires that the
user who is logged on is a member of the Enterprise Admins Windows security group when the first Exchange
2013 server in the organization is installed. This is required because Exchange 2013 Setup creates and configures
objects in the Exchange Organization container in Active Directory during installation.

NOTE
If you haven't prepared the Active Directory schema for Exchange 2013, the logged-on user must also be a member of the
Schema Admins Windows security group. Alternately, another user who's a member of the Schema Admins Windows group
can prepare the Active Directory schema before Exchange 2013 is installed.

To resolve this issue, add the logged-on user as a member of the Enterprise Admins security group. Or, log on to
an account that's a member of the Enterprise Admins security group. Then run Exchange 2013 Setup again.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation of the first Exchange server in the
organization can't be delegated
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to install the first Exchange 2013 server in the organization.
Although Exchange 2013 Setup allows using delegation to install successive server roles, Setup requires that the
user who is logged on is a member of the Enterprise Admins Windows security group when the first Exchange
2013 server in the organization is installed. This is required because Exchange 2013 Setup creates and configures
objects in the Exchange Organization container in Active Directory during installation.

NOTE
If you haven't prepared the Active Directory schema for Exchange 2013, the logged-on user must also be a member of the
Schema Admins Windows security group. Alternately, another user who's a member of the Schema Admins Windows group
can prepare the Active Directory schema before Exchange 2013 is installed.

To resolve this issue, add the logged-on user as a member of the Enterprise Admins security group. Or, log on to
an account that's a member of the Enterprise Admins security group. Then run Exchange 2013 Setup again.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Active Directory functional level isn't Windows Server
2003 or later
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected that the forest functional level of the
current Active Directory forest isn't Windows Server 2003 native or later. Before you can install Exchange 2013,
you must raise the forest functional level to Windows Server 2003 or later.
For information about how to raise the forest functional level of the current Active Directory forest to Windows
Server 2003 or later, see Raise the Forest Functional Level.
For more information about Active Directory functional levels, see the following topics:
What are Active Directory Functional Levels?
How Active Directory Functional Levels Work
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Cannot write to the Exchange organization container
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to write to the organization container in the Active Directory directory service.
Setup requires that the user who is logged on when Exchange 2013 is installed has permission to create and
modify objects in Active Directory. If you're running Exchange 2013 Setup in your organization for the first time,
the account you use must be a member of the Schema Admins and Enterprise Admins groups. These permissions
are required because Active Directory is prepared for Exchange 2013 the first time Setup is run. After Active
Directory is prepared, the account you use to install additional Exchange 2013 servers must be a member of the
Organization Management management role group.
To resolve this issue, grant the logged-on user the appropriate permissions, or log on with an account that has
those permissions and run Exchange 2013 Setup again.

IMPORTANT
Cross-forest installation of Exchange 2013 isn't supported. Use an account that is a member of the Active Directory forest
where you're installing Exchange 2013.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Global updates required
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to make global updates to Active Directory.
Setup requires that the user who is logged on when Exchange 2013 is installed has permission to create and
modify objects in Active Directory. If you're running Exchange 2013 Setup in your organization for the first time,
the account you use must be a member of the Schema Admins and Enterprise Admins groups. These permissions
are required because Active Directory is prepared for Exchange 2013 the first time Setup is run. After Active
Directory is prepared, the account you use to install additional Exchange 2013 servers must be a member of the
Organization Management management role group.
To resolve this issue, grant the logged-on user the appropriate permissions, or log on with an account that has
those permissions and run Exchange 2013 Setup again.

IMPORTANT
Cross-forest installation of Exchange 2013 isn't supported. Use an account that is a member of the Active Directory forest
where you're installing Exchange 2013.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 The Host record for the local computer cannot be
found in the DNS database
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the Host (A) record for this computer can't be found
in the Domain Name System (DNS ) database.
Exchange 2013 Setup requires that the local computer have a valid HOST (A) record registered with the
authoritative DNS database for the domain.
Exchange depends on DNS Host (A) records for the IP Address of its next internal or external destination server.
To resolve this issue:
Verify that the local TCP/IP configuration points to the correct DNS server. For more information, see
Configure TCP/IP settings.
Use Nslookup.exe to verify that the Host (A) record exists on the DNS server. For more information, see To
verify A resource records exist in DNS.
For information about DNS name resolution, troubleshooting, and Host (A) records, see the following:
Troubleshooting DNS
Managing resource records
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation on domain controllers is not supported
with Active Directory split permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup has detected that you're attempting to run Setup on an Active Directory
domain controller and one of the following is true:
The Exchange organization is already configured for Active Directory split permissions.
You selected the Active Directory split permissions option in Exchange 2013 Setup.
The installation of Exchange 2013 on domain controllers isn't supported when the Exchange organization is
configured for Active Directory split permissions.
If you want to install Exchange 2013 on a domain controller, you must configure the Exchange organization for
Role Based Access Control (RBAC ) split permissions or shared permissions.

IMPORTANT
We don't recommend installing Exchange 2013 on Active Directory domain controllers. For more information, see Installing
Exchange on a domain controller is not recommended.

If you want to continue using Active Directory split permissions, you must install Exchange 2013 on a member
server.
For more information about split and shared permissions in Exchange 2013, see the following topics:
Understanding split permissions
Configure Exchange 2013 for split permissions
Configure Exchange 2013 for shared permissions
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 The current account isn't logged into an Active
Directory domain
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected that the current account isn't logged on
to an Active Directory domain. You must log in using an Active Directory account that has the permissions required
to install Exchange Server 2013.
Setup requires that the user who is logged on when Exchange 2013 is installed has permission to create and
modify objects in Active Directory. If you're running Exchange 2013 Setup in your organization for the first time,
the account you use must be a member of the Schema Admins and Enterprise Admins groups. These permissions
are required because Active Directory is prepared for Exchange 2013 the first time Setup is run. After Active
Directory is prepared, the account you use to install additional Exchange 2013 servers must be a member of the
Organization Management management role group.
To resolve this issue, grant the logged-on user the appropriate permissions, or log on with an account that has
those permissions and run Exchange 2013 Setup again.

IMPORTANT
Cross-forest installation of Exchange 2013 isn't supported. Use an account that is a member of the Active Directory forest
where you're installing Exchange 2013.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 The computer needs to be restarted before Setup can
continue
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected that the local computer needs to be
restarted to complete the installation of other programs or Windows updates.

Why is this happening?

When programs and Windows updates are installed, they make changes to files that are stored on your computer.
Sometimes, during installation, a program or Windows update needs to make a change to a file that's in use. When
this happens, you need to restart the computer before any other programs, such as Exchange 2013, can be
installed. Exchange Setup requires that all other installations have finished so it can verify that all of the
prerequisites it needs to work properly have been installed.
Sometimes, the installation of a previous program or Windows update might not complete successfully. When this
happens, it can leave behind changes that make Windows and other programs think a restart is needed.
Unfortunately, because the failed installation never cleans up these changes, the installation of Windows updates
and other programs can be blocked. You'll continue to see this error each time you run Exchange Setup if this
happens.

How do I fix it?

In most cases, you just need to restart the computer to get past this error. There are times, however, when you
might get this error again even though you've already restarted the computer. This can happen when the
installation of a program or Windows update needs to make additional changes and those changes also require
that the computer be restarted. If you see this error after you restart your computer, try restarting it again.
If you've restarted the computer more than two or three times, and you're still seeing this error, try and reinstall any
programs or Windows updates you've installed recently. This might allow a failed installation to complete
successfully.
If, after restarting your computer and reinstalling any recent programs or Windows updates, you still receive this
error, we recommend that you contact Microsoft support. They'll help you find the reason why Windows and other
programs think your computer needs to be restarted. To contact Microsoft support, go to Support for Microsoft
Exchange Server.

WARNING
Even though it can be tempting to do so, we strongly recommend that you don't attempt to work around this issue by
manually deleting or changing keys or values in the Windows Registry. While doing so might fix this issue now, it might cause
issues later on. This is especially important if the failed installation was a Windows update.
 The logged-on user is not a member of the Schema
Admins group
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the user account performing the Active Directory
schema update process isn't a member of the Schema Admins and Enterprise Admins groups.
Setup requires that the user who is logged on when Exchange 2013 is installed has permission to create and
modify objects in Active Directory. If you're running Exchange 2013 Setup in your organization for the first time,
the account you use must be a member of the Schema Admins and Enterprise Admins groups. These permissions
are required because Active Directory is prepared for Exchange 2013 the first time Setup is run. After Active
Directory is prepared, the account you use to install additional Exchange 2013 servers must be a member of the
Organization Management management role group.
To resolve this issue, grant the logged-on user the appropriate permissions, or log on with an account that has
those permissions and run Exchange 2013 Setup again.

IMPORTANT
Cross-forest installation of Exchange 2013 isn't supported. Use an account that is a member of the Active Directory forest
where you're installing Exchange 2013.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 UCMA 4.0, Core Runtime not installed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the local computer requires a software update.
You'll need to install this update before Exchange 2013 Setup can continue.
Exchange 2013 Setup requires that the Unified Communications Managed API 4.0 Runtime update be installed on
the computer before installation can continue.
Download and install the 64-bit update from the following URL, and then click retry on the Readiness Checks
page.

NOTE
If this update requires a reboot to complete installation, you'll need to exit Exchange 2013 Setup, reboot, and then start
Setup again.

Unified Communications Managed API 4.0 Runtime

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Cannot remove mailbox database
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it can't remove a user mailbox database from the
local server without incurring potential data loss.
Exchange 2013 Setup determines whether all mailbox databases have been removed from the server before the
Mailbox server role is removed. However, user mailboxes might still remain on the server.
To resolve this issue, move any mailboxes on the server to another Exchange server or, if the mailboxes and the
data contained within them are no longer required, disable the mailboxes. Then run Exchange 2013 Setup again.
For more information about how to identify a mailbox in the database, see Get-Mailbox.
For more information about how to move a mailbox, see Mailbox moves in Exchange 2013.
For more information about how to disable a mailbox, see Disable-Mailbox.
For more information about how to remove a mailbox database, see Manage mailbox databases in
Exchange 2013.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installing Exchange on a domain controller is not
recommended
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup has detected that the computer you're attempting to install Exchange 2013
on is an Active Directory domain controller. Installing Exchange 2013 on a domain controller isn't recommended.
If you install Exchange 2013 on a domain controller, be aware of the following issues:
Configuring Exchange 2013 for Active Directory split permissions isn't supported.
The Exchange Trusted Subsystem universal security group (USG ) is added to the Domain Admins group
when Exchange is installed on a domain controller. When this occurs, all Exchange servers in the domain are
granted domain administrator rights in that domain.
Exchange Server and Active Directory are both resource-intensive applications. There are performance
implications to be considered when both are running on the same computer.
You must make sure that the domain controller Exchange 2013 is installed on is a global catalog server.
Exchange services may not start correctly when the domain controller is also a global catalog server.
System shutdown will take considerably longer if Exchange services aren't stopped before shutting down or
restarting the server.
Demoting a domain controller to a member server isn't supported.
Running Exchange 2013 on a clustered node that is also an Active Directory domain controller isn't
supported.
We recommend that you install Exchange 2013 on a member server.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 KB2619234 update not installed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the local computer requires a software update.
You'll need to install this update before Exchange 2013 Setup can continue.
Exchange 2013 Setup requires an update to Windows that allows Outlook Anywhere (formerly known as RPC
over HTTP ) to work correctly.
Download and install the 64-bit update from the following URL, and then click retry on the Readiness Checks
page.

NOTE
If this update requires a reboot to complete installation, you'll need to exit Exchange 2013 Setup, reboot, and then start
Setup again.

Microsoft Knowledge Base article KB2619234, A hotfix is available to enable the Association Cookie/GUID that is
used by RPC over HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2)
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Installation of the first Exchange server in the
organization can't be delegated
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the logged-on user doesn't have the account
permissions that are required to install the first Exchange 2013 server in the organization.
Although Exchange 2013 Setup allows using delegation to install successive server roles, Setup requires that the
user who is logged on is a member of the Enterprise Admins Windows security group when the first Exchange
2013 server in the organization is installed. This is required because Exchange 2013 Setup creates and configures
objects in the Exchange Organization container in Active Directory during installation.

NOTE
If you haven't prepared the Active Directory schema for Exchange 2013, the logged-on user must also be a member of the
Schema Admins Windows security group. Alternately, another user who's a member of the Schema Admins Windows group
can prepare the Active Directory schema before Exchange 2013 is installed.

To resolve this issue, add the logged-on user as a member of the Enterprise Admins security group. Or, log on to
an account that's a member of the Enterprise Admins security group. Then run Exchange 2013 Setup again.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 No Exchange 2010 or Exchange 2007 servers detected
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup displayed this warning because no Exchange Server 2010 or Exchange
Server 2007 server roles exist in the organization.

WARNING
If you continue with Exchange Server 2013 installation, you won't be able to add Exchange 2010 or Exchange 2007 servers to
the organization at a future date.

Before deploying Exchange 2013, consider the following factors that may require you to deploy Exchange 2010 or
Exchange 2007 servers prior to deploying Exchange 2013:
Third-party or in-house developed applications: Applications developed for earlier versions of
Exchange may not be compatible with Exchange 2013. You may need to maintain Exchange 2010 or
Exchange 2007 servers to support these applications.
Coexistence or migration requirements: If you plan on migrating mailboxes into your organization,
some solutions may require the use of Exchange 2010 or Exchange 2007 servers.
If you decide that you need to deploy Exchange 2010 or Exchange 2007 servers, you must do so before you deploy
Exchange 2013. Active Directory must be prepared for each Exchange version in the following order:
1. Exchange 2007
2. Exchange 2010
3. Exchange 2013
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 The computer needs to be restarted before Setup can
continue
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected that the local computer needs to be
restarted to complete the installation of other programs or Windows updates.

Why is this happening?

When programs and Windows updates are installed, they make changes to files that are stored on your computer.
Sometimes, during installation, a program or Windows update needs to make a change to a file that's in use. When
this happens, you need to restart the computer before any other programs, such as Exchange 2013, can be
installed. Exchange Setup requires that all other installations have finished so it can verify that all of the
prerequisites it needs to work properly have been installed.
Sometimes, the installation of a previous program or Windows update might not complete successfully. When this
happens, it can leave behind changes that make Windows and other programs think a restart is needed.
Unfortunately, because the failed installation never cleans up these changes, the installation of Windows updates
and other programs can be blocked. You'll continue to see this error each time you run Exchange Setup if this
happens.

How do I fix it?

In most cases, you just need to restart the computer to get past this error. There are times, however, when you
might get this error again even though you've already restarted the computer. This can happen when the
installation of a program or Windows update needs to make additional changes and those changes also require
that the computer be restarted. If you see this error after you restart your computer, try restarting it again.
If you've restarted the computer more than two or three times, and you're still seeing this error, try and reinstall any
programs or Windows updates you've installed recently. This might allow a failed installation to complete
successfully.
If, after restarting your computer and reinstalling any recent programs or Windows updates, you still receive this
error, we recommend that you contact Microsoft support. They'll help you find the reason why Windows and other
programs think your computer needs to be restarted. To contact Microsoft support, go to Support for Microsoft
Exchange Server.

WARNING
Even though it can be tempting to do so, we strongly recommend that you don't attempt to work around this issue by
manually deleting or changing keys or values in the Windows Registry. While doing so might fix this issue now, it might cause
issues later on. This is especially important if the failed installation was a Windows update.
 Exchange 2007 servers must be upgraded to Service
Pack 3, Update Rollup 10
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected one or more Exchange Server 2007
servers haven't been upgraded to Exchange Server 2007 Service Pack 3 (SP3) Roll Up 10 (RU10). Before you can
install Exchange 2013, all Exchange 2007 servers in your organization must be upgraded to Exchange 2007 SP3
RU10. This requirement includes Exchange 2007 Edge Transport servers. For more information, see Upgrade from
Exchange 2007 to Exchange 2013.

IMPORTANT
After you upgrade your Exchange 2007 Edge Transport servers to Exchange 2007 SP3 RU10, you must re-create the Edge
subscription between your Exchange organization and each Edge Transport server to update their server version in Active
Directory. For more information about re-creating Edge subscriptions in Exchange 2007, see Subscribing the Edge Transport
Server to the Exchange Organization.
 Exchange 2010 servers must be upgraded to Service
Pack 3
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected one or more Microsoft Exchange Server
2010 servers haven't been upgraded to Service Pack 3 (SP3) for Exchange Server 2010. Before you can install
Exchange 2013, all Exchange 2010 servers in your organization must be upgraded to Exchange 2010 SP3. This
requirement includes Exchange 2010 Edge Transport servers. For more information, see Upgrade from Exchange
2010 to Exchange 2013.

IMPORTANT
After you upgrade your Exchange 2010 Edge Transport servers to Exchange 2010 SP3, you must re-create the Edge
subscription between your Exchange organization and each Edge Transport server to update their server version in Active
Directory. For more information about re-creating Edge subscriptions in Exchange 2010, see Managing Edge Subscriptions.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Office 2010 Filter Pack not installed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the local computer requires a software update.
You'll need to install this update before Exchange 2013 Setup can continue.
Exchange 2013 Setup requires that the Microsoft Office 2010 Filter Pack update be installed on the computer
before installation can continue.
Download and install the 64-bit update from the following URL, and then click retry on the Readiness Checks
page.

NOTE
If this update requires a reboot to complete installation, you'll need to exit Exchange 2013 Setup, reboot, and then start
Setup again.

Microsoft Office 2010 Filter Packs

NOTE
You must also install the Microsoft Office 2010 Filter Pack Service Pack 1 64-bit update. For more information, see Office
2010 Filter Pack SP1 not installed.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Office 2010 Filter Pack SP1 not installed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the local computer requires a software update.
You'll need to install this update before Exchange 2013 Setup can continue.
Exchange 2013 Setup requires that the Microsoft Office 2010 Filter Pack Service Pack 1 update be installed on the
computer before installation can continue.
Download and install the 64-bit update from the following URL, and then click retry on the Readiness Checks
page.

NOTE
If this update requires a reboot to complete installation, you'll need to exit Exchange 2013 Setup, reboot, and then start
Setup again.

Service Pack 1 for Microsoft Office Filter Pack 2010 (KB2460041) 64-bit Edition
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Can't install Exchange 2013 in a forest containing
Exchange 2000 or Exchange 2003 servers.
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 can't continue because one or more computers running Exchange 2000 Server or
Exchange Server 2003 were found in the Active Directory forest. Before you can install Exchange 2013, all
Exchange 2000 and Exchange 2003 servers must be removed from the forest. Mailboxes, public folders, and all
other Exchange objects or components must be upgraded to either Exchange Server 2007 or Exchange Server
2010. You can't upgrade from Exchange 2000 or Exchange 2003 directly to Exchange 2013.
The path you need to follow to install Exchange 2013 in your organization depends on the version of Exchange you
currently have installed in your forest. See the following table for more information.

IF YOU HAVE THE FOLLOWING INSTALLED IN YOUR ORGANIZATION YOU MUST TAKE THIS PATH TO UPGRADE TO EXCHANGE 2013

Exchange 2000 1. Install Exchange 2007 into your Exchange 2000

organization.
2. Configure Exchange 2007 and Exchange 2000
coexistence.
3. Migrate Exchange 2000 mailboxes, public folders,
and other components to Exchange 2007.
4. Decommission and remove all Exchange 2000
servers.
5. Install Exchange 2013 into your Exchange 2007
organization.
6. Configure Exchange 2013 and Exchange 2007
coexistence.
7. Migrate Exchange 2007 mailboxes, public folders,
and other components to Exchange 2013.
8. Decommission and remove all Exchange 2007
servers.
For more information, see Upgrading to Exchange 2007
and Upgrade from Exchange 2007 to Exchange 2013.
 IF YOU HAVE THE FOLLOWING INSTALLED IN YOUR ORGANIZATION YOU MUST TAKE THIS PATH TO UPGRADE TO EXCHANGE 2013

Exchange 2003 1. Install Exchange 2010 into your Exchange 2003

organization.
2. Configure Exchange 2010 and Exchange 2003
coexistence.
3. Migrate Exchange 2003 mailboxes, public folders,
and other components to Exchange 2010.
4. Decommission and remove all Exchange 2003
servers.
5. Install Exchange 2013 into your Exchange 2010
organization.
6. Configure Exchange 2013 and Exchange 2010
coexistence.
7. Migrate Exchange 2010 mailboxes, public folders,
and other components to Exchange 2013.
8. Decommission and remove all Exchange 2010
servers.
For more information, see Exchange 2003 - Planning
Roadmap for Upgrade and Coexistence and Upgrade from
Exchange 2010 to Exchange 2013.

When upgrading to Exchange 2010 or Exchange 2013, you can use the Exchange Deployment Assistant to help
you complete your deployment. For more information, see the following links:
Exchange 2010 Deployment Assistant
Exchange 2013 Deployment Assistant
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 An incompatible operating system was found
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected an incompatible operating system. You
must install a compatible operating system on this computer before you install Exchange 2013. The following table
shows the operating systems that are compatible with Exchange 2013.

IMPORTANT
Exchange 2013 doesn't support the Server Core installation option of Windows Server 2008 R2, Windows Server 2012, or
Windows Server 2012 R2.

Supported operating systems for Exchange 2013

COMPONENT REQUIREMENT

Mailbox, Client Access, and Edge Transport server roles One of the following:
Windows Server 2012 R2 Standard or Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard with Service
Pack 1 (SP1)
Windows Server 2008 R2 Enterprise with Service
Pack 1 (SP1)
Windows Server 2008 R2 Datacenter RTM or later

Management tools One of the following:

Windows Server 2012 R2 Standard or Datacenter1
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard with SP1
Windows Server 2008 R2 Enterprise with SP1
Windows Server 2008 R2 Datacenter RTM or later
64-bit edition of Windows 8.12
64-bit edition of Windows 8
64-bit edition of Windows 7 with Service Pack 1

1 Windows Server 2012 R2 is supported only with Exchange 2013 SP1 or later.
2 Windows 8.1 is supported only with Exchange 2013 SP1 or later.
For more information, see Exchange 2013 system requirements.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Exchange 2010 servers must be upgraded to Service
Pack 3
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected one or more Microsoft Exchange Server
2010 servers haven't been upgraded to Service Pack 3 (SP3) for Exchange Server 2010. Before you can install
Exchange 2013, all Exchange 2010 servers in your organization must be upgraded to Exchange 2010 SP3. This
requirement includes Exchange 2010 Edge Transport servers. For more information, see Upgrade from Exchange
2010 to Exchange 2013.

IMPORTANT
After you upgrade your Exchange 2010 Edge Transport servers to Exchange 2010 SP3, you must re-create the Edge
subscription between your Exchange organization and each Edge Transport server to update their server version in Active
Directory. For more information about re-creating Edge subscriptions in Exchange 2010, see Managing Edge Subscriptions.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 ExecutionPolicy GPO is defined
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because it detected that the ExecutionPolicy Group Policy
Object (GPO ) defines one or both of the following policies:
MachinePolicy
UserPolicy
It doesn't matter how the policies have been defined. It only matters that they have been defined.
When you run Exchange 2013 Setup, Exchange stops and disables the Windows Management Instrumentation
(WMI) service. When either of these policies are defined, the WMI service needs to be enabled to run a Windows
PowerShell script. If the policies are defined and the WMI service is stopped, Setup will fail and the server will be
left in an inconsistent state.
To allow Setup to continue, you need to temporarily remove any definition of MachinePolicy or UserPolicy in
the ExecutionPolicy GPO.
For information on how to remove any definitions of MachinePolicy or UserPolicy in the ExecutionPolicy
GPO, see Knowledge Base article KB981474.

NOTE
Even though this Knowledge Base article was written for Exchange 2010, it also applies to Exchange 2013 cumulative updates
and service packs.

Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 Primary DNS Suffix is missing
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup can't continue because the primary domain name system (DNS ) suffix for
the computer you're installing Exchange on hasn't been configured.
To resolve this issue, add a primary DNS suffix on the computer using the steps below and then run Setup again.

IMPORTANT
Changing the computer name or primary DNS suffix after you install Exchange 2013 isn't supported.

1. Log on to the computer where you want to install the Edge Transport role as a user that's a member of the
local Administrators group.
2. Open the Control Panel and then double-click System.
3. In the Computer name, domain, and workgroup settings section, click Change settings.
4. In the System Properties window, make sure the Computer Name tab is selected and then click
Change....
5. In Computer Name/Domain Changes, click More....
6. In Primary DNS suffix of this computer, enter the DNS domain name for the Edge Transport server. For
example, contoso.com.
7. Click OK to close each window.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Did you find what you're looking for? Please take a minute to send us feedback about the information you were
hoping to find.
 The Simple Mail Transport Protocol is currently
installed_SMTPSvcInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the Microsoft Windows Server™ 2003 Simple
Mail Transfer Protocol (SMTP ) service is installed on this computer.
Microsoft Exchange setup requires that the SMTP service not be installed on servers that are used for
Exchange 2007.
To resolve this issue, uninstall the SMTP service and rerun Microsoft Exchange setup.
To uninstall the SMTP service by using Add or Remove a Windows Component in Control Panel
1. On the Start menu, click Control Panel.
2. Double-click Add or Remove Programs.
3. Click Add/Remove Windows Components.
4. In the Components list, select the Application Server check box and then click Details.
5. Select Internet Information Services Manager and then click Details.
6. Select SMTP Service and then click to clear the check box.
7. Click OK two times to return to the Components list and then click Next.
8. Click Finish when the SMTP service is uninstalled.
 SMTP Addressing Format Not
Supported_SMTPAddressLiteral
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 and Exchange Server 2010 setup cannot continue because the specified recipient
policy uses an unsupported Simple Mail Transfer Protocol (SMTP ) address format.
Exchange 2007 and Exchange 2010 setup requires that all SMTP addresses used for e-mail address policies not
contain IP address literals, for example: user@[10.10.1.1 ].
To resolve this issue, change the value of the SMTP address in the recipient policy so that it does not contain an IP
address literal. Replace brackets ([]) and numbers (10.10.1.1) of the IP address literal with the Domain Name
System (DNS ) naming format, for example: *[email protected]*, and then rerun Exchange setup.
For more information about managing recipient policies in Exchange Server 2007, see "Managing E -Mail Address
Policies" (https://go.microsoft.com/fwlink/?LinkId=86653).
For more information about managing recipient policies in Exchange Server 2010, see "Managing E -Mail Address
Policies" (https://go.microsoft.com/fwlink/?LinkId=179519).
 The World Wide Web Publishing Service is disabled
or missing_ShouldReRunSetupForW3SVC
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install the Mailbox Server or
Client Access role found that the World Wide Web Publishing Service is either disabled or not installed on this
computer.
Exchange 2007 setup requires the computer that you are installing Microsoft Exchange to have the World Wide
Web Publishing Service installed and set to something other than disabled.
To resolve this issue, verify that the World Wide Web Publishing service is installed and not disabled on the local
computer, and then rerun Microsoft Exchange setup.
To verify that the World Wide Web Publishing Service is installed and not disabled
1. Right-click My Computer on the desktop, and then click Manage.
2. Expand the Services and Applications node, and then click the Services node.
3. In the right pane, locate the World Wide Web Publishing Service.
If the World Wide Web Publishing Service is not displayed in the list of services installed, follow the
steps in the procedure below to install it.
4. If the World Wide Web Publishing Service is displayed but has a status other than Started, continue
with the steps below to start it.
5. Right-click World Wide Web Publishing Service, and then click Properties.
6. Verify the Startup Type is Automatic and the Service status is set to Started.
7. Click Apply, and then click OK.
To install the World Wide Web Publishing Service
1. On the Start menu, select Settings, Control Panel, and then click Add or Remove Programs
2. Click Add/Remove Windows Components.
3. In the Components list, select the Application Server check box, and then click Details.
4. Select Internet Information Services Manager, and then click Details.
5. Select World Wide Web Service, and then select the check box.
6. Click OK two times to return to the Components list, and then click Next.
7. Click Finish when the IIS service is installed.
 This Server is the Source for a Send
Connector_ServerIsSourceForSendConnector
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because its attempt to remove the Hub Transport server
role failed. The local computer is the source for one or more Send connectors in the Exchange organization.
A Send connector represents a logical gateway through which outbound messages are sent.
Exchange 2007 setup requires that all Send connectors for an Exchange organization be moved or deleted from the
Hub Transport server computer before the server role can be deleted.
To resolve this issue, move or delete all Send connectors from the local computer and then rerun setup.
For more information about modifying or removing Send connectors, see the following topics in the Exchange
Server 2007 product documentation:
"How to Remove a Send Connector" (https://go.microsoft.com/fwlink/?LinkId=86655).
"How to Modify the Configuration of a Send Connector" (https://go.microsoft.com/fwlink/?LinkId=86656).
 The local computer is responsible for expanding
group membership_ServerIsGroupExpansionServer
6/11/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because its attempt to uninstall a Hub Transport role
responsible for expanding group membership failed.
Exchange 2007 setup requires that distribution list expansion be removed from the current Bridgehead server
before the Hub Transport role can be uninstalled.
The expansion of distribution lists enables identification of individual recipients who belong to the distribution list
to be identified, or the identification of additional distribution lists for expansion. An expanded distribution list can
return the path for any required delivery status notification (DSN ). DSNs notify the Microsoft Exchange
administrator or e-mail sender of the status of a particular e-mail message. Additionally, distribution list expansion
identifies whether Out of Office messages or automatically generated replies should be sent to the sender of the
original message.
To resolve this issue, move distribution group expansion to another server and rerun Microsoft Exchange setup.

To change the expansion server for a distribution group or dynamic

distribution group
1. Open the Exchange Management Console.
2. In the console tree, expand Recipient Configuration.
3. In the console tree, click Distribution Group.
4. Create a filter to view all distribution groups and dynamic distribution groups that use the current
Bridgehead server as an expansion server.
a. In the action pane, click Create Filter.
b. In the property drop-down list, click Expansion Server.
c. In the operator drop-down list, click Equals.
d. At the value box, click the Browse button to select the Bridgehead server that currently acting as the
expansion server.

NOTE
The following step is optional.

5. Click Add Expression to specify additional filter criteria. Only messages that meet all filter criteria will be
displayed.
 6. Click Apply Filter. The results that meet the filter criteria are displayed.
7. In the results pane, click the distribution group you want to change the expansion server for, and then click
Properties in the action pane.
8. On Properties, click the Advanced tab.
9. In the Expansion server drop-down list, select a specific server from the list or select Any server in the
organization.
10. Repeat steps 5 through 7 for all distribution groups or for dynamic distribution groups that are using the
Bridgehead server as their expansion server.
2 minutes to read
2 minutes to read
 Older database files present_SecondSGFilesExist
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because it detected existing Microsoft Exchange
database files in the target installation path.
Exchange 2007 setup requires that the target installation path be empty of Microsoft Exchange database files.
To resolve this issue, remove all existing files from target installation paths and then rerun setup.
To delete existing Exchange Server database files from the target installation path
1. In My Computer or Windows Explorer, locate the target install path.

NOTE
By default, the database files are located in:
<systemDrive>:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group.

2. Right-click the files to be removed, and then select Delete.

3. At the Confirm File Delete dialog, click Yes.
4. Repeat steps 2 and 3 for all files in the target install paths.
2 minutes to read
 Cannot find a recipient update service_RUSMissing
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 or Exchange Server 2010 setup cannot continue because the Recipient Update
Service (RUS ) responsible for a domain in the existing Exchange organization cannot be found.
Microsoft Exchange setup requires that each domain in the existing Exchange organization have an instance of the
Recipient Update Service.
If an instance of the Recipient Update Service is missing for a domain, new user objects created in the domain will
not receive e-mail addresses issued to them.
To resolve this issue, verify that an instance of the Recipient Update Service exists for each domain and create an
instance of the Recipient Update Service for the domains that do not have one and then rerun Microsoft Exchange
setup.

To create a Recipient Update Service instance for a domain

1. Open Exchange System Manager.

2. Expand Recipients.
3. Right-click the Recipient Update Services node, click New, and then click Recipient Update Service.
4. In the New Object window, click Browse to locate the name of the domain.
5. Select the name of the domain and then click OK.
6. In the New Object window, click Next, and then Finish.

For more information about the Recipient Update Service, see the following Microsoft Knowledge Base articles:
"How the Recipient Update Service applies recipient policies" (https://go.microsoft.com/fwlink/?
linkid=3052&kbid=328738).
"How the Recipient Update Service Populates Address Lists" (https://go.microsoft.com/fwlink/?
linkid=3052&kbid=253828).
"How to check the progress of the Exchange Recipient Update Service" (https://go.microsoft.com/fwlink/?
linkid=3052&kbid=246127).
"Tasks performed by the Exchange Recipient Update Service" (https://go.microsoft.com/fwlink/?
linkid=3052&kbid=253770).
 Active Directory domain is mixed
mode_RootDomainModeMixed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because an existing Active Directory domain is not set to
Microsoft Windows®°2000 Server native mode or better.
Exchange 2007 setup will create Universal Security Groups that can only exist in Windows 2000 Server native
mode, or better, domains.
To resolve this issue, follow these steps to raise the domain functional level to at least the Windows 2000 Server
native level, and then rerun Exchange 2007 setup.
To raise the domain functional level
1. Open Active Directory Domains and Trusts.
2. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise
Domain Functional Level.
3. In Select an available domain functional level, use one of the following procedures:
To raise the domain functional level to Windows 2000 Server native, click Windows 2000 native,
and then click Raise.
To raise domain functional level to Windows Server® 2003, click Windows Server 2003, and then
click Raise.

WARNING

If you have or will have any domain controllers running Windows NT® 4.0 and earlier, do not raise the domain functional
level to Windows 2000 Server native. After the domain functional level is set to Windows 2000 Server native, it cannot be
changed back to Windows 2000 Server mixed.
If you have or will have any domain controllers running Windows NT 4.0 and earlier or Windows 2000 Server, do not raise
the domain functional level to Windows Server 2003. After the domain functional level is set to Windows Server 2003, it
cannot be changed back to Windows 2000 Server mixed or Windows 2000 Server native.
 The primary DNS server cannot be
contacted_PrimaryDNSTestFailed
6/11/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because communication with the primary Domain Name
System (DNS ) server cannot be established.
Exchange 2007 setup requires that the local computer communicate with the authoritative DNS database for the
domain.
Microsoft Exchange depends on DNS to resolve the IP Address of its next internal or external destination server.
Communication with the primary DNS server can fail for the following reasons:
The local TCP/IP configuration does not point to the correct DNS server.
The DNS server is down or unreachable because of a network failure or other reasons.
To resolve this issue, verify that the local TCP/IP configuration points to the correct DNS server.

To verify the local TCP/IP configuration

1. Review the local TCP/IP configuration. For more information, see Configure TCP/IP to use DNS.
2. Verify that the DNS server is running and can be contacted.

To verify that the DNS server is running and can be contacted

Verify that the DNS server is running by doing one or more of the following checks:
Look at the DNS server status from the DNS Administration program on the DNS server.
Restart the DNS server. For more information, see Start, stop, pause, or restart a DNS server .
Verify the DNS server responsiveness by using the nslookup command. For more information, see the
instructions in Verify DNS server responsiveness using the nslookup command.
 Insufficient permissions to run
/PrepareDomain_PrepareDomainNotAdmin
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the attempt to run the /PrepareDomain process
failed. The logged on user has insufficient permissions to perform the /PrepareDomain process.
Exchange 2007 setup requires that the user who is logged on when running the /PrepareDomain process be a
member of the Domain Admins group for the domain to be prepared, and a member of the Enterprise Admins
group.
To resolve this issue, grant the logged-on user Domain Admins group permissions for the domain being prepared
and enroll them in the Enterprise Admins groups, or log on with an account that has those permissions and rerun
Exchange 2007 setup.
For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working
with Active Directory Permissions in Exchange Server" (https://go.microsoft.com/fwlink/?LinkId=47592).
 Active Directory domain is mixed
mode_PrepareDomainModeMixed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because an existing Active Directory domain is not set to
Microsoft Windows®°2000 Server native mode or better.
Exchange 2007 setup will create Universal Security Groups that can only exist in Windows 2000 Server native
mode, or better, domains.
To resolve this issue, follow these steps to raise the domain functional level to at least the Windows 2000 Server
native level, and then rerun Exchange 2007 setup.
To raise the domain functional level
1. Open Active Directory Domains and Trusts.
2. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise
Domain Functional Level.
3. In Select an available domain functional level, use one of the following procedures:
To raise the domain functional level to Windows 2000 Server native, click Windows 2000 native,
and then click Raise.
To raise domain functional level to Windows Server® 2003, click Windows Server 2003, and then
click Raise.

WARNING

If you have or will have any domain controllers running Windows NT® 4.0 and earlier, do not raise the domain functional
level to Windows 2000 Server native. After the domain functional level is set to Windows 2000 Server native, it cannot be
changed back to Windows 2000 Server mixed.
If you have or will have any domain controllers running Windows NT 4.0 and earlier or Windows 2000 Server, do not raise
the domain functional level to Windows Server 2003. After the domain functional level is set to Windows Server 2003, it
cannot be changed back to Windows 2000 Server mixed or Windows 2000 Server native.
 The operating system is in debug
mode_OSCheckedBuild
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
The Microsoft® Exchange Server Analyzer Tool queries the Win32_OperatingSystem Microsoft Windows®
Management Instrumentation (WMI) class to determine whether a value is set for the Debug property. If the value
for this key on an Exchange Server computer is set to True, an error is displayed.
Windows debug mode is toggled by adding the /debug parameter in the Boot.ini file. When /debug is specified in
the Boot.ini file of a Windows Server computer, the kernel debugger is loaded during startup and kept in memory
at all times. This enables a support professional to dial in to the system being debugged and break in to the
debugger, even when the system is not suspended at a Kernel STOP screen. Unlike the /crashdebug switch, the
/debug switch uses the COM port whether you are debugging or not. This switch is used when debugging
problems that are regularly reproducible. It is likely that the /debug parameter was set as a means to troubleshoot
a problem, and was unintentionally left set.
Because of the additional processes that are being run, performance suffers greatly. Therefore, running Exchange
Server on a computer where Windows is running in debug mode is not recommended.
To eliminate this error, edit the Boot.ini file and remove the /debug parameter.

To correct this error

1. In Windows Explorer, navigate to the System Partition. This is the partition that holds the hardware specific
files such as Boot.ini and NTLDR.
2. If you cannot see the Boot.ini file, it could be because the Folder Options are set to Hide protected
operating system files. If this is the case, in the Windows Explorer window, click Tools, click Folder
Options, and then click View. Clear the Hide protected operating system files (Recommended) check
box. When prompted, click Yes.
3. When the Boot.ini file is visible in Windows Explorer, right-click the file, click Open With, and then select
Notepad to open the file.
4. In the [Operating Systems] section, remove the /debug parameter.
5. Save and close the file, and then restart the Exchange Server computer for the change to take effect.
For more information about the parameters that can be used in the Boot.ini file, see the Microsoft Knowledge Base
article 833721, "Available switch options for the Windows XP and Windows Server 2003 Boot.ini files"
(https://go.microsoft.com/fwlink/?linkid=3052&kbid=833721).
 The logged-on user is not a member of the local
Administrators group_NotLocalAdmin
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the logged-on user is not a member of the local
computer's administrators group.
Exchange 2007 setup requires that the logged-on user who installs Microsoft Exchange has full access to the local
computer.
To resolve this issue, log on to the computer by using an account that has local administrator access and then rerun
Microsoft Exchange setup.
 Not in schema master
site/domain_NotInSchemaMasterSite
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the computer that is running setup is not in the
same Active Directory® directory service site or domain as the server that is assigned the domain schema master
role, also known as flexible single master operations or FSMO.
Exchange 2007 setup requires the domain controller that serves as the domain schema master to be in the same
site and domain as the local computer that is running Exchange setup.
The domain schema master controls all updates and modifications to the Active Directory schema.
To resolve this issue, run Exchange Server 2007 setup using the /prepareschema and /prepareAD switches from
the same site and domain as the domain schema master.
For more information about the /prepareschema and /prepareAD setup switches, see the Exchange 2007
product documentation topic "How to Prepare Active Directory and Domains" (https://go.microsoft.com/fwlink/?
linkid=78453)
You can use the Schema Master tool to identify the role. However, the Schmmgmt.dll DLL must be registered in
order to make the Schema tool available as an MMC snap-in.
To view the current schema master
1. At a command prompt, type regsvr32 schmmgmt.dll

NOTE
RegSvr32 has been successfully registered when the following dialog box is displayed:
DllRegisterServer in schmmgmt.dll succeeded.

2. To open a new management console, click Start, click Run, and then type mmc.
3. On the Console menu, click Add/Remove Snap-in.
4. Click Add to open the Add Standalone Snap-in dialog box.
5. Select Active Directory Schema, and then click Add.
6. "Active Directory Schema" is displayed in the Add/Remove snap-in. Click Close, and then click OK to return
to the console.
7. Select Active Directory Schema so that the Classes and Attributes sections are displayed on the right
side.
8. Right-click Active Directory Schema and then click Operations Master.
9. The current schema master is displayed
After you identify the current schema master, determine which subnet the schema master is located in. Then, use
one of the following methods to install Exchange:
Modify the subnet on the Exchange server to move it into the site in which the schema master is located.
Then, install Exchange.
Temporarily force a site membership change on the Exchange server, and then install Exchange. After
Exchange is installed, return the Exchange server to its original site.
To force site membership
1. On the server on which you want to install Exchange, start Registry Editor. To do this, click Start, click Run,
type regedit, and then click OK.
2. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Create the following new String value:
Value name: SiteName
Value type: REG_SZ
Value data: <site_that_contains_the_schema_master>
4. Exit Registry Editor, and then restart the Netlogon service. This action forces the Exchange server to
participate in the site that you specified.
5. Install Exchange.
6. Remove the registry entry that you added in step 3.
7. Restart the Netlogon service. This action returns Exchange to the original site.
 Not in schema master
site/domain_NotInSchemaMasterDomain
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the computer that is running setup is not in the
same Active Directory® directory service site or domain as the server that is assigned the domain schema master
role, also known as flexible single master operations or FSMO.
Exchange 2007 setup requires the domain controller that serves as the domain schema master to be in the same
site and domain as the local computer that is running Exchange setup.
The domain schema master controls all updates and modifications to the Active Directory schema.
To resolve this issue, run Exchange Server 2007 setup using the /prepareschema and /prepareAD switches from
the same site and domain as the domain schema master.
For more information about the /prepareschema and /prepareAD setup switches, see the Exchange 2007
product documentation topic "How to Prepare Active Directory and Domains" (https://go.microsoft.com/fwlink/?
linkid=78453)
You can use the Schema Master tool to identify the role. However, the Schmmgmt.dll DLL must be registered in
order to make the Schema tool available as an MMC snap-in.
To view the current schema master
1. At a command prompt, type regsvr32 schmmgmt.dll

NOTE
RegSvr32 has been successfully registered when the following dialog box is displayed:
DllRegisterServer in schmmgmt.dll succeeded.

2. To open a new management console, click Start, click Run, and then type mmc.
3. On the Console menu, click Add/Remove Snap-in.
4. Click Add to open the Add Standalone Snap-in dialog box.
5. Select Active Directory Schema, and then click Add.
6. "Active Directory Schema" is displayed in the Add/Remove snap-in. Click Close, and then click OK to return
to the console.
7. Select Active Directory Schema so that the Classes and Attributes sections are displayed on the right
side.
8. Right-click Active Directory Schema and then click Operations Master.
9. The current schema master is displayed
After you identify the current schema master, determine which subnet the schema master is located in. Then, use
one of the following methods to install Exchange:
Modify the subnet on the Exchange server to move it into the site in which the schema master is located.
Then, install Exchange.
Temporarily force a site membership change on the Exchange server, and then install Exchange. After
Exchange is installed, return the Exchange server to its original site.
To force site membership
1. On the server on which you want to install Exchange, start Registry Editor. To do this, click Start, click Run,
type regedit, and then click OK.
2. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Create the following new String value:
Value name: SiteName
Value type: REG_SZ
Value data: <site_that_contains_the_schema_master>
4. Exit Registry Editor, and then restart the Netlogon service. This action forces the Exchange server to
participate in the site that you specified.
5. Install Exchange.
6. Remove the registry entry that you added in step 3.
7. Restart the Netlogon service. This action returns Exchange to the original site.
2 minutes to read
2 minutes to read
 Messages currently exist in one or more
queues_MessagesInQueue
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup displays this warning because its attempt to uninstall a transport role
could cause data loss from a transport queue.
Exchange 2007 setup checks to make sure that the transport queues are empty before it removes the roles
associated with managing those queues.
If you remove the transport roles before delivery of messages still in the transport queues, those messages may be
held indefinitely.
To resolve this issue, inspect the referenced queues to make sure that they are empty of messages before you
continue with setup.
To view the contents of a queue
1. Open the Exchange Management Console.
2. In the console tree, click Toolbox.
3. In the result pane, click Exchange Queue Viewer.
4. In the action pane, click Open Tool.
5. In the Queue Viewer, click the Queues tab. A list of all queues on the server to which you are connected is
displayed.
6. Right-click the queue you want and select Properties to view the properties of the queue.
To view messages in a queue
1. Follow steps 1 through 4.
2. In the Queue Viewer, click the Messages tab. A list of all messages on the server to which you are
connected is displayed. To adjust the view to a single queue, click the Queues tab, double-click the queue
name, and then click the Server\Queue tab that appears.
3. To view detailed information about a message, select a message, and then click Properties in the action
pane.
 Storage group drive specification is
missing_MailboxLogDriveDoesNotExist
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 Disaster Recovery setup cannot continue because Disaster Recovery setup
cannot access the storage group database drive specification that was used in the previous installation of this
server.
Microsoft Exchange Disaster Recovery setup requires that the same storage group database drive specifications
previously used for this server be available during the restore.
To resolve this situation, configure the drives to match the original logical drive configuration and rerun Microsoft
Exchange Disaster Recovery setup.
Assign or change a drive letter
1. Open Computer Management (Local).
2. In the console tree, click Computer Management (Local), click Storage, and then click Disk
Management.
3. Right-click a partition, logical drive, or volume, and then click Change Drive Letter and Paths.
4. Use one of the following procedures:
To assign a drive letter, click Add, click the drive letter you want to use, and then click OK.
To modify a drive letter, click it, click Change, click the drive letter you want to use, and then click OK.
For more information about how to assign drive letters, see "Assign, change, or remove a drive letter"
(https://go.microsoft.com/fwlink/?LinkId=66764).
 Mailbox database drive specification is
missing_MailboxEDBDriveDoesNotExist
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 Disaster Recovery setup cannot continue because Disaster Recovery setup
cannot access the mailbox database drive specification that was used in the previous installation of this server.
Microsoft Exchange Disaster Recovery setup requires that the same mailbox database drive specifications
previously used for this server be available during the restore.
To resolve this situation, configure the drives to match the original logical drive configuration and rerun Microsoft
Exchange Disaster Recovery setup.
Assign or change a drive letter
1. Open Computer Management (Local).
2. In the console tree, click Computer Management (Local), click Storage, and then click Disk
Management.
3. Right-click a partition, logical drive, or volume, and then click Change Drive Letter and Paths.
4. Use one of the following procedures:
To assign a drive letter, click Add, click the drive letter you want to use, and then click OK.
To modify a drive letter, click it, click Change, click the drive letter you want to use, and then click OK.
For more information about how to assign drive letters, see "Assign, change, or remove a drive letter"
(https://go.microsoft.com/fwlink/?LinkId=66764).
2 minutes to read
 IIS 7 component not
installed_LonghornIIS7WindowsAuthNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2010 Setup or Microsoft Exchange Server 2007 Setup cannot install the Client Access
Server (CAS ) role or the Mailbox server role on a Microsoft Windows Server 2008-based computer or on a
Windows Server 2008 R2-based computer because the required Internet Information Server (IIS ) 7 components
are not installed.
Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the CAS role already has the following IIS 7
components installed.

REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

Dynamic Content Compression

Static Content Compression

Basic Authentication

Windows Authentication

IIS 7 Digest Authentication

ASP.NET

Client Certificate Mapping

Directory Browsing

HTTP Errors

HTTP Logging
 REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

HTTP Redirection

Tracing

ISAPI Filters

Request Monitor

Static Content

Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the Mailbox server role already has the
following IIS 7 components installed.

REQUIRED IIS 7 COMPONENTS FOR THE MAILBOX SERVER ROLE

Basic Authentication

Windows Authentication

To address this issue, follow the appropriate steps to install the required IIS 7 components on the destination
computer, and then run Microsoft Exchange Setup again.
Install the IIS 7 Components for the CAS server role by using the Windows Server 2008 Server Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Digest Authentication
Windows Authentication
5. In the Performance area, click to select the following check boxes:
Static Compression
Dynamic Compression
6. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations
Selections pane.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 7 Components for the Mailbox server role by using the Windows Server 2008 Server
Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Windows Authentication
5. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations
Selections pane.
6. Click Close to exit the Add Role Services wizard.
 IIS 7 .NET Extensibility component is
required_LonghornIIS7NetExt
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2010 Setup cannot continue because the required Internet Information Server (IIS ) 7
.NET Extensibility component is not installed on the target server.
Before Exchange 2010 can use Windows PowerShell Remoting, the IIS 7 .NET Extensibility component must be
installed on the target server.
To address this error, use Server Manager to install the IIS 7 .NET Extensibility component on this server and then
rerun Exchange 2010 setup.
Install the IIS 7 .NET Extensibility component in Windows Server 2008 or in Windows Server 2008 R2 by
using the Server Manager tool
1. Click Start, click Administrative Tools and then Server Manager.
2. In the left navigation pane, expand Roles, and then right-click Web Server (IIS ) and select Add Role
Services.
3. On the Select Role Services pane, scroll down to Application Development.
4. Select the check box under .NET Extensibility.
5. Click Next from the Select Role Services pane, and then click Install at the Confirm Installations
Selections pane.
6. Click Close to exit the Add Role Services wizard.
 Uninstall Unified Messaging Language
Packs_AdditionalUMLangPackExists
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the Unified Messaging server role upgrade failed.
Exchange setup requires that all Unified Messaging server role language packs, except the US English language
pack, be uninstalled before the Unified Messaging server role upgrade can continue.
Unified Messaging (UM ) language packs that are included with Exchange 2007 contain pre-recorded prompts,
Text-to-Speech (TTS ) conversion support for a given language.
Exchange 2007 UM language packs enable callers and Outlook Voice Access users to interact with the Unified
Messaging system in multiple languages.
The existing non-US English language packs need to be uninstalled so that new language packs can be installed.
To resolve this issue, uninstall all Unified Messaging server role language packs, except the US English language
pack, and then rerun Exchange 2007 setup.
For more information about uninstalling Unified Messaging server role language packs, see How to Remove a
Unified Messaging Language Pack from a Unified Messaging Server in the Exchange 2007 product
documentation.
 Insufficient permissions to prepare Active
Directory_ADUpdateRequired
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the attempted domain preparation failed.
Exchange setup requires that the Active Directory directory service be modified for Exchange Server 2007 before
domains in the Active Directory can be prepared.
The account being used to run the setup /PrepareAD command has insufficient permissions to execute this
command even though it appears to belong to the Enterprise Admins group. The account may have expired.
To resolve this issue, verify that the logged-on user account is valid and belongs to the Enterprise Admins group, or
log on with an account that has those permissions and rerun setup /PrepareAD.
For more information about how to perform the PrepareAD process, see "How to Prepare Active Directory and
Domains" (https://go.microsoft.com/fwlink/?LinkId=78453).
For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working
with Active Directory Permissions in Exchange Server" (https://go.microsoft.com/fwlink/?LinkId=47592).
 Hub Transport role not detected in local
site_BridgeheadRoleNotPresentInSite
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup displays this warning because an existing Hub Transport server role could
not be detected in the local Active Directory® directory service site.
You have chosen to install the Mailbox Server role before an instance of the Hub Transport role is installed in the
Active Directory site.
Exchange 2007 Hub Transport Services are deployed inside your organization's Active Directory. Hub Transport
Services handle all mail flow inside the organization, applies organizational mail flow routing rules, and are
responsible for delivering messages to a recipient's mailbox.
Users will be able to log on to their mailboxes, but mail cannot be sent or received from this mailbox server until a
Hub Transport role is installed.
 Insufficient permissions to remove all server
roles_CannotUninstallDelegatedServer
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the attempt to uninstall all server roles failed.
Exchange 2007 setup requires that the user who is logged on when uninstalling all server roles be a member of the
Exchange Organization Administrators groups, or the Enterprise Admins group.
To resolve this issue, grant the logged-on user Exchange Organization Administrator permissions or enroll them in
the Enterprise Admins group, or log on with an account that has those permissions and rerun Exchange 2007
setup.
For more information about Active Directory permissions needed with Microsoft Exchange, see "Working with
Active Directory Permissions in Exchange Server" (https://go.microsoft.com/fwlink/?LinkId=47592).
 Client Access role not detected in local
site_ClientAccessRoleNotPresentInSite
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup displayed this warning because an existing Client Access role could not
be detected in the local Active Directory® directory service site.
You have chosen to install the Mailbox Server role before an instance of the Client Access role is installed in the
Active Directory site.
The Client Access server role accepts connections to your Exchange 2007 server from a variety of different clients.
Software clients such as Microsoft Outlook Express and Eudora use POP3 or IMAP4 connections to communicate
with the Exchange server. Hardware clients, such as mobile devices, use ActiveSync, POP3, or IMAP4 to
communicate with the Exchange server.
If users access their Inbox by using any client other than Microsoft Office Outlook®, you must install the Client
Access server role in your Exchange organization.
Users will be able to logon to their mailboxes with Outlook but will not be able to use Outlook Web Access or
mobile devices against the same mailbox until a Client Access role is present in the local Active Directory site.
 Only the Mailbox role can be installed on a cluster
server_ClusSvcInstalledRoleBlock
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install a role other than the
Mailbox Server role on this clustered server failed.
Microsoft Exchange does not support Exchange 2007 roles other than the Mailbox Server role on servers that have
the Cluster service installed.
To address this issue, see "High Availability for Exchange 2007" in the Exchange Server 2007 Operations Guide
(https://go.microsoft.com/fwlink/?LinkId=68190).
 Setup cannot install Exchange to a read-only domain
controller_ComputerRODC
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 Setup cannot continue the installation because the target computer is a Read-
Only Domain Controller (RODC ).
Read-Only Domain Controllers are a feature of Windows Server 2008 Active Directory. The RODC is a type of
domain controller install option that can be installed in remote sites that may have lower levels of physical security.
Exchange Setup requires write access to the target install computer.
To resolve this issue, select a target install computer that is not designated as an RODC, and rerun Setup.
 Domain Controller Override is set in the
Registry_ConfigDCHostNameMismatch
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because its attempt to use the specified domain controller
failed. A domain controller has been statically mapped in the registry.
Exchange 2007 setup requires that the domain controller specified in the setup command match the domain
controller that has been statically mapped using a registry override.
To resolve this issue, run setup again, specifying the statically mapped domain controller for the
/DomainController: <FQDN of the statically mapped domain controller> parameter.
For more information about DSAccess and directory services detection, see Microsoft Knowledge Base article
250570, "Directory Service Server Detection and DSAccess Usage" (https://go.microsoft.com/fwlink/?
linkid=3052&kbid=250570).
 Insufficient permissions to prepare Active
Directory_DomainPrepWithoutADUpdate
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the attempted domain preparation failed.
Exchange setup requires that the Active Directory directory service be modified for Exchange Server 2007 before
domains in the Active Directory can be prepared.
The account being used to run the setup /PrepareAD command has insufficient permissions to execute this
command even though it appears to belong to the Enterprise Admins group. The account may have expired.
To resolve this issue, verify that the logged-on user account is valid and belongs to the Enterprise Admins group, or
log on with an account that has those permissions and rerun setup /PrepareAD.
For more information about how to perform the PrepareAD process, see "How to Prepare Active Directory and
Domains" (https://go.microsoft.com/fwlink/?LinkId=78453).
For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working
with Active Directory Permissions in Exchange Server" (https://go.microsoft.com/fwlink/?LinkId=47592).
 The local computer is already running Exchange
Server_ExchangeAlreadyInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the local computer has previous Microsoft
Exchange components installed.
Exchange 2007 setup requires that the local computer not have existing Microsoft Exchange components installed.
To resolve this issue, remove any Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003
components, and then rerun Microsoft Exchange setup.
To remove Microsoft Exchange components
1. Click Start, point to Settings, and then click Control Panel.
2. Double-click Add or Remove Programs.
3. In the Currently installed programs list, click Microsoft Exchange, and then click Change/Remove.
4. In Microsoft Exchange Installation Wizard, click Next.
5. In the Action list on the Component Selection page, click the down arrow next to each component that has
been installed, and then click Remove.

NOTE
Installed components have a check mark in the Action list. When you click Remove, the check mark is replaced by the
word Remove.

6. Click Next two times.

7. Click Finish.
 Older database files present_FirstSGFilesExist
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because it detected existing Microsoft Exchange
database files in the target installation path.
Exchange 2007 setup requires that the target installation path be empty of Microsoft Exchange database files.
To resolve this issue, remove all existing files from target installation paths and then rerun setup.
To delete existing Exchange Server database files from the target installation path
1. In My Computer or Windows Explorer, locate the target install path.

NOTE
By default, the database files are located in:
<systemDrive>:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group.

2. Right-click the files to be removed, and then select Delete.

3. At the Confirm File Delete dialog, click Yes.
4. Repeat steps 2 and 3 for all files in the target install paths.
 One or more Active Directory Connector servers
were found_ADCFound
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 and Exchange Server 2010 setup cannot continue because one or more Active
Directory Connectors (ADC ) have been found in the current Microsoft Exchange environment.
ADC replicates objects from Exchange Server version 5.5 to the Active Directory directory service in a mixed mode
Microsoft Exchange environment and is not supported by Exchange 2007 or Exchange 2010.
Exchange 2007 or Exchange 2010 setup requires that all ADC components be removed.
To resolve this issue, remove all ADC components, and rerun Exchange 2007 or Exchange 2010 setup.

To remove Active Directory Connector components

1. To disable the ADC service on the server that is running the ADC service, right-click My Computer on the desktop,
and then click Manage.
2. Expand the Services and Applications node, and then click the Services node.
3. In the right pane, right-click Microsoft Active Directory Connector and then click Properties.
4. Change the Startup Type to Disabled. The next time that the computer starts, the ADC service will not start.
5. Click Apply, and then click OK.
6. To uninstall the ADC service, use the Active Directory Installation Wizard on the Microsoft Exchange 2000 Server or
Microsoft Exchange Server 2003 CD. Open the \ADC\I386 folder and double-click the Setup.exe program. Follow the
prompts to Remove All ADC service components.

IMPORTANT
You must complete step 6 and Remove All ADC components to resolve this issue. It is insufficient to disable the ADC
service.

For more information about ADC, see the following Microsoft Knowledge Base articles:
325300, "Support WebCast: Introduction to the Active Directory Connector"
(https://go.microsoft.com/fwlink/?linkid=3052&kbid=325300).
325221, "Support WebCast: Microsoft Advanced Active Directory Connector"
(https://go.microsoft.com/fwlink/?linkid=3052&kbid=325221).
312632, "How To Install and Configure the Active Directory Connector in Exchange 2000 Server"
(https://go.microsoft.com/fwlink/?linkid=3052&kbid=312632).
2 minutes to read
 Domain preparation required_DomainPrepRequired
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the attempt to install the server role failed.
Microsoft Exchange setup requires that the local domain be prepared for Exchange Server 2007 before certain
server roles can be installed.
Preparation of the domain for Exchange Server 2007 consists of the following tasks:
Setting permissions on the Domain container for the Exchange Servers, Exchange Organization
Administrators, Authenticated Users, and Exchange Mailbox Administrators.
Creating the Microsoft Exchange System Objects container if it does not exist, and setting permissions on
this container for the Exchange Servers, Exchange Organization Administrators, and Authenticated Users.
Creating a new domain global group in the current domain called Exchange Install Domain Servers.
Adding the Exchange Install Domain Servers group to the Exchange Servers USG in the root domain.
To resolve this issue, run setup /PrepareDomain to prepare the local domain and retry the server role
installation.
For more information about how to perform the PrepareDomain process, see "How to Prepare Active Directory
and Domains" (https://go.microsoft.com/fwlink/?LinkId=78453).
 The COM+ Event System Service must be started
before setup can continue_EventSystemStopped
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because its attempt to install the Client Access Server or
Edge Transport server roles failed because the COM+ Event System service is not started on the target computer.
Exchange 2007 setup requires the computer that you are installing Microsoft Exchange to have the COM+ Event
System service status set to Started.
The COM+ Event System service supports system event notification for COM+ components, which provide
automatic distribution of events to subscribing COM components.
Both the Client Access Server and Edge Transport server roles have dependencies on COM+ components that
subscribe to the COM+ Event System service.
To resolve this issue, verify that the COM+ Event System service status is set to Started on the local computer, and
then rerun Microsoft Exchange setup.
To set the status of the COM+ Event System service to 'Started'
1. Right-click My Computer, and then click Manage.
2. Expand the Services and Applications node, and then click the Services node.
3. In the right pane, locate the Com+ Event System.
4. Right-click Com+ Event System, and then click Properties.
5. Set the Startup Type to Automatic and the Service status to Started.
6. Click Apply, and then click OK.
 IIS is in 32-bit compatibility mode_IIS32BitMode
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the Microsoft Internet Information Service (IIS )
is running in 32-bit mode on this 64-bit computer.
Exchange 2007 requires that IIS be in full 64-bit mode when it runs on a 64-bit computer.
To resolve this issue, switch IIS to 64-bit mode, and then rerun Microsoft Exchange setup.
To switch IIS to 64-bit mode
1. Open a command prompt.
2. Type the following:
cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False
3. Press enter
 Access control list (ACL) inheritance is
blocked_InhBlockPublicFolderTree
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 or Exchange Server 2010 setup cannot continue because the required
permissions have not been able to propagate.
Exchange setup requires that inheritance for permissions be enabled on the following Exchange objects:
Exchange Organization object
Exchange Administrative Group object
Exchange Servers container object
Exchange Address List object
Exchange Public Folder object
Exchange Public Folder tree object
Failure to enable inheritance for permissions on these objects may result in mail flow problems, store mounting
issues, and other service outages.
To resolve this issue, make sure that the "Allow permissions to propagate to this object and child objects" setting is
enabled for the object, and then rerun Exchange Server 2007 or Exchange 2010 setup.

To re-enable permissions inheritance for an Exchange configuration object using Exchange Server 2003 Exchange System
Manager
1. Enable the Security tab for the object properties box of Exchange System Manager by setting a registry parameter.
a. Start Registry Editor (Regedt32.exe).
b. Locate the following key in the registry:
HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin
c. On the Edit menu, click New, and then add the following registry value:
Value Name: ShowSecurityPage
Data Type: REG_DWORD
Radix: Binary
Value: 1
d. Quit Registry Editor.

NOTE
By default, the Security tab is not enabled in the configuration object properties box.

2. Open Exchange System Manager, find the object in question, right-click the object and select Properties.
3. Select the Security tab and then click Advanced.
4. Select Allow inheritable permissions from the parent to propagate to this object and all child objects to re-
enable permissions inheritance.
5. Restart Exchange Server.

WARNING
If you incorrectly modify the attributes of Active Directory objects when you use ADSI Edit, the LDP tool, or another LDAP
version 3 client, you may cause serious problems. These problems may require that you reinstall Microsoft
Windows Server™ 2003, Exchange Server, or both. Modify Active Directory object attributes at your own risk.

To re-enable permissions inheritance for an Exchange configuration object using ADSIEdit from Exchange Server 2007 or
Exchange Server 2010

1. Install ADSI Edit.

2. Launch ADSI Edit. Click Start, click Run, type adsiedit.msc in the text box, and then click OK.
3. Navigate to the object in question, right-click the object and select Properties.
4. Select the Security tab and then click Advanced.
5. Select Allow inheritable permissions from the parent to propagate to this object and all child objects to re-
enable permissions inheritance.
6. Select Ok twice to apply the change.
7. Wait for Active Directory replication to propagate the changes or force Active Directory replication by following the
guidance in Microsoft Knowledge Base article 232072, "Initiating Replication Between Active Directory Direct
Replication Partners" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072).
 Setup failure occurred while installing a server
role_InstallWatermark
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because a previous setup failure occurred while installing a
server role.
Exchange 2007 setup requires that a failed server role installation be successfully re-installed, or removed from the
setup process, before any other setup task can continue.
To address this issue, either reinstall just the failed server role(s), or remove the server role(s).
To reinstall the failed server role from the command line
1. Open a Command Prompt window, and then navigate to the installation files.
2. Run the following command:

Setup /roles:<Failed Server Role>

Select from one or more of the following roles, in a comma-separated list:

ClientAccess (or CA, or C )
EdgeTransport (or ET, or E )

NOTE
The Edge Transport server role cannot coexist on the same computer with any other server role.

NOTE
You must deploy the Edge Transport server role in the perimeter network and outside the Active Directory forest.

HubTransport (or HT, or H)

Mailbox (or MB, or M )
UnifiedMessaging (or UM, or U )
ManagementTools (or MT, or T)
 NOTE
If you specify ManagementTools, you will install the Exchange Management Console, the Exchange cmdlets for the
Exchange Management Shell, the Exchange Help file, the Exchange Best Practices Analyzer Tool, and the Exchange
Troubleshooting Assistant. If you install any other server role, the management tools will be installed automatically.

For example, to add the Hub Transport server role to an existing Mailbox server, type the following:
%LocalExchangeInstallationDir%\bin\Setup.com /role:HubTransport /Mode:Install

NOTE
If any Exchange Server 2007 server role previously installed successfully, the Setup wizard will run in maintenance mode. If no
Exchange 2007 server roles were previously successfully installed, the Setup wizard will start from where it stopped.

To use the Exchange Server 2007 Setup wizard in maintenance mode to reinstall the failed server role
1. Log on to the server for which you want to reinstall a server role.
2. Open Control Panel and then double-click Add or Remove Programs.
3. On the Change or Remove Programs page, select Microsoft Exchange Server, and then click Change.
4. In the Exchange Server 2007 Setup wizard, on the Exchange Maintenance Mode page, click Next.
5. On the Server Role Selection page, select the check boxes for the server roles that you want to install, and
then click Next.

NOTE
The Edge Transport server role cannot coexist on the same computer with any other server role.

NOTE
You must deploy the Edge Transport server role in the perimeter network and outside the Active Directory forest.

NOTE
If you select Management Tools, you will install the Exchange Management Console, the Exchange cmdlets for the
Exchange Management Shell, and the Exchange Help file. The management tools will be installed automatically if you
install any other server role.

6. If you selected Hub Transport Role, and if you are installing Exchange 2007 in a forest that has an existing
Exchange Server 2003 or Exchange 2000 Server organization, on the Mail Flow Settings page, select a
bridgehead server in the existing organization that is a member of the Exchange 2003 or Exchange 2000
routing group to which you want to create a routing group connector.
7. On the Readiness Checks page, view the status to determine if the organization and server role
prerequisite checks completed successfully. If they have completed successfully, click Install to install
Exchange 2007.
8. On the Completion page, click Finish.
To use the Exchange Server 2007 Setup wizard to reinstall the failed server role when no other server
role was previously successfully installed
1. Follow the guidance in "How to Perform a Custom Installation Using Exchange Server 2007 Setup"
(https://go.microsoft.com/fwlink/?LinkId=86648) in the Exchange Server 2007 product documentation.

To remove the failed server role

1. Follow the guidance in "How to Remove Exchange 2007 Server Roles" (https://go.microsoft.com/fwlink/?
LinkId=86649) in the Exchange Server 2007 product documentation.

For More Information

For more information about how to install Exchange 2007 in unattended mode, see "How to Install Exchange 2007
in Unattended Mode" (https://go.microsoft.com/fwlink/?LinkId=86476).
 Setup failure occurred while uninstalling a server
role_InterruptedUninstallNotContinued
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Exchange Server 2010 setup cannot continue because a previous setup failure occurred while uninstalling a server
role.
Exchange 2010 setup requires that a failed server role uninstall be successfully uninstalled before any other setup
task can continue.
To address this issue, uninstall the failed server role(s), and then rerun setup.
For more information about how to remove a server role, see the Exchange 2007 product documentation topic,
"How to Remove Exchange 2007 Server Roles" (https://go.microsoft.com/fwlink/?linkid=86649).
 Cannot determine the name of the Active Directory
site_InvalidADSite
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because this server does not appear to belong to a valid
Active Directory® directory service site.
Microsoft Exchange setup requires that the server that is used for installation of Exchange 2007 belong to a valid
Active Directory site.
To resolve this issue, verify that the local server is a member of a valid Active Directory site and rerun Exchange
Server 2007 setup.
You can use the /DsGetSite option of the Nltest.exe command line tool to verify and display site membership. For
more information, see "Nltest.exe: NLTest Overview" in the "Tools and Settings Collection" of Windows
Server 2003 Technical Reference (https://go.microsoft.com/fwlink/?LinkId=27734).
For more information about Active Directory troubleshooting, see "Troubleshooting Active Directory Operations"
in Windows Server 2003: Operations (https://go.microsoft.com/fwlink/?linkid=68099).
 The local computer is a domain controller of a child
domain_LocalComputerIsDCInChildDomain
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because the local computer is a domain controller for a
child domain.
Exchange 2007 setup will not install on to a domain controller for a child domain unless the domain controller is a
global catalog server.
To resolve this issue, promote the domain controller to a global catalog server or install Exchange 2007 to a non-
domain controller, a member server, in the child domain, and then rerun the Microsoft Exchange setup.
To correct this warning by making the Exchange server a global catalog server
1. On the domain controller, click Start, point to Programs, click Administrative Tools, and then click Active
Directory Sites and Services.
2. In the console tree, double-click Sites, double-click the name of the site, and then double-click Servers.
3. Double-click the target domain controller.
4. In the results pane, right-click NTDS Settings, and then click Properties.
5. On the General tab, click to select the Global catalog check box.
6. Restart the domain controller.
 Active Directory domain is mixed
mode_LocalDomainModeMixed
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because an existing Active Directory domain is not set to
Microsoft Windows®°2000 Server native mode or better.
Exchange 2007 setup will create Universal Security Groups that can only exist in Windows 2000 Server native
mode, or better, domains.
To resolve this issue, follow these steps to raise the domain functional level to at least the Windows 2000 Server
native level, and then rerun Exchange 2007 setup.
To raise the domain functional level
1. Open Active Directory Domains and Trusts.
2. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise
Domain Functional Level.
3. In Select an available domain functional level, use one of the following procedures:
To raise the domain functional level to Windows 2000 Server native, click Windows 2000 native,
and then click Raise.
To raise domain functional level to Windows Server® 2003, click Windows Server 2003, and then
click Raise.

WARNING

If you have or will have any domain controllers running Windows NT® 4.0 and earlier, do not raise the domain functional
level to Windows 2000 Server native. After the domain functional level is set to Windows 2000 Server native, it cannot be
changed back to Windows 2000 Server mixed.
If you have or will have any domain controllers running Windows NT 4.0 and earlier or Windows 2000 Server, do not raise
the domain functional level to Windows Server 2003. After the domain functional level is set to Windows Server 2003, it
cannot be changed back to Windows 2000 Server mixed or Windows 2000 Server native.
 The local domain needs to be
updated_LocalDomainPrep
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because the logged on user does not have the account
permissions that are required for domain preparation.
Exchange setup requires that the user who is logged on when Setup /PrepareDomain is run be a member of the
Domain Administrators and Exchange Organization Administrators groups, or the Enterprise Admins group.
To resolve this issue, grant the logged on user Domain Admins and Exchange Organization Administrator
permissions, enroll them in the Enterprise Admins group, or log on with an account that has those permissions and
rerun Exchange 2007 setup.
For more information about Active Directory permissions that are needed with Microsoft Exchange, see "Working
with Active Directory Permissions in Exchange Server" (https://go.microsoft.com/fwlink/?LinkId=47592).
 IIS 6 Compatibility components not
installed_LonghornIIS6MetabaseNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 Setup cannot continue its attempt to install the Client Access Server server role,
the Mailbox server role, or the Exchange 2007 Administrative Tools on the following Windows operating systems:
Windows Server 2008 R2
Windows Server 2008
Windows 7 (Administrative Tools only)
Windows Vista (Administrative Tools only)
This problem occurs because the Internet Information Server (IIS ) 6 Metabase Compatibility component and the
IIS 6 Management Console component are not installed.
Exchange 2007 setup requires that the computer on which you are installing the Exchange 2007 Client Access
server role, the Mailbox server role, or the Exchange 2007 Administrative Tools has the IIS 6 Metabase
Compatibility component and the IIS 6 Management Console component installed.
To resolve this problem, install the IIS 6 Metabase Compatibility component on the destination computer, and then
rerun Microsoft Exchange Setup.
Install the IIS 6.0 Management Compatibility Components in Windows Server 2008 R2 or in Windows
Server by using the Server Manager tool
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS 6 Management Compatibility.
4. Click to select the IIS 6 Metabase Compatibility, IIS 6 WMI Compatibility, and IIS 6 Management
Console check boxes.
5. In the Select Role Services pane, click Next.
6. In the Confirm Installations Selections pane, click Install.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 6.0 Management Compatibility Components in Windows 7 or in Windows Vista from
Control Panel
1. Click Start, click Control Panel, click Programs and Features, and then click Turn Windows features on
or off.
2. Open Internet Information Services.
3. Open Web Management Tools.
4. Open IIS 6.0 Management Compatibility.
5. Click to select the IIS 6 Metabase and IIS 6 configuration compatibility, IIS 6 WMI Compatibility,
and IIS 6 Management Console check boxes.
6. Click OK.
 IIS 6 Compatibility components not
installed_LonghornIIS6MgmtConsoleNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 Setup cannot continue its attempt to install the Client Access Server server role,
the Mailbox server role, or the Exchange 2007 Administrative Tools on the following Windows operating systems:
Windows Server 2008 R2
Windows Server 2008
Windows 7 (Administrative Tools only)
Windows Vista (Administrative Tools only)
This problem occurs because the Internet Information Server (IIS ) 6 Metabase Compatibility component and the
IIS 6 Management Console component are not installed.
Exchange 2007 setup requires that the computer on which you are installing the Exchange 2007 Client Access
server role, the Mailbox server role, or the Exchange 2007 Administrative Tools has the IIS 6 Metabase
Compatibility component and the IIS 6 Management Console component installed.
To resolve this problem, install the IIS 6 Metabase Compatibility component on the destination computer, and then
rerun Microsoft Exchange Setup.
Install the IIS 6.0 Management Compatibility Components in Windows Server 2008 R2 or in Windows
Server by using the Server Manager tool
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS 6 Management Compatibility.
4. Click to select the IIS 6 Metabase Compatibility, IIS 6 WMI Compatibility, and IIS 6 Management
Console check boxes.
5. In the Select Role Services pane, click Next.
6. In the Confirm Installations Selections pane, click Install.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 6.0 Management Compatibility Components in Windows 7 or in Windows Vista from
Control Panel
1. Click Start, click Control Panel, click Programs and Features, and then click Turn Windows features on
or off.
2. Open Internet Information Services.
3. Open Web Management Tools.
4. Open IIS 6.0 Management Compatibility.
5. Click to select the IIS 6 Metabase and IIS 6 configuration compatibility, IIS 6 WMI Compatibility,
and IIS 6 Management Console check boxes.
6. Click OK.
 IIS 7 component not
installed_LonghornIIS7BasicAuthNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2010 Setup or Microsoft Exchange Server 2007 Setup cannot install the Client Access
Server (CAS ) role or the Mailbox server role on a Microsoft Windows Server 2008-based computer or on a
Windows Server 2008 R2-based computer because the required Internet Information Server (IIS ) 7 components
are not installed.
Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the CAS role already has the following IIS 7
components installed.

REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

Dynamic Content Compression

Static Content Compression

Basic Authentication

Windows Authentication

IIS 7 Digest Authentication

ASP.NET

Client Certificate Mapping

Directory Browsing

HTTP Errors

HTTP Logging
 REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

HTTP Redirection

Tracing

ISAPI Filters

Request Monitor

Static Content

Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the Mailbox server role already has the
following IIS 7 components installed.

REQUIRED IIS 7 COMPONENTS FOR THE MAILBOX SERVER ROLE

Basic Authentication

Windows Authentication

To address this issue, follow the appropriate steps to install the required IIS 7 components on the destination
computer, and then run Microsoft Exchange Setup again.
Install the IIS 7 Components for the CAS server role by using the Windows Server 2008 Server Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Digest Authentication
Windows Authentication
5. In the Performance area, click to select the following check boxes:
Static Compression
Dynamic Compression
6. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations
Selections pane.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 7 Components for the Mailbox server role by using the Windows Server 2008 Server
Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Windows Authentication
5. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations
Selections pane.
6. Click Close to exit the Add Role Services wizard.
 IIS 7 component not
installed_LonghornIIS7DigestAuthNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2010 Setup or Microsoft Exchange Server 2007 Setup cannot install the Client Access
Server (CAS ) role or the Mailbox server role on a Microsoft Windows Server 2008-based computer or on a
Windows Server 2008 R2-based computer because the required Internet Information Server (IIS ) 7 components
are not installed.
Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the CAS role already has the following IIS 7
components installed.

REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

Dynamic Content Compression

Static Content Compression

Basic Authentication

Windows Authentication

IIS 7 Digest Authentication

ASP.NET

Client Certificate Mapping

Directory Browsing

HTTP Errors

HTTP Logging
 REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

HTTP Redirection

Tracing

ISAPI Filters

Request Monitor

Static Content

Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the Mailbox server role already has the
following IIS 7 components installed.

REQUIRED IIS 7 COMPONENTS FOR THE MAILBOX SERVER ROLE

Basic Authentication

Windows Authentication

To address this issue, follow the appropriate steps to install the required IIS 7 components on the destination
computer, and then run Microsoft Exchange Setup again.
Install the IIS 7 Components for the CAS server role by using the Windows Server 2008 Server Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Digest Authentication
Windows Authentication
5. In the Performance area, click to select the following check boxes:
Static Compression
Dynamic Compression
6. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations
Selections pane.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 7 Components for the Mailbox server role by using the Windows Server 2008 Server
Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Windows Authentication
5. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations
Selections pane.
6. Click Close to exit the Add Role Services wizard.
 IIS 7 component not
installed_LonghornIIS7HttpCompressionDynamicNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated yet, it may
still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2010 Setup or Microsoft Exchange Server 2007 Setup cannot install the Client Access Server
(CAS ) role or the Mailbox server role on a Microsoft Windows Server 2008-based computer or on a Windows
Server 2008 R2-based computer because the required Internet Information Server (IIS ) 7 components are not installed.
Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the Windows
Server 2008 R2-based computer on which you are installing the CAS role already has the following IIS 7 components
installed.

REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

Dynamic Content Compression

Static Content Compression

Basic Authentication

Windows Authentication

IIS 7 Digest Authentication

ASP.NET

Client Certificate Mapping

Directory Browsing

HTTP Errors

HTTP Logging

HTTP Redirection

Tracing
 REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

ISAPI Filters

Request Monitor

Static Content

Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the Windows
Server 2008 R2-based computer on which you are installing the Mailbox server role already has the following IIS 7
components installed.

REQUIRED IIS 7 COMPONENTS FOR THE MAILBOX SERVER ROLE

Basic Authentication

Windows Authentication

To address this issue, follow the appropriate steps to install the required IIS 7 components on the destination computer,
and then run Microsoft Exchange Setup again.
Install the IIS 7 Components for the CAS server role by using the Windows Server 2008 Server Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Digest Authentication
Windows Authentication
5. In the Performance area, click to select the following check boxes:
Static Compression
Dynamic Compression
6. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations Selections pane.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 7 Components for the Mailbox server role by using the Windows Server 2008 Server Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Windows Authentication
5. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations Selections pane.
6. Click Close to exit the Add Role Services wizard.
 IIS 7 component not
installed_LonghornIIS7HttpCompressionStaticNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated yet,
it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2010 Setup or Microsoft Exchange Server 2007 Setup cannot install the Client Access
Server (CAS ) role or the Mailbox server role on a Microsoft Windows Server 2008-based computer or on a
Windows Server 2008 R2-based computer because the required Internet Information Server (IIS ) 7 components are
not installed.
Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the CAS role already has the following IIS 7
components installed.

REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

Dynamic Content Compression

Static Content Compression

Basic Authentication

Windows Authentication

IIS 7 Digest Authentication

ASP.NET

Client Certificate Mapping

Directory Browsing

HTTP Errors

HTTP Logging

HTTP Redirection
 REQUIRED IIS 7 COMPONENTS FOR THE CAS SERVER ROLE

Tracing

ISAPI Filters

Request Monitor

Static Content

Exchange 2010 Setup and Exchange 2007 Setup require that the Windows Server 2008-based computer or the
Windows Server 2008 R2-based computer on which you are installing the Mailbox server role already has the
following IIS 7 components installed.

REQUIRED IIS 7 COMPONENTS FOR THE MAILBOX SERVER ROLE

Basic Authentication

Windows Authentication

To address this issue, follow the appropriate steps to install the required IIS 7 components on the destination
computer, and then run Microsoft Exchange Setup again.
Install the IIS 7 Components for the CAS server role by using the Windows Server 2008 Server Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Digest Authentication
Windows Authentication
5. In the Performance area, click to select the following check boxes:
Static Compression
Dynamic Compression
6. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations Selections
pane.
7. Click Close to exit the Add Role Services wizard.
Install the IIS 7 Components for the Mailbox server role by using the Windows Server 2008 Server
Manager
1. Click Start, click Administrative Tools, and then click Server Manager.
2. In the navigation pane, expand Roles, right-click Web Server (IIS ), and then click Add Role Services.
3. In the Select Role Services pane, scroll down to IIS.
4. In the Security area, click to select the following check boxes:
Basic Authentication
Windows Authentication
5. In the Select Role Services pane, click Next, and then click Install in the Confirm Installations Selections
pane.
6. Click Close to exit the Add Role Services wizard.
 The World Wide Web Publishing Service is disabled
or missing_W3SVCDisabledOrNotInstalled
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft® Exchange Server 2007 setup cannot continue because its attempt to install the Mailbox Server or
Client Access role found that the World Wide Web Publishing Service is either disabled or not installed on this
computer.
Exchange 2007 setup requires the computer that you are installing Microsoft Exchange to have the World Wide
Web Publishing Service installed and set to something other than disabled.
To resolve this issue, verify that the World Wide Web Publishing service is installed and not disabled on the local
computer, and then rerun Microsoft Exchange setup.
To verify that the World Wide Web Publishing Service is installed and not disabled
1. Right-click My Computer on the desktop, and then click Manage.
2. Expand the Services and Applications node, and then click the Services node.
3. In the right pane, locate the World Wide Web Publishing Service.
If the World Wide Web Publishing Service is not displayed in the list of services installed, follow the
steps in the procedure below to install it.
4. If the World Wide Web Publishing Service is displayed but has a status other than Started, continue
with the steps below to start it.
5. Right-click World Wide Web Publishing Service, and then click Properties.
6. Verify the Startup Type is Automatic and the Service status is set to Started.
7. Click Apply, and then click OK.
To install the World Wide Web Publishing Service
1. On the Start menu, select Settings, Control Panel, and then click Add or Remove Programs
2. Click Add/Remove Windows Components.
3. In the Components list, select the Application Server check box, and then click Details.
4. Select Internet Information Services Manager, and then click Details.
5. Select World Wide Web Service, and then select the check box.
6. Click OK two times to return to the Components list, and then click Next.
7. Click Finish when the IIS service is installed.
 OAB server has been
deleted_OffLineABServerDeleted
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The content in this topic hasn't been updated for Microsoft Exchange Server 2013. While it hasn't been updated
yet, it may still be applicable to Exchange 2013. If you still need help, check out the community resources below.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Microsoft Exchange Server 2007 setup cannot continue because its attempt to install the Client Access server role
failed. The Exchange Mailbox server designated to host the Offline Address Book (OAB ) has been deleted.
Exchange 2007 setup requires that there be a valid Exchange Mailbox server hosting OAB generation for the Client
Access server role installation to continue.
To address this issue, designate a valid Exchange Mailbox server as OAB generation host, and then rerun Exchange
2007 setup.
For information about how to designate an Exchange server to be the host for Offline Address Book generation,
see "How to Create an Offline Address Book" (https://go.microsoft.com/fwlink/?LinkId=86314) in the Exchange
2007 product documentation.
 Network ports for clients and mail flow in Exchange
2013
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic provides information about the network ports that are used by Microsoft Exchange Server 2013 for
communication with email clients, Internet mail servers, and other services that are external to your local Exchange
organization. Before we get into that, understand the following ground rules:
We do not support restricting or altering network traffic between internal Exchange servers, between
internal Exchange servers and internal Lync or Skype for Business servers, or between internal Exchange
servers and internal Active Directory domain controllers in any and all types of topologies. If you have
firewalls or network devices that could potentially restrict or alter this kind of network traffic, you need to
configure rules that allow free and unrestricted communication between these servers (rules that allow
incoming and outgoing network traffic on any port (including random RPC ports) and any protocol that
never alter bits on the wire).
Edge Transport servers are almost always located in a perimeter network, so it's expected that you'll restrict
network traffic between the Edge Transport server and the Internet, and between the Edge Transport server
and your internal Exchange organization. These network ports are described in this topic.
It's expected that you'll restrict network traffic between external clients and services and your internal
Exchange organization. It's also OK if you decide to restrict network traffic between internal clients and
internal Exchange servers. These network ports are described in this topic.

Network ports required for clients and services

The network ports that are required for email clients to access mailboxes and other services in the Exchange
organization are described in the following diagram and table.
Notes:
The destination for these clients and services is a Client Access server. This could be a standalone Client
Access server or a Client Access server and Mailbox server installed on the same computer.
Although the diagram shows clients and services from the Internet, the concepts are the same for internal
clients (for example, clients in an accounts forest accessing Exchange servers in a resource forest). Similarly,
the table doesn't have a source column because the source could be any location that's external to the
Exchange organization (for example, the Internet or an accounts forest).
Edge Transport servers have no involvement in the network traffic that's associated with these clients and
services.
PURPOSE PORTS COMMENTS

Encrypted web connections are 443/TCP (HTTPS) For more information about these
used by the following clients and clients and services, see the
services: following topics:
Autodiscover service Autodiscover service
Exchange ActiveSync Exchange ActiveSync
Exchange Web Services EWS reference for Exchange
(EWS)
Offline address books
Offline address book
distribution Outlook Anywhere

Outlook Anywhere (RPC MAPI over HTTP

over HTTP) What's new for Outlook
Outlook MAPI over HTTP Web App in Exchange 2013

Outlook Web App

 PURPOSE PORTS COMMENTS

Unencrypted web connections are 80/TCP (HTTP) Whenever possible, we recommend

used by the following clients and using encrypted web connections
services: on 443/TCP to help protect data
and credentials. However, you may
Internet calendar publishing find that some services must be
Outlook Web App (redirect configured to use unencrypted web
to 443/TCP) connections on 80/TCP to the
Client Access server.
Autodiscover (fallback when
443/TCP isn't available) For more information about these
clients and services, see the
following topics:
Enable Internet calendar
publishing
What's new for Outlook
Web App in Exchange 2013
Autodiscover service

IMAP4 clients 143/TCP (IMAP), 993/TCP (secure IMAP4 is disabled by default. For
IMAP) more information, see POP3 and
IMAP4 in Exchange Server 2013.
The IMAP4 service on the Client
Access server proxies connections
to the IMAP4 Backend service on a
Mailbox server.

POP3 clients 110/TCP (POP3), 995/TCP (secure POP3 is disabled by default. For
POP3) more information, see POP3 and
IMAP4 in Exchange Server 2013.
The POP3 service on the Client
Access server proxies connections
to the POP3 Backend service on a
Mailbox server.

SMTP clients (authenticated) 587/TCP (authenticated SMTP) The default Received connector
named "Client Frontend <Server
name>" listens for authenticated
SMTP client submissions on port
587 on the Client Access server.
Note:
If you have mail clients that can
submit authenticated SMTP mail
only on port 25, you can modify
the network adapter bindings value
of this Receive connector to also
listen for authenticated SMTP mail
submissions on port 25.

Network ports required for mail flow

How mail is delivered to and from your Exchange organization depends on your Exchange topology. The most
important factor is whether you have a subscribed Edge Transport server deployed in your perimeter network.

Network ports required for mail flow (no Edge Transport servers)
The network ports that are required for mail flow in an Exchange organization that has only Client Access servers
and Mailbox servers are described in the following diagram and table. Although the diagram shows separate
Mailbox and Client Access servers, the concepts are the same whether the Client Access server and the Mailbox
server are installed on the same computer or on separate computers.

PURPOSE PORTS SOURCE DESTINATION COMMENTS

PURPOSE PORTS SOURCE DESTINATION COMMENTS

Inbound mail 25/TCP (SMTP) Internet (any) Client Access The default
server Receive connector
named "Default
Frontend <Client
Access server
name>" on the
Client Access
server listens for
anonymous
inbound SMTP
mail on port 25.
Mail is relayed
from the Client
Access server to a
Mailbox server
using the implicit
and invisible
intra-organization
Send connector
that automatically
routes mail
between
Exchange servers
in the same
organization.

Outbound mail 25/TCP (SMTP) Mailbox server Internet (any) By default,

Exchange doesn't
create any Send
connectors that
allow you to send
mail to the
Internet. You
have to create
Send connectors
manually. For
more information,
see Send
connectors.
 PURPOSE PORTS SOURCE DESTINATION COMMENTS

Outbound mail (if 25/TCP (SMTP) Client Access Internet (any) Outbound mail is
routed through server routed through a
the Client Access Client Access
server) server only when
a Send connector
is configured with
Proxy through
Client Access
server in the
Exchange admin
center or
-
FrontEndProxyEnabled
$true
in the Exchange
Management
Shell.
In this case, the
default Receive
connector named
"Outbound Proxy
Frontend <Client
Access server
name>" on the
Client Access
server listens for
outbound mail
from the Mailbox
server. For more
information, see
Create a Send
connector for
email sent to the
Internet.

DNS for name 53/UDP,53/TCP Internet-facing DNS server See the Name
resolution of the (DNS) Exchange server resolution section.
next mail hop (not (Client Access
pictured) server or Mailbox
server)

Network ports required for mail flow with Edge Transport servers
A subscribed Edge Transport server that's installed in your perimeter network basically eliminates SMTP mail flow
through the Client Access server. Specifically:
Outbound mail from the Exchange organization never flows through a Client Access server. Mail always
flows from a Mailbox server in the subscribed Active Directory site to the Edge Transport server (regardless
of the version of Exchange on the Edge Transport server).
Inbound mail never flows through a standalone Client Access server. Mail flows from the Edge Transport
server to a Mailbox server in the subscribed Active Directory site. If the Mailbox server and the Client
Access server are installed on the same computer, mail from an Exchange 2013 Edge Transport server first
arrives on the computer at the Front End Transport service (the Client Access server role) before it flows to
the Transport service (the Mailbox server role). Exchange 2007 or Exchange 2010 Edge Transport servers
always deliver mail directly to the Transport service even when the Mailbox server and the Client Access
 server are installed on the same computer.
For more information, see Mail flow.
The network ports that are required for mail flow in Exchange organizations that have Edge Transport servers are
described in the following diagram and table. Unless otherwise noted, the concepts are the same whether the
Client Access server and the Mailbox server are installed on the same computer or on separate computers.

PURPOSE PORTS SOURCE DESTINATION COMMENTS

Inbound mail - 25/TCP (SMTP) Internet (any) Edge Transport The default
Internet to Edge server Receive connector
Transport server named "Default
internal Receive
connector <Edge
Transport server
name>" on the
Edge Transport
server listens for
anonymous SMTP
mail on port 25.

Inbound mail - 25/TCP (SMTP) Edge Transport Mailbox servers in The default Send
Edge Transport server the subscribed connector named
server to internal Active Directory "EdgeSync -
Exchange site Inbound to
organization <Active Directory
site name>"
relays inbound
mail on port 25
to any Mailbox
server in the
subscribed Active
Directory site. For
more information,
see the "Send
connectors
created during
the Edge
Subscription
 process" section
PURPOSE PORTS SOURCE DESTINATION COMMENTS
in the topic, Edge
Subscriptions.
The service that
actually receives
mail depends on
whether the
Mailbox server
and Client Access
server are
installed on the
same computer
or on separate
computers.
Standalo
ne
Mailbox
server T
he default
Receive
connector
named
"Default
<Mailbox
server
name>"
listens for
inbound
mail
(including
mail from
Edge
Transport
servers)
on port
25.
Mailbox
server
and
Client
Access
server
installed
on the
same
computer
The
default
Receive
connector
named
"Default
Frontend
<Server
name>" in
the Front
End
Transport
service
(the Client
Access
server
role)
 listens for
PURPOSE PORTS SOURCE DESTINATION COMMENTS
inbound
mail
(including
mail from
Exchange
2013 Edge
Transport
servers)
on port
25.

Outbound mail - 25/TCP (SMTP) Mailbox servers in Edge Transport Outbound mail
Internal Exchange the subscribed servers always bypasses
organization to Active Directory the Client Access
Edge Transport site server.
server
Mail is relayed
from any Mailbox
server in the
subscribed Active
Directory site to
an Edge Transport
server using the
implicit and
invisible intra-
organization Send
connector that
automatically
routes mail
between
Exchange servers
in the same
organization.
The default
Receive connector
named "Default
internal Receive
connector <Edge
Transport server
name>" on the
Edge Transport
server listens for
SMTP mail on
port 25 from any
Mailbox server in
the subscribed
Active Directory
site.

Outbound mail - 25/TCP (SMTP) Edge Transport Internet (any) The default Send
Edge Transport server connector named
server to Internet "EdgeSync -
<Active Directory
site name> to
Internet" relays
outbound mail on
port 25 from the
Edge Transport
server to the
Internet.
PURPOSE PORTS SOURCE DESTINATION COMMENTS

EdgeSync 50636/TCP Mailbox servers in Edge Transport When the Edge

synchronization (secure LDAP) the subscribed servers Transport server
Active Directory is subscribed to
site that the Active
participate in Directory site, all
EdgeSync Mailbox servers
synchronization that exist in the
site at the time
participate in
EdgeSync
synchronization.
However, any
Mailbox servers
that you add later
don't
automatically
participate in
EdgeSync
synchronization.

DNS for name 53/UDP,53/TCP Edge Transport DNS server See the Name
resolution of the (DNS) server resolution section.
next mail hop (not
pictured)
 PURPOSE PORTS SOURCE DESTINATION COMMENTS

Proxy server user defined Edge Transport Internet Sender reputation

definition for servers (the Protocol
sender reputation Analysis agent)
(not pictured) analyzes inbound
message paths in
an effort to
reduce spam. If
your organization
uses a proxy
server to control
access to the
Internet, you
need to define
details about the
proxy server so
that sender
reputation can
work properly (in
particular, open
proxy detection
and sender
blocking). You use
the
ProxyServerName
, ProxyServerPort
and
ProxyServerType
parameters on
the Set-
SenderReputati
onConfig cmdlet
to define your
organization's
proxy server so
sender reputation
can successfully
connect to the
Internet. For
more information,
see Manage
sender
reputation.

Name resolution
DNS resolution of the next mail hop is a fundamental part of mail flow in any Exchange organization. Exchange
servers that are responsible for receiving inbound mail or delivering outbound mail must be able to resolve both
internal and external host names for proper mail routing. And all internal Exchange servers must be able to resolve
internal host names for proper mail routing. There are many different ways to design a DNS infrastructure, but the
important result is to ensure name resolution for the next hop is working properly for all of your Exchange servers.

Network ports required for hybrid deployments

The network ports that are required for an organization that uses both Exchange 2013 and Microsoft Office 365
are covered in the "Hybrid deployment protocols, port and endpoints" section in Hybrid deployment prerequisites.

Network ports required for Unified Messaging

The network ports that are required for Unified Messaging are covered in the following topics:
UM protocols, ports, and services
Exchange Server 2013 SP1 Architecture Poster
 Overview of Exchange 2013 services
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

During the installation of Exchange Server 2013, Setup runs a set of tasks that install new services in Microsoft
Windows. A service is a background process that can be launched during the startup of the server by the Windows
Service Control Manager. Services are executable files designed to operate independently and without
administrative intervention. A service can run using either a graphical user interface (GUI) mode or a console
mode.
All previous versions of Exchange included components that are implemented as services. Each Exchange server
role includes services that are part of (or may be needed by) the server role to perform its functions. Note that
some services only become active when specific features are used.
The sections in this topic describe the various services that are installed by Exchange 2013 on Mailbox servers,
Client Access servers, and Edge Transport servers. For services that are labeled as optional, you can disable the
service if you determine your organization doesn't need the functionality that's provided by the service.

Exchange services on Exchange 2013 Mailbox servers

The following table describes the Exchange services that are installed on Mailbox servers.

DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides Automatic Local Net.TCP Required

Exchange geADTopo Active System Port
Active logy Directory Sharing
Directory topology Service
Topology informatio
n to
Exchange
services. If
this
service is
stopped,
most
Exchange
services
can't start.

Microsoft MSExchan Provides Automatic Local Microsoft Optional

Exchange geAntispa Exchange System Exchange
Anti-spam mUpdate SmartScre Active
Update en spam Directory
definition Topology
updates.

NOTE
On
Nove
mber
1,
 2016,
DESCRIPTION
SERVICE SHORT Micro
AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME soft
DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL
stopp
ed
produ
cing
spam
definiti
on
updat
es for
the
Smart
Screen
filters
in
Excha
nge
and
Outlo
ok.
The
existin
g
Smart
Screen
spam
definiti
ons
will be
left in
place,
but
their
effecti
veness
will
likely
degra
de
over
time.
For
more
inform
ation,
see
Depre
cating
suppo
rt for
Smart
Screen
in
Outlo
ok
and
Excha
nge.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides Automatic Local Microsoft Required

Exchange geDagMg storage System Exchange
DAG mt and Active
Managem database Directory
ent layout Topology
managem
ent for Net.TCP
Mailbox Port
servers in Sharing
database Service
availability
groups
(DAGs).

Microsoft MSExchan Provides Automatic Local None Required

Exchange geDiagnos an agent System
Diagnostic tics that
s monitors
Exchange
server
health.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Replicates Automatic Local Microsoft Optional

Exchange geEdgeSy configurati System Exchange
EdgeSync nc on and Active
recipient Directory
data Topology
between
the
Mailbox
server and
Active
Directory
Lightweig
ht
Directory
Services
(AD LDS)
on
subscribed
Edge
Transport
servers
over a
secure
LDAP
channel.
If you
don't have
any
subscribed
Edge
Transport
servers,
you can
disable
this
service.

Microsoft MSExchan Part of Automatic Local Windows Required

Exchange geHM managed System Event Log
Health availability
Manager that Windows
monitors Managem
the health ent
of key Instrumen
componen tation
ts on the
Exchange
server.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Receives Manual Network Microsoft Optional

Exchange geIMAP4B proxied Service Exchange
IMAP4 E client Active
Backend connectio Directory
ns from Topology
the from
the
IMAP4
service on
Client
Access
servers.
By default,
this
service
isn't
running,
so IMAP4
clients
can't
connect to
the
Exchange
server
until this
service is
started.
If you
don't have
any
IMAP4
clients,
you can
disable
this
service.

Microsoft MSExchan Manages Automatic Local Microsoft Required

Exchange geIS the System Exchange
Informatio mailbox Active
n Store databases Directory
on the Topology
server. If
this Remote
service is Procedure
stopped, Call (RPC)
mailbox Server
databases
on the Windows
server are Event Log
unavailabl Workstati
e. on
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Performs Automatic Local Microsoft Required

Exchange geMailbox backgroun System Exchange
Mailbox Assistants d Active
Assistants processing Directory
of Topology
mailboxes
in mailbox
databases
on the
server.

Microsoft MSExchan Processes Automatic Local Microsoft Required

Exchange geMailbox mailbox System Exchange
Mailbox Replicatio moves Active
Replicatio n and move Directory
n requests. Topology
Net.TCP
Port
Sharing
Service

Microsoft MSExchan Receives Automatic Network Microsoft Required

Exchange geDelivery SMTP Service Exchange
Mailbox messages Active
Transport from the Directory
Delivery Microsoft Topology
Exchange
Transport
service
(on the
local or
remote
Mailbox
servers)
and
delivers
them to a
local
mailbox
database
using RPC.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Receives Automatic Local Microsoft Required

Exchange geSubmiss RPC System Exchange
Mailbox ion messages Active
Transport from a Directory
Submissio local Topology
n mailbox
database,
and
submits
them over
SMTP to
the
Microsoft
Exchange
Transport
service
(on the
local or
remote
Mailbox
servers).

Microsoft MSExchan Receives Manual Network Microsoft Optional

Exchange gePOP3BE proxied Service Exchange
POP3 client Active
Backend connectio Directory
ns from Topology
the POP3
service on
Client
Access
servers.
By default,
this
service
isn't
running,
so POP3
clients
can't
connect to
the
Exchange
server
until this
service is
started.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides Automatic Local Microsoft Required

Exchange geRepl replication System Exchange
Replicatio functionali Active
n Service ty for Directory
mailbox Topology
databases
in a
database
availability
groups
(DAGs).

Microsoft MSExchan Manages Automatic Network Microsoft Required

Exchange geRPC client RPC Service Exchange
RPC Client connectio Active
Access ns for Directory
Exchange. Topology

Microsoft MSExchan Provides Automatic Local Microsoft Required

Exchange geFastSea indexing System Exchange
Search rch of mailbox Active
content, Directory
which Topology
improves
the
performan
ce of
content
search.

Microsoft HostContr Provides Automatic Local HTTP Required

Exchange ollerServic deployme System Service
Search e nt and
Host managem
Controller ent
services
for
applicatio
ns on the
local
Exchange
server.

Microsoft WSBExcha Enables Manual Local None Optional

Exchange nge Windows System
Server Server
Extension Backup to
for back and
Windows restore
Server Exchange
Backup server
data.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides a Automatic Local Microsoft Required

Exchange geService service System Exchange
Service Host host for Active
Host Exchange Directory
componen Topology
ts that
don't have
their own
services.

Microsoft MSExchan Provides Automatic Network Microsoft Required

Exchange geThrottli user Service Exchange
Throttling ng workload Active
managem Directory
ent that Topology
limits the
rate of
user
operations
(formerly
known as
user
throttling).

Microsoft MSExchan Provides Automatic Network Microsoft Required

Exchange geTranspo SMTP Service Exchange
Transport rt server and Active
transport Directory
stack. Topology
Microsoft
Filtering
Managem
ent
Service

Microsoft MSExchan Provides Automatic Local Microsoft Optional

Exchange geTranspo remote System Exchange
Transport rtLogSearc search Active
Log h capability Directory
Search for Topology
transport
log files
(for
example,
message
tracking).
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides Automatic Local CNG Key Optional

Exchange geUM Unified System Isolation
Unified Messagin
Messagin g (UM) Microsoft
g features: Exchange
allows Active
voice and Directory
fax Topology
messages
to be
stored in
Exchange
and gives
users
telephone
access to
email,
voice mail,
calendar,
contacts,
or an auto
attendant.
If this
service is
stopped,
Unified
Messagin
g isn't
available.
If you
don't use
UM, you
can
disable
this
service.

Exchange services on Exchange 2013 Client Access servers

The following table describes the Exchange services that are installed on Client Access servers.

DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides Automatic Local Net.TCP Required

Exchange geADTopo Active System Port
Active logy Directory Sharing
Directory topology Service
Topology informatio
n to
Exchange
services. If
this
service is
stopped,
most
Exchange
services
can't start.

Microsoft MSExchan Provides Automatic Local None Required

Exchange geDiagnos an agent System
Diagnostic tics that
s monitors
Exchange
server
health.

Microsoft MSExchan Proxies Automatic Local Microsoft Required

Exchange geFrontEn SMTP System Exchange
Frontend dTranspor connectio Active
Transport t ns from Directory
external Topology
hosts to
the
Microsoft
Exchange
Transport
service on
Mailbox
servers.

Microsoft MSExchan Part of Automatic Local Windows Required

Exchange geHM managed System Event Log
Health availability
Manager that Windows
monitors Managem
the health ent
of key Instrumen
componen tation
ts on the
Exchange
server.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Proxies Manual Local Microsoft Optional

Exchange geIMAP4 IMAP4 System Exchange
IMAP4 client Active
connectio Directory
ns to the Topology
IMAP4
service on
Mailbox
servers.
By default,
this
service
isn't
running,
so IMAP4
clients
can't
connect to
the
Exchange
server
until this
service is
started.
If you
don't have
any
IMAP4
clients,
you can
disable
this
service.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Proxies Manual Network Microsoft Optional

Exchange gePOP3 POP3 Service Exchange
POP3 client Active
connectio Directory
ns to the Topology
IMAP4
service on
Mailbox
servers.
By default,
this
service
isn't
running,
so POP3
clients
can't
connect to
the
Exchange
server
until this
service is
started.

Microsoft HostContr Provides Automatic Local HTTP Required

Exchange ollerServic deployme System Service
Search e nt and
Host managem
Controller ent
services
for
applicatio
ns on the
local
Exchange
server.

Microsoft MSExchan Provides a Automatic Local Microsoft Required

Exchange geService service System Exchange
Service Host host for Active
Host Exchange Directory
componen Topology
ts that
don't have
their own
services.
 DESCRIPTION
SERVICE SHORT AND DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DEPENDENCIES STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Redirects Automatic Local CNG Key Optional

Exchange geUMCR UM client System Isolation
Unified connectio
Messagin ns to the Microsoft
g Call Unified Exchange
Router Messagin Active
g service Directory
on Topology
Mailbox
servers.
If you
don't use
UM, you
can
disable
this
service.

Exchange services on Exchange 2013 Edge Transport servers

The following table describes the Exchange services that are installed on Edge Transport servers.

SERVICE SHORT DEFAULT SECURITY REQUIRED OR

SERVICE NAME NAME DESCRIPTION STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft ADAM_M Stores Automatic Network COM+ Required

Exchange SExchange configurati Service Event
ADAM on data System
and
recipient
data on
the Edge
Transport
server.
This
service
represents
the
named
instance
of the
Active
Directory
Lightweig
ht
Directory
Services
(AD LDS)
that's
automatic
ally
created by
Exchange
Setup.
Microsoft MSExchan Provides Automatic Local Microsoft Optional
SERVICE SHORT DEFAULT SECURITY REQUIRED OR
ExchangeNAME
SERVICE geAntispa
NAME Exchange
DESCRIPTION STARTUP TYPE System T
CONTEX Exchange
DEPENDENCIES OPTIONAL
Anti-spam mUpdate SmartScre ADAM
Update en spam
definition
updates.

NOTE
On
Nove
mber
1,
2016,
Micro
soft
stopp
ed
produ
cing
spam
definiti
on
updat
es for
the
Smart
Screen
filters
in
Excha
nge
and
Outlo
ok.
The
existin
g
Smart
Screen
spam
definiti
ons
will be
left in
place,
but
their
effecti
veness
will
likely
degra
de
over
time.
For
more
inform
ation,
see
Depre
cating
suppo
rt for
 Smart
SERVICE SHORT DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME Screen
DESCRIPTION STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL
in
Outlo
ok
and
Excha
nge.

Microsoft MSExchan Monitors Automatic Local Microsoft Required

Exchange geEdgeCr credential System Exchange
Credential edential changes in ADAM
Service Active
Directory
Lightweig
ht
Directory
Services
(AD LDS)
and
installs the
changes
on the
Edge
Transport
server.

Microsoft MSExchan Provides Automatic Local None Required

Exchange geDiagnos an agent System
Diagnostic tics that
s monitors
Exchange
server
health.

Microsoft MSExchan Part of Automatic Local Windows Required

Exchange geHM managed System Event Log
Health availability
Manager that Windows
monitors Managem
the health ent
of key Instrumen
componen tation
ts on the
Exchange
server.

Microsoft MSExchan Provides a Automatic Local Microsoft Required

Exchange geService service System Exchange
Service Host host for ADAM
Host Exchange
componen
ts that
don't have
their own
services.
 SERVICE SHORT DEFAULT SECURITY REQUIRED OR
SERVICE NAME NAME DESCRIPTION STARTUP TYPE CONTEX T DEPENDENCIES OPTIONAL

Microsoft MSExchan Provides Automatic Network Microsoft Required

Exchange geTranspo SMTP Service Exchange
Transport rt server and ADAM
transport
stack.

Microsoft MSExchan Provides Automatic Local Microsoft Optional

Exchange geTranspo remote System Exchange
Transport rtLogSearc search ADAM
Log h capability
Search for
transport
log files
(for
example,
message
tracking).
 Basic concepts in Exchange Management Shell
5/20/2019 • 2 minutes to read • Edit Online

Getting help
Getting help

Cmdlets and parameters

Cmdlets
Parameters
Structured data
Syntax

Running commands
Aliases
Arrays
Comparison operators
Identity
Import and export files in the Exchange Management Shell
Modifying multivalued properties
Pipelining
WhatIf, Confirm, and ValidateOnly switches
Working with command output

Running scripts
Scripting with the Exchange Management Shell
Script security
Shell variables
User-defined variables
 Cmdlets
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

A cmdlet, pronounced "command-let", is the smallest unit of functionality in the Exchange Management Shell.
Cmdlets resemble built-in commands in other shells, for example, the dir command found in cmd.exe . Like these
familiar commands, cmdlets can be called directly from the command line in the Shell and run under the context of
the Shell, not as a separate process.

NOTE
Since Microsoft Exchange Server 2007, there have been changes to how Exchange 2013 uses cmdlets internally due to the
use of Windows PowerShell remoting functionality. These changes have little to no impact on how you need to use cmdlets,
but they may offer additional flexibility in how you manage your Exchange servers.

Cmdlets are usually designed around repetitive administrative tasks, and, in the Shell, several hundred cmdlets are
provided for Exchange-specific management tasks. These cmdlets are available in addition to the non-Exchange
system cmdlets included in the basic Windows PowerShell shell design. For information about how to open the
Exchange Management Shell, see Open the Shell.
All cmdlets in the Shell are presented in verb-noun pairs. The verb-noun pair is always separated by a hyphen (-)
without spaces, and the cmdlet nouns are always singular. Verbs refer to the action that the cmdlet takes. Nouns
refer to the object on which the cmdlet takes action. For example, in the Get-SystemMessage cmdlet, the verb is
Get, and the noun is SystemMessage. All Shell cmdlets that manage a specific feature share the same noun. The
following table provides examples of some verbs available in the Shell.

NOTE
By default, if the verb is omitted, the Shell assumes the Get verb. For example, when you call Mailbox, you retrieve the same
results as when you call Get-Mailbox.

Examples of verbs in the Exchange Management Shell

VERB DESCRIPTION

Disable Disable cmdlets set the Enabled status of the specified

Exchange object to $False . This prevents the object
from processing data even though the object exists.

Enable Enable cmdlets set the Enabled status of the specified

Exchange object to $True . This enables the object to
process data.
 VERB DESCRIPTION

Get Get cmdlets retrieve information about a specific

Exchange object.

NOTE
Most Get cmdlets only return summary information
when you run them. To tell the Get cmdlet to return
verbose information when you run a command, pipe the
command to the Format-List cmdlet. For more
information about the Format-List command, see
Working with command output. For more information
about pipelining, see Pipelining.

Install Install cmdlets install a new object or feature on an

Exchange server.

Move Move cmdlets relocate the specified Exchange object from

one container or server to another.

New New cmdlets create new Exchange object.

Remove Remove cmdlets delete the specified Exchange object.

Set Set cmdlets modify the properties of an existing Exchange

object.

Test Test cmdlets test specific Exchange components and

provide log files that you can examine.

Uninstall Uninstall cmdlets remove an object or feature from an

Exchange server.

The following list of cmdlets is an example of a complete cmdlet set. This cmdlet set is used to manage the delivery
status notification (DSN ) message and mailbox quota message features of Exchange 2013:
Get-SystemMessage
New-SystemMessage
Remove-SystemMessage
Set-SystemMessage
 Identity
6/10/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Identity parameter is a special parameter that you can use with most cmdlets. The Identity parameter gives
you access to the unique identifiers that refer to a specific object in Microsoft Exchange Server 2013. This
capability lets you perform actions on a specific Exchange 2013 object.
The following sections describe the Identity parameter and provide examples of how you can use it effectively:
Characteristics of the Identity parameter
Wildcard characters in Identity
Examples of the Identity parameter

Characteristics of the Identity parameter

The primary unique identifier of an object in Exchange 2013 is always a GUID. A GUID is a 128-bit identifier, such
as 63d64005-42c5-4f8f-b310-14f6cb125bf3 . This GUID never repeats and is therefore always unique. However, you
don't want to type such GUIDs regularly. Therefore the Identity parameter typically also consists of the values of
other parameters, or combined set of values from multiple parameters on a single object. These values are also
guaranteed to be unique across that set of objects. You can specify the values of these other parameters, such as
Name and DistriguishedName, or they can be system-generated. The additional parameters that are used, if any,
and how they are populated, depend on the object you refer to.
The Identity parameter is also considered a positional parameter. The first argument on a cmdlet is assumed to be
the Identity parameter when no parameter label is specified. This reduces the number of keystrokes when you type
commands. For more information about positional parameters, see Parameters.
The following example shows the use of the Identity parameter by using the Receive connector's unique Name
parameter value. This example also shows how you can omit the Identity parameter name because Identity is a
positional parameter.

Get-ReceiveConnector -Identity "From the Internet"

Get-ReceiveConnector "From the Internet"

Like all objects in Exchange 2013, this Receive connector can also be referred to by its unique GUID. For example,
if the Receive connector named "From the Internet" is also assigned the GUID
63d64005-42c5-4f8f-b310-14f6cb125bf3 , you can also retrieve the Receive connector by using the following
command:

Get-ReceiveConnector 63d64005-42c5-4f8f-b310-14f6cb125bf3

Wildcard characters in Identity

Some Get cmdlets can accept a wildcard character ( * ) as part of the value you submit to Identity when you run
the cmdlet. By using a wildcard with the Identity parameter, you can specify a partial name and retrieve a list of
objects that match that partial name. You can place a wildcard character at the beginning or the end of the Identity
value, but you can't place the character in the middle of a string. For example, the commands Get-Mailbox David*
and Get-Mailbox *anders* are valid, but Get-Mailbox Reb*ca isn't a valid command.
Some Get cmdlets retrieve objects in Exchange 2013 that are organized in a hierarchical or parent and children
relationship. That is, there may be a collection of parent objects that also contain their own child objects. Objects
that have a parent and child relationship may have an Identity with the syntax of <parent>\<child> .
When an Identity parameter has a syntax of <parent>\<child> , some cmdlets enable you to use a wildcard
character (*) to replace all or some of the parent or child names. For example, if you want to find all of the child
objects named "Contoso" in all parent objects, you could use the syntax "*\Contoso" . Likewise, if you want to find
all of the child objects with a partial name of "Auth" that exist under the "ServerA" parent object, you could use
the syntax "ServerA\Auth*" .
Some, but not all, cmdlets allow you to specify just the child portion of the Identity parameter when you run a
command. When you do this, the cmdlets default to the current parent object being accessed. For example, two
receive connectors named "Contoso Receive Connector" exist on both MBX1 and MBX2. If you run the command
Get-ReceiveConnector "Contoso Receive Connector" on MBX2, only the receive connector on the server MBX2 is
returned.
The specific behavior of the Identity parameter and wildcard characters is dependent on the cmdlet that's being
run. For more information about the cmdlet you're running, see the feature-specific content for that cmdlet.

Examples of the Identity parameter

The examples described in this topic illustrate how the Identity parameter can accept different unique values to
refer to specific objects in the Exchange 2013 organization. These examples also illustrate how the Identity
parameter label can be omitted to reduce the number of keystrokes when you type commands.

DSN messages
The examples in this section refer to the delivery status notification (DSN ) messages that can be configured in an
Exchange 2013 organization. The first example shows how to retrieve DSN 5.4.1 by using the Get-
SystemMessage cmdlet. In the Get-SystemMessage cmdlet, the Identity parameter consists of several pieces of
data that are configured on each DSN message object. These pieces of data include the language that the DSN is
written in, whether the DSN is internal or external in scope, and the DSN message code as in the following
example:

Get-SystemMessage en\internal\5.4.1

You can also retrieve this DSN message by using its GUID as in the following example, because all objects in
Exchange 2013 have a GUID:

Get-SystemMessage 82ca7bde-1c2d-4aa1-97e1-f298a6f10222

For more information about the makeup of the Identity parameter when it's used with the SystemMessage
cmdlets, see DSN message identity.

Management role entries

The examples in this section refer to management role entries that make up management roles in Exchange 2013.
Management roles are used to control the permissions that are granted to administrators and end users.
Management role entries are made up of two parts: the management role they're associated with and a cmdlet.
The Identity parameter is likewise made up of both the management role name and the cmdlet name. For example,
the following is the role entry for the Set-Mailbox cmdlet on the Mail Recipients role:
 Mail Recipients\Set-Mailbox

The Mail Recipients\Set-Mailbox role entry is one of several entries on the Mail Recipients role. To view all the
role entries on the Mail Recipients role, you can use the following command:

Get-ManagementRoleEntry "Mail Recipients\*"

To view all the role entries on the Mail Recipients role that contain the string " Mailbox ", use the following
command:

Get-ManagementRoleEntry "Mail Recipients\*Mailbox*"

To view all the management roles where Set-Mailbox is one of the role entries, use the following command:

Get-ManagementRoleEntry *\Set-Mailbox

With role entries you can use the wildcard character in a variety of ways to query Exchange 2013 for the
information you're interested in.
For more information about management roles, see Understanding management roles.
 Import and export files in the Exchange Management
Shell
6/10/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 uses Windows PowerShell command-line interface remoting to establish a
connection between the server or workstation from which you're administering Exchange and the server running
Exchange 2013 that you're administering. In Exchange 2013, this is called remote Exchange Management Shell, or
remote Shell. Even if you're administering the local Exchange 2013 server, remote Shell is used to make the
connection. For more information about local and remote Shell, see Using PowerShell with Exchange 2013
(Exchange Management Shell).
How you import and export files to and from an Exchange server in Exchange 2013 is different than how you
might have done it in Exchange Server 2007. This is due to the use of remote Shell in Exchange 2013. This topic
discusses why this new process is required and how to import and export files between a local server or
workstation and an Exchange 2013 server.

Windows PowerShell sessions

To understand why you need a special syntax to import and export files in remote Shell, you need to know how the
Shell is implemented in Exchange 2013. The Shell uses Windows PowerShell sessions, which are the environments
in which variables, cmdlets, and so on, can share information. Every time you open a new Shell window, you create
a new session. The cmdlets that are run in each window can access variables and other information stored in that
window, but can't access variables in other open Shell windows. This is because they're each contained within their
own Windows PowerShell session. Windows PowerShell sessions can also be referred to as runspaces.
Remote Shell in Exchange 2013 has two sessions, the local session and the remote session. The local session is the
Windows PowerShell session that's running on your local computer. This session contains all of the cmdlets that
ship with Windows PowerShell. It also has access to your local file system.
The remote session is the Windows PowerShell session that's running on the remote Exchange server. This session
is where all Exchange cmdlets are run. It has access to the Exchange server's file system.
When you connect to a remote Exchange server, a connection is made between your local session on your
computer and the remote session on the Exchange server. This connection enables you to run Exchange cmdlets on
the remote Exchange server in your local session even though your local computer doesn't have any Exchange
cmdlets installed. Even though the Exchange cmdlets appear to be running on your local computer, they're actually
running on the Exchange server.

IMPORTANT
Even if you open the Shell on an Exchange 2013 server, the same connection process takes place and two sessions are
created. This means that you must use the same new syntax to import and export files whether you're opening the Shell on
an Exchange 2013 server or from a remote client workstation.

The Exchange cmdlets that run in the remote session on the remote Exchange server don't have access to your
local file system. This means that you can't use Exchange cmdlets, on their own, to import or export files from or to
your local file system. Additional syntax needs to be used to transfer the files to and from your local file system so
that the Exchange cmdlets running on the remote Exchange server can use the data. For more information about
the required syntax, see "Importing and exporting files in remote Shell" later in this topic.

Importing and exporting files in remote Shell

Importing and exporting files requires a specific syntax because Mailbox and Client Access servers use remote
Shell and don't have access to the local computer's file system.

Importing files in remote Shell

The syntax to import files in Exchange 2013 is used any time you want to send a file to a cmdlet running on an
Exchange 2013 server from your local computer or server. Cmdlets that accept data from a file on your local
computer will have a parameter called FileData (or something similar). To determine the correct parameter to use,
see the Help information for the cmdlet you're using.
The Shell must know what file you want to send to the Exchange 2013 cmdlet, and what parameter will accept the
data. To do so, use the following syntax.

<Cmdlet> -FileData ([Byte[]]$(Get-Content -Path <local path to file> -Encoding Byte -ReadCount 0))

For example, the following command imports the file C:\MyData.dat into the FileData parameter on the Import-
SomeData fictional cmdlet.

Import-SomeData -FileData (Byte[]]$(Get-Content -Path "C:\MyData.dat" -Encoding Byte -ReadCount 0))

The following actions occur when the command is run:

1. The command is accepted by remote Shell.
2. Remote Shell evaluates the command and determines that there's an embedded command in the value
being provided to the FileData parameter.
3. Remote Shell stops evaluating the Import-SomeData command and runs the Get-Content command.
The Get-Content command reads the data from the MyData.dat file.
4. Remote Shell temporarily stores the data from the Get-Content command as a Byte[] object so that it can
be passed to the Import-SomeData cmdlet.
5. Execution of the Import-SomeData command resumes. Remote Shell sends the request to run the
Import-SomeData cmdlet to the remote Exchange 2013 server, along with the object created by the Get-
Content cmdlet.
6. On the remote Exchange 2013 server, the Import-SomeData cmdlet is run, and the data stored in the
temporary object created by the Get-Content cmdlet is passed to the FileData parameter. The Import-
SomeData cmdlet processes the input and performs whatever actions are required.
Some cmdlets use the following alternate syntax that accomplishes the same thing as the preceding syntax.

[Byte[]]$Data = Get-Content -Path <local path to file> -Encoding Byte -ReadCount 0

Import-SomeData -FileData $Data

The same process happens with this alternate syntax. The only difference is instead of performing the entire
operation at once, the data retrieved from the local file is stored in a variable that can be referenced after it's
created. The variable is then used in the import command to pass the contents of the local file to the Import-
SomeData cmdlet. Using this two-step process is useful when you want to use the data from the local file in more
than one command.
There are limitations that you must consider when importing files. For more information, see "Limitations on
importing files" later in this topic.
For specific information about how to import data into Exchange 2013, see the Help topics for the feature you're
managing.

Limitations on importing files

Limits must be set when importing data in remote Shell to preserve the integrity of the data that's being
transferred. Transfers that are in progress can't be resumed if they're interrupted. Also, because data being
transferred is stored in the remote server's memory, the server must be protected from memory exhaustion
caused by excessively large amounts of data.
For these reasons, the amount of data that's transferred to a remote Exchange 2013 server from a local computer
or server is limited to the following:
500 megabytes (MB ) for each cmdlet that's run
75 MB for each object that's passed to a cmdlet
If you exceed either of the limits, the execution of the cmdlet and its associated pipeline will stop and you'll receive
an error. Consider the examples in the following table to understand how these limits work.
Import data limit examples
NUMBER OF OBJECTS OBJECT SIZE (MB) TOTAL SIZE (MB) RESULT OF OPERATION

10 40 400 The operation is

successful because
neither the size of the
individual objects
exceeds 75 MB nor the
total amount of data
passed to the cmdlet
exceeds 500 MB.

5 80 400 The operation fails

because, although the
total amount of data
passed to the cmdlet is
only 400 MB, the size of
each individual object
exceeds the 75 MB limit.

120 5 600 The operation fails

because, although each
individual object is only
5 MB, the total amount
of data passed to the
cmdlet exceeds the
500 MB limit.

Due to the size limits that have been placed on the amount of data that can be transferred between a remote
Exchange 2013 server and a local computer, not all cmdlets that once supported importing support this method of
data transfer. To determine whether a specific cmdlet supports this method, see the Help information for the
specific cmdlet.
These limits should accommodate the majority of typical operations that can be performed on an Exchange 2013
server. If the limits are lowered, you may find that some normal operations fail because they exceed the new limits.
If the limits are raised, the data being transferred could take longer to transfer and become more at risk to
transient conditions that interrupt the data transfer. Also, you may exhaust the memory on the remote server if you
haven't installed enough memory to allow the server to store the entire block of data during transfer. Each
possibility could result in data loss and therefore we recommend you don't change the default limits.

Exporting files in remote Shell

The syntax to export files in Exchange 2013 is used any time you want to accept data from a cmdlet running on a
remote Exchange 2013 server and store the data on your local computer or server. Cmdlets that provide data that
you can save to a local file will output an object that will contain the FileData property (or something similar).
Depending on the cmdlet, the FileData property is only populated on the object that's output in specific situations.
To determine the correct property to use and when it can be used, see the Help information for the cmdlet you're
using.
The Shell must know that you want to save the data stored in the FileData property to your local computer. To do
so, use the following syntax.

<cmdlet> | ForEach {<cmdlet> | ForEach {$_.FileData | Add-Content <local path to file> -Encoding
Byte}.FileData | Add-Content <local path to file> -Encoding Byte}

For example, the following command exports the data stored in the FileData property on the object created by the
Export-SomeData fictional cmdlet. The exported data is stored in a file you specify on the local computer, in this
case MyData.dat.

NOTE
This procedure uses the ForEach cmdlet, objects, and pipelining. For more information about each, see Pipelining and
Structured data.

Export-SomeData | ForEach {Export-SomeData | ForEach {$_.FileData | Add-Content C:\MyData.dat -Encoding

Byte}.FileData | Add-Content C:\MyData.dat -Encoding Byte}

The following actions occur when the command is run:

1. The command is accepted by remote Shell.
2. Remote Shell calls the Export-SomeData cmdlet on the remote Exchange 2013 server.
3. The output object created by the Export-SomeData cmdlet is passed back to the local Shell session via the
pipeline.
4. The output object is then piped to the ForEach cmdlet, which has a script block.
5. Within the script block, the FileData property on the current object in the pipeline is accessed. The data
contained within the FileData property is piped to the Add-Content cmdlet.
6. The Add-Content cmdlet saves the data piped from the FileData property to the file MyData.dat on the
local file system.
For specific information about how to export data from Exchange 2013, see the Help topics for the feature you're
managing.
 Modifying multivalued properties
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

A multivalued property is a property that can contain more than one value. For example, the BlockedRecipients
property on the RecipientFilterConfig object can accept multiple recipient addresses as in the following
examples:
[email protected]
[email protected]
[email protected]
Because the BlockedRecipients property can accept more than one value, it's called a multivalued property. This
topic explains how to use the Exchange Management Shell to add values to and remove values from a multivalued
property on an object.
For more information about objects, see Structured data. For more information about the Shell, see Using
PowerShell with Exchange 2013 (Exchange Management Shell).

Modifying a multivalued property vs. modifying a property that accepts

only a single value
How you modify a multivalued property is slightly different from how you modify a property that accepts only one
value. When you modify a property that accepts only a single value, you can assign a value directly to it, as in the
following command.

Set-TransportConfig -MaxSendSize 12MB

When you use this command to provide a new value to the MaxSendSize property, the stored value is
overwritten. This isn't a problem with properties that accept only one value. However, it becomes a problem with
multivalued properties. For example, assume that the BlockedRecipients property on the RecipientFilterConfig
object is configured to have the three values that are listed in the previous section. When you run the command
Get-RecipientFilterConfig | Format-List BlockedRecipients , the following is displayed.

BlockedRecipients : {[email protected], [email protected], [email protected]}

Now assume that you've received a request to add a new SMTP address to the blocked recipients list. You run the
following command to add the new SMTP address.

Set-RecipientFilterConfig -BlockedRecipients [email protected]

When you run the Get-RecipientFilterConfig | Format-List BlockedRecipients command again, you will see the
following.

BlockedRecipients : {[email protected]}
This isn't what you expected. You wanted to add the new SMTP address to the existing list of blocked recipients,
but instead the existing list of blocked recipients was overwritten by the new SMTP address. This unintended
result exemplifies how modifying a multivalued property differs from modifying a property that accepts only a
single value. When you modify a multivalued property, you must make sure that you append or remove values
instead of overwriting the whole list of values. The following sections show you how to do exactly that.

Modifying multivalued properties

Modifying multivalued properties is similar to modifying single-valued properties. You just need to add some
additional syntax to tell the Shell that you want to add or remove values to or from the multivalued property rather
than replace everything that's stored in the property. The syntax is included, along with the value or values to add
or remove to or from the property, as a value on a parameter when you run a cmdlet. The following table shows
the syntax that you need to add to a parameter on a cmdlet to modify multivalued properties.
Multivalue property syntax
ACTION SYNTAX

Add one or more values to a multivalued property

@{Add="<value1>", "<value2>", "<value3>"}

Remove one or more values from a multivalued property

@{Remove="<value1>", "<value2>", "<value3>"}

The syntax that you choose from the Multivalue property syntax table is specified as a parameter value on a
cmdlet. For example, the following command adds multiple values to a multivalued property:

Set-ExampleCmdlet -Parameter @{Add="Red", "Blue", "Green"}

When you use this syntax, the values that you specify are added or removed from the list of values already present
on the property. Taking the BlockedRecipients example earlier in this topic, we can now add [email protected]
without overwriting the rest of the values on this property by using the following command:

Set-RecipientFilterConfig -BlockedRecipients @{Add="[email protected]"}

If you wanted to remove [email protected] from the list of values, you would use this command:

Set-RecipientFilterConfig -BlockedRecipients @{Remove="[email protected]"}

More complex combinations can be used, such as adding or removing values to and from a property at the same
time. To do so, insert a semicolon ( ; ) between Add and Remove actions. For example:

Set-RecipientFilterConfig -BlockedRecipients @{Add="[email protected]", "[email protected]",

"[email protected]"; Remove="[email protected]"}

If we use the Get-RecipientFilterConfig | Format-List BlockedRecipients command again, we can see that the
email addresses for Carter, Sam, and Brian have been added while the address for John has been removed.
BlockedRecipients : {[email protected], [email protected], [email protected], [email protected],
[email protected]}
 WhatIf, Confirm, and ValidateOnly switches
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Both experienced administrators and script writers, and administrators who are new to Exchange and scripting,
can benefit from using the WhatIf, Confirm, and ValidateOnly switches. These switches let you control how your
commands run and indicate exactly what a command will do before it affects data. This functionality is quite
valuable as you transition from your test environment into your production environment and as you roll out new
scripts or commands.
The WhatIf, Confirm, and ValidateOnly switches are especially useful when you use them with commands that
modify objects that are returned by using a filter or by using a Get command in a pipeline. This topic describes
each switch and also provides an example command for each switch.

IMPORTANT
If you want to use the WhatIf, Confirm, and ValidateOnly switches with commands in a script, you must add the
appropriate switch to each command in the script, and not on the command line that calls the script.

NOTE
WhatIf, Confirm, and ValidateOnly are called switch parameters. For more information about switch parameters, see
Parameters.

WhatIf switch
The WhatIf switch instructs the command to which it is applied to run but only to display the objects that would
be affected by running the command and what changes would be made to those objects. The switch does not
actually change any of those objects. When you use the WhatIf switch, you can see whether the changes that
would be made to those objects match your expectations, without the worry of modifying those objects.
When you run a command together with the WhatIf switch, you put the WhatIf switch at the end of the command,
as in the following example:

New-AcceptedDomain -Name "Contoso Domain" -DomainName "contoso.com" -WhatIf

When you run this example command, the following text is returned by the Shell:

What if: Creating Accepted Domain "Contoso Domain" with domain name "contoso.com".

Confirm switch
The Confirm switch instructs the command to which it is applied to stop processing before any changes are made.
The command then prompts you to acknowledge each action before it continues. When you use the Confirm
switch, you can step through changes to objects to make sure that changes are made only to the specific objects
that you want to change. This functionality is useful when you apply changes to many objects and want precise
control over the operation of the Shell. A confirmation prompt is displayed for each object before the Shell
modifies the object.
By default, the Shell automatically applies the Confirm switch to cmdlets that have the following verbs:
Clear
Disable
Dismount
Move
Remove
Stop
Suspend
Uninstall
When a cmdlet runs that has any of these verbs, the Shell automatically stops the command and waits for your
acknowledgement before it continues to process.
If you want to manually apply the Confirm switch to a command, include the Confirm switch at the end of the
command, as in the following example:

Get-JournalRule | Enable-JournalRule -Confirm

When you run this example command, the following confirmation prompt is returned by the Shell:

Confirm
Are you sure you want to perform this action?
Enabling journal rule "Litigation Journal Rule".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

The confirmation prompt gives you the following choices:

[Y ] Yes: Type Y to instruct the command to continue the operation. The next operation will present another
confirmation prompt. [Y] Yes is the default choice.
[A ] Yes to All: Type A to instruct the command to continue the operation and all subsequent operations.
You will not receive additional confirmation prompts for the duration of this command.
[N ] No: Type N to instruct the command to skip this operation and continue with the next operation. The
next operation will present another confirmation prompt.
[L ] No to All: Type L to instruct the command to skip this operation and all subsequent operations.
[S ] Suspend: Type S to pause the current pipeline and return to the command line. Type Exit to resume
the pipeline.
[?] Help: Type ? to display confirmation prompt Help on the command line.

If you want to override the default behavior of the Shell and suppress the confirmation prompt for cmdlets on
which it is automatically applied, you can include the Confirm switch with a value of $False , as in the following
example:

Get-JournalRule | Disable-JournalRule -Confirm:$False

In this case, no confirmation prompt is displayed.

WARNING
The default value of the Confirm switch is $True . The default behavior of the Shell is to automatically display a confirmation
prompt. If you suppress this default behavior, you instruct the command to suppress all confirmation prompts for the
duration of that command. The command will process all objects that meet the criteria for the command without
confirmation.

ValidateOnly switch
The ValidateOnly switch instructs the command to which it is applied to evaluate all the conditions and
requirements that are needed to perform the operation before you apply any changes. The ValidateOnly switch is
available on cmdlets that may take a long time to run, have several dependencies on multiple systems, or affect
critical data, such as mailboxes.
When you apply the ValidateOnly switch to a command, the command runs through the whole process. The
command performs each action as it would without the ValidateOnly switch. But the command doesn't change
any objects. When the command completes its process, it displays a summary with the results of the validation. If
the validation indicates that the command was successful, you can run the command again without the
ValidateOnly switch.
When you run a command together with the ValidateOnly switch, you put the ValidateOnly switch at the end of
the command.
 Working with command output
6/14/2019 • 13 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Exchange Management Shell offers several methods that you can use to format command output. This topic
discusses the following subjects:
How to format data Control how the data that you see is formatted by using the Format-List, Format-
Table, and Format-Wide cmdlets.
How to output data Determine whether data is output to the Shell console window or to a file by using
the Out-Host and Out-File cmdlets. Included in this topic is a sample script to output data to
Microsoft Internet Explorer.
How to filter data Filter data by using either of the following filtering methods:
Server-side filtering, available on certain cmdlets.
Client-side filtering, available on all cmdlets by piping the results of a command to the Where-
Object cmdlet.
To use the functionality that is described in this topic, you must be familiar with the following concepts:
Pipelining
Shell variables
Comparison operators

How to format data

If you call formatting cmdlets at the end of the pipeline, you can override the default formatting to control what
data is displayed and how that data appears. The formatting cmdlets are Format-List, Format-Table, and
Format-Wide. Each has its own distinct output style that differs from the other formatting cmdlets.

Format-List
The Format-List cmdlet takes input from the pipeline and outputs a vertical columned list of all the specified
properties of each object. You can specify which properties you want to display by using the Property parameter.
If the Format-List cmdlet is called without any parameters specified, all properties are output. The Format-List
cmdlet wraps lines instead of truncating them. One of the best uses for the Format-List cmdlet is to override the
default output of a cmdlet so that you can retrieve additional or more focused information.
For example, when you call the Get-Mailbox cmdlet, you only see a limited amount of information in table
format. If you pipe the output of the Get-Mailbox cmdlet to the Format-List cmdlet and add parameters for the
additional or more focused information that you want to view, you can retrieve the output that you want.
You can also specify a wildcard character "*" with a partial property name. If you include a wildcard character, you
can match multiple properties without having to type each property name individually. For example,
Get-Mailbox | Format-List -Property Email* returns all properties that begin with Email .

The following examples show the different ways that you can view the same data returned by the Get-Mailbox
cmdlet.
 Get-Mailbox TestUser1

Name Alias ServerName ProhibitSendQuota

---- ----- ---------- ---------------
TestUser1 TestUser1 mbx unlimited

In the first example, the Get-Mailbox cmdlet is called without specific formatting so the default output is in table
format and contains a predetermined set of properties.

Get-Mailbox TestUser1 | Format-List -Property Name,Alias,EmailAddresses

Name : TestUser1
Alias : TestUser1
EmailAddresses : {SMTP:[email protected]}

In the second example, the output of the Get-Mailbox cmdlet is piped to the Format-List cmdlet, together with
specific properties. As you can see, the format and content of the output is significantly different.

Get-Mailbox TestUser1 | Format-List -Property Name, Alias, Email*

Name : Test User
Alias : TestUser1
EmailAddresses : {SMTP:[email protected]}
EmailAddressPolicyEnabled : True

In the last example, the output of the Get-Mailbox cmdlet is piped to the Format-List cmdlet as in the second
example. However, in the last example, a wildcard character is used to match all properties that start with Email .
If more than one object is passed to the Format-List cmdlet, all specified properties for an object are displayed
and grouped by object. The display order depends on the default parameter for the cmdlet. The default
parameter is most frequently the Name parameter or the Identity parameter. For example, when the Get-
Childitem cmdlet is called, the default display order is file names in alphabetical order. To change this behavior,
you must call the Format-List cmdlet, together with the GroupBy parameter, and the name of a property value
by which you want to group the output. For example, the following command lists all files in a directory and then
groups these files by extension.
 Get-Childitem | Format-List Name,Length -GroupBy Extension

Extension: .xml

Name : Config_01.xml
Length : 5627

Name : Config_02.xml
Length : 3901

Extension: .bmp

Name : Image_01.bmp
Length : 746550

Name : Image_02.bmp
Length : 746550

Extension: .txt

Name : Text_01.txt
Length : 16822

Name : Text_02.txt
Length : 9835

In this example, the Format-List cmdlet has grouped the items by the Extension property that is specified by the
GroupBy parameter. You can use the GroupBy parameter with any valid property for the objects in the pipeline
stream.

Format-Table
The Format-Table cmdlet lets you display items in a table format with label headers and columns of property
data. By default, many cmdlets, such as the Get-Process and Get-Service cmdlets, use the table format for
output. Parameters for the Format-Table cmdlet include the Properties and GroupBy parameters. These
parameters work exactly as they do with the Format-List cmdlet.
The Format-Table cmdlet also uses the Wrap parameter. This parameter enables long lines of property
information to display completely instead of truncating at the end of a line. To see how the Wrap parameter is
used to display returned information, compare the output of the Get-Command command in the following two
examples.
In the first example, when the Get-Command cmdlet is used to display command information about the Get-
Process cmdlet, the information for the Definition property is truncated.

Get-Command Get-Process | Format-Table Name,Definition

Name Definition
---- ----------
get-process get-process [[-ProcessName] String[]...

In the second example, the Wrap parameter is added to the command to force the complete contents of the
Definition property to display.
 Get-Command Get-Process | Format-Table Name,Definition -Wrap

Get-Process Get-Process [[-Name] <String[]>] [-Comp

uterName <String[]>] [-Module] [-FileVe
rsionInfo] [-Verbose] [-Debug] [-ErrorA
ction <ActionPreference>] [-WarningActi
on <ActionPreference>] [-ErrorVariable
<String>] [-WarningVariable <String>] [
-OutVariable <String>] [-OutBuffer <Int
32>]
Get-Process -Id <Int32[]> [-ComputerNam
e <String[]>] [-Module] [-FileVersionIn
fo] [-Verbose] [-Debug] [-ErrorAction <
ActionPreference>] [-WarningAction <Act
ionPreference>] [-ErrorVariable <String
>] [-WarningVariable <String>] [-OutVar
iable <String>] [-OutBuffer <Int32>]
Get-Process [-ComputerName <String[]>]
[-Module] [-FileVersionInfo] -InputObje
ct <Process[]> [-Verbose] [-Debug] [-Er
rorAction <ActionPreference>] [-Warning
Action <ActionPreference>] [-ErrorVaria
ble <String>] [-WarningVariable <String
>] [-OutVariable <String>] [-OutBuffer
<Int32>]

As with the Format-List cmdlet, you can also specify a wildcard character " * " with a partial property name. By
including a wildcard character, you can match multiple properties without typing each property name
individually.

Format-Wide
The Format-Wide cmdlet provides a much simpler output control than the other format cmdlets. By default, the
Format-Wide cmdlet tries to display as many columns of property values as possible on a line of output. By
adding parameters, you can control the number of columns and how the output space is used.
In the most basic usage, calling the Format-Wide cmdlet without any parameters arranges the output in as
many columns as will fit the page. For example, if you run the Get-Childitem cmdlet and pipe its output to the
Format-Wide cmdlet, you will see the following display of information:

Get-ChildItem | Format-Wide

Directory: FileSystem::C:\WorkingFolder

Config_01.xml Config_02.xml
Config_03.xml Config_04.xml
Config_05.xml Config_06.xml
Config_07.xml Config_08.xml
Config_09.xml Image_01.bmp
Image_02.bmp Image_03.bmp
Image_04.bmp Image_05.bmp
Image_06.bmp Text_01.txt
Text_02.txt Text_03.txt
Text_04.txt Text_05.txt
Text_06.txt Text_07.txt
Text_08.txt Text_09.txt
Text_10.txt Text_11.txt
Text_12.txt

Generally, calling the Get-Childitem cmdlet without any parameters displays the names of all files in the
directory in a table of properties. In this example, by piping the output of the Get-Childitem cmdlet to the
Format-Wide cmdlet, the output was displayed in two columns of names. Notice that only one property type
can be displayed at a time, specified by a property name that follows the Format-Wide cmdlet. If you add the
Autosize parameter, the output is changed from two columns to as many columns as can fit the screen width.

Get-ChildItem | Format-Wide -AutoSize

Directory: FileSystem::C:\WorkingFolder

Config_01.xml Config_02.xml Config_03.xml Config_04.xml Config_05.xml

Config_06.xml Config_07.xml Config_08.xml Config_09.xml Image_01.bmp
Image_02.bmp Image_03.bmp Image_04.bmp Image_05.bmp Image_06.bmp
Text_01.txt Text_02.txt Text_03.txt Text_04.txt Text_05.txt
Text_06.txt Text_07.txt Text_08.txt Text_09.txt Text_10.txt
Text_11.txt Text_12.txt

In this example, the table is arranged in five columns, instead of two columns. The Column parameter offers
more control by letting you specify the maximum number of columns to display information as follows:

Get-ChildItem | Format-Wide -Column 4

Directory: FileSystem::C:\WorkingFolder

Config_01.xml Config_02.xml Config_03.xml Config_04.xml

Config_05.xml Config_06.xml Config_07.xml Config_08.xml
Config_09.xml Image_01.bmp Image_02.bmp Image_03.bmp
Image_04.bmp Image_05.bmp Image_06.bmp Text_01.txt
Text_02.txt Text_03.txt Text_04.txt Text_05.txt
Text_06.txt Text_07.txt Text_08.txt Text_09.txt
Text_10.txt Text_11.txt Text_12.txt

In this example, the number of columns is forced to four by using the Column parameter.

How to output data

Out-Host and Out-File cmdlets
The Out-Host cmdlet is an unseen default cmdlet at the end of the pipeline. After all formatting is applied, the
Out-Host cmdlet sends the final output to the console window for display. You don't have to explicitly call the
Out-Host cmdlet, because it's the default output. You can override sending the output to the console window by
calling the Out-File cmdlet as the last cmdlet in the command. The Out-File cmdlet then writes the output to the
file that you specify in the command as in the following example:

Get-ChildItem | Format-Wide -Column 4 | Out-File c:\OutputFile.txt

In this example, the Out-File cmdlet writes the information that is displayed in the Get-ChildItem | Format-
Wide -Column 4 command to a file that is named OutputFile.txt . You can also redirect pipeline output to a file
by using the redirection operator, which is the right-angle bracket ( > ). To append pipeline output of a
command to an existing file without replacing the original file, use the double right-angle brackets ( >> ), as in
the following example:

Get-ChildItem | Format-Wide -Column 4 >> C:\OutputFile.txt

In this example, the output from the Get-Childitem cmdlet is piped to the Format-Wide cmdlet for formatting
and then is written to the end of the OutputFile.txt file. Notice that if the OutputFile.txt file didn't exist, use of
the double right-angle brackets ( >> ) would create the file.
For more information about pipelines, see Pipelining.
For more information about the syntax used in the previous examples, see Syntax.

Viewing data in Internet Explorer

Because of the flexibility and ease of scripting in the Exchange Management Shell, you can take the data that is
returned by commands and format and output them in almost limitless ways.
The following example shows how you can use a simple script to output the data that is returned by a command
and display it in Internet Explorer. This script takes the objects that are passed through the pipeline, opens an
Internet Explorer window, and then displays the data in Internet Explorer:

$Ie = New-Object -Com InternetExplorer.Application

$Ie.Navigate("about:blank")
While ($Ie.Busy) { Sleep 1 }
$Ie.Visible = $True
$Ie.Document.Write("$Input")
# If the previous line doesn't work on your system, uncomment the line below.
# $Ie.Document.IHtmlDocument2_Write("$Input")
$Ie

To use this script, save it to the C:\Program Files\Microsoft\Exchange Server\V15\Scripts directory on the
computer where the script will be run. Name the file Out-Ie.ps1 . After you save the file, you can then use the
script as a regular cmdlet.

NOTE
To run scripts in Exchange 2013, scripts must be added to an unscoped management role and you must be assigned the
management role either directly or through a management role group. For more information, see Understanding
management roles.

The Out-Ie script assumes that the data it receives is valid HTML. To convert the data that you want to view into
HTML, you must pipe the results of your command to the ConvertTo-Html cmdlet. You can then pipe the
results of that command to the Out-Ie script. The following example shows how to view a directory listing in an
Internet Explorer window:

Get-ChildItem | Select Name,Length | ConvertTo-Html | Out-Ie

How to filter data

The Shell gives you access to a large quantity of information about your servers, mailboxes, Active Directory, and
other objects in your organization. Although access to this information helps you better understand your
environment, this much information can be overwhelming. The Shell lets you control this information and return
only the data that you want to see by using filtering. The following types of filtering are available:
Server-side filtering: Server-side filtering takes the filter that you specify on the command line and
submits it to the Exchange server that you query. That server processes the query and returns only the
data that matches the filter that you specified.
Server-side filtering is performed only on objects where tens or hundreds of thousands of results could be
returned. Therefore, only the recipient management cmdlets, such as the Get-Mailbox cmdlet, and queue
management cmdlets, such as the Get-Queue cmdlet, support server-side filtering. These cmdlets
support the Filter parameter. This parameter takes the filter expression that you specify and submits it to
 the server for processing.
Client-side filtering: Client-side filtering is performed on the objects in the local console window in
which you are currently working. When you use client-side filtering, the cmdlet retrieves all the objects
that match the task that you are performing to the local console window. The Shell then takes all the
returned results, applies the client-side filter to those results, and returns to you only the results that
match your filter. All cmdlets support client-side filtering. This is invoked by piping the results of a
command to the Where-Object cmdlet.

Server-side filtering
The implementation of server-side filtering is specific to the cmdlet on which it is supported. Server-side filtering
is enabled only on specific properties on the objects that are returned. For more information, see the Help for the
following cmdlets:

Get- Get- Get-CASMailbox Get-Contact Get-

ActiveSyncDevice ActiveSyncDevice DistributionGrou
Class p

Get- Get-Group Get-Mailbox Get- Get-MailContact

DynamicDistributi MailboxStatistics
onGroup

Get- Get-MailUser Get-Message Get- Get-Queue

MailPublicFolder MobileDevice

Get-QueueDigest Get-Recipient Get- Get-RoleGroup Get-

RemoteMailbox SecurityPrincipal

Get- Get-UMMailbox Get-User Get-UserPhoto Remove-

StoreUsageStatist Message
ics

Resume-Message Resume-Queue Retry-Queue Suspend- Suspend-Queue

Message

Client-side filtering
Client-side filtering can be used with any cmdlet. This capability includes those cmdlets that also support server-
side filtering. As described earlier in this topic, client-side filtering accepts all the data that is returned by a
previous command in the pipeline, and in turn, returns only the results that match the filter that you specify. The
Where-Object cmdlet performs this filtering. It can be shortened to Where.
As data passes through the pipeline, the Where cmdlet receives the data from the previous object and then
filters the data before passing it on to the next object. The filtering is based on a script block that is defined in the
Where command. The script block filters data based on the object's properties and values.
The Clear-Host cmdlet is used to clear the console window. In this example, you can find all the defined aliases
for the Clear-Host cmdlet if you run the following command:
 Get-Alias | Where {$_.Definition -eq "Clear-Host"}

CommandType Name Definition

----------- ---- ----------
Alias clear clear-host
Alias cls clear-host

The Get-Alias cmdlet and the Where command work together to return the list of aliases that are defined for
the Clear-Host cmdlet and no other cmdlets. The following table outlines each element of the Where command
that is used in the example.
Elements of the Where command
ELEMENT DESCRIPTION

{ } Braces enclose the script block that defines the filter.

$_ This special variable automatically initiates and binds to

the objects in the pipeline.

Definition The Definition property is the property of the current

pipeline objects that stores the name of the alias
definition. When Definition is used with the $_
variable, a period comes before the property name.

-eq This comparison operator for "equal to" is used to specify

that the results must exactly match the property value
that is supplied in the expression.

"Clear-Host" In this example, "Clear-Host" is the value for which the

command is parsing.

In the example, the objects that are returned by the Get-Alias cmdlet represent all the defined aliases on the
system. Even though you don't see them from the command line, the aliases are collected and passed to the
Where cmdlet through the pipeline. The Where cmdlet uses the information in the script block to apply a filter
to the alias objects.
The special variable $ _represents the objects that are being passed. The $_ variable is automatically initiated by
the Shell and is bound to the current pipeline object. For more information about this special variable, see Shell
variables.
Using standard "dot" notation (object.property), the Definition property is added to define the exact property of
the object to evaluate. The -eq comparison operator then compares the value of this property to "Clear-Host" .
Only the objects that have the Definition property that match this criterion are passed to the console window
for output. For more information about comparison operators, see Comparison operators.
After the Where command has filtered the objects returned by the Get-Alias cmdlet, you can pipe the filtered
objects to another command. The next command processes only the filtered objects returned by the Where
command.
 Cmdlet extension agents
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

Cmdlet extension agents are components in Microsoft Exchange Server 2013 invoked by Exchange 2013 cmdlets
when the cmdlets run. As the name implies, cmdlet extension agents extend the capabilities of the cmdlets that
invoke them by assisting in processing data or performing additional actions based on the requirements of the
cmdlet. Cmdlet extension agents are available on any server role.
Agents can modify, replace, or extend functionality of Exchange Management Shell cmdlets. An agent can provide
a value for a required parameter that isn't provided on a command, override a value provided by a user, perform
other actions outside of the cmdlet workflow while a cmdlet runs, and more.
For example, the New-Mailbox cmdlet accepts the Database parameter that specifies the mailbox database in
which to create a new mailbox. In Microsoft Exchange Server 2007, if you don't specify the Database parameter
when you run the New-Mailbox cmdlet, the command fails. However, in Exchange 2013, the New-Mailbox
cmdlet invokes the Mailbox Resources Management agent when the cmdlet runs. If the Database parameter isn't
specified, the Mailbox Resources Management agent automatically determines a suitable mailbox database on which
to create the new mailbox and inserts that value into the Database parameter.
Cmdlet extension agents can only be invoked by Exchange 2013 and Microsoft Exchange Server 2010 cmdlets.
Exchange 2007 cmdlets and cmdlets provided by other Microsoft and third-party products can't invoke cmdlet
extension agents. Scripts also can't invoke cmdlet extension agents directly. However, if scripts contain Exchange
2013 cmdlets, those cmdlets continue to call the cmdlet extension agents.
Looking for management tasks related to cmdlet extension agents? See Manage cmdlet extension agents.

Agent priority
The priority of an agent determines the order in which the agent is invoked while a cmdlet runs. An agent that has
a higher priority, closer to zero, is invoked first. The priority of an agent becomes important when two or more
agents attempt to set the value of the same property. The highest priority agent that attempts to set a property
value succeeds, and all subsequent attempts to set the same property by lower priority agents are ignored. For
example, if the Name property on an object is modified by an agent with a priority of 3 and another agent with a
priority of 6 modifies the same object, the modification made by the agent with a priority of 6 is ignored.
If you want to use the Scripting agent to set the value of properties that might be set by other, higher priority
agents, you have the following options:
Disable the agent that currently sets the property.
Set the Scripting agent to a priority higher than the existing agent you want to replace.
Keep the priorities of the agents the same and make sure that the script that runs under the
Scripting agent respects the value provided by the other agents.

WARNING
Changing the priority or replacing the functionality of a built-in agent is an advanced operation. Be sure that you completely
understand the changes you're making.
For more information about changing the priority of an agent, see Manage cmdlet extension agents.

Built-in agents
Exchange 2013 includes several agents that can be invoked when a cmdlet runs. The following table lists the
agents, their order, and whether the agents are enabled by default. You can't add or remove agents to or from a
server running Exchange 2013. However, you can use the Scripting agent to run Windows PowerShell scripts to
extend the functionality of the cmdlets that use it. For more information about the Scripting agent , see the
"Scripting agent" section later in this topic.
You can enable or disable most agents or change the priority of the agents if you want to replace the functionality
of a specific agent with functionality you provide in a custom script that you call using the Scripting agent .
However, some agents can't be disabled. Agents that can't be disabled are called system agents and have their
IsSystem property set to $True . The following table provides information about Exchange 2013 cmdlet extension
agents, including system agents.
The configuration for agents is stored at the organization level. When you enable or disable an agent, or set its
priority, you set that agent configuration across every server in the organization. The exception is adding scripts to
the Scripting agent . You must update the scripts on each server individually. For more information about
configuring scripts for use with the Scripting agent , see the "Scripting agent" section later in this topic.

WARNING
Changing the priority of agents, or enabling or disabling agents, can cause unintended effects if you don't completely
understand what each agent does and how they interact with Exchange cmdlets. Before you change the configuration of any
agent, be sure you fully understand the changes and results you want and that you verify that your custom script will work
as intended.

Exchange 2013 cmdlet extension agents

AGENT NAME PRIORITY ENABLED BY DEFAULT SYSTEM AGENT

Admin Audit Log 255 True Yes

agent

Scripting agent 6 False No

Mailbox Resources 5 True No

Management agent

OAB Resources 4 True No

Management agent

Query Base DN agent 3 True No

Provisioning Policy 2 True No

agent

Rus agent 1 True No

 AGENT NAME PRIORITY ENABLED BY DEFAULT SYSTEM AGENT

Mailbox Creation 0 True No

Time agent

Scripting agent
You can use the Scripting agent cmdlet extension agent in Exchange 2013 to insert your own scripting logic into
the execution of Exchange cmdlets. Using the Scripting agent , you can add conditions, override values, and set
up reporting.

WARNING
When you enable the Scripting agent cmdlet extension agent, the agent is invoked every time a cmdlet is run on a
server running Exchange 2013. This includes not only cmdlets run directly by you in the Exchange Management Shell, but
also cmdlets run by Exchange services, and the Exchange admin center (EAC). We strongly recommend that you test your
scripts and any changes you make to the configuration file before you copy your updated configuration file to your
Exchange 2013 servers and enable the Scripting agent cmdlet extension agent.

Every time an Exchange cmdlet is run, the cmdlet invokes the Scripting agent cmdlet extension agent. When this
agent is invoked, the cmdlet checks whether any scripts are configured to be invoked by the cmdlet. If a script
should be run for a cmdlet, the cmdlet tries to invoke any APIs defined in the script. The following APIs are
available and are invoked in the following order:
1. ProvisionDefaultProperties: This API can be used to set values of properties on objects when they're
created. When you set a value, that value is returned to the cmdlet and the cmdlet sets the value on the
property. You can fill in values on properties if the user didn't specify a value, or you can override the value
specified by the user. This API respects the values set by higher priority agents. The Scripting agent
cmdlet extension agent won't overwrite the values set by higher priority agents.
2. UpdateAffectedIConfigurable: This API can be used to set values of properties on objects after all other
processing has been completed, but the Validate API hasn't yet been invoked. This API respects the values
set by higher priority agents. The Scripting agent cmdlet extension agent won't overwrite the values set
by higher priority agents.
3. Validate: This API can be used to validate the values on an object's properties that are about to be set by
the cmdlet. This API is called just before a cmdlet writes any data. You can configure validation checks that
allow a cmdlet to either succeed or fail. If a cmdlet passes the validation checks in this API, the cmdlet is
allowed to write the data. If the cmdlet fails the validation checks, it returns any errors defined in this API.
4. OnComplete: This API is used after all cmdlet processing is complete. It can be used to perform post-
processing tasks, such as writing data to an external database.

NOTE
The Scripting agent cmdlet extension agent isn't invoked when cmdlets with the Get verb are run.

Scripting agent configuration file

The Scripting agent configuration file contains all the scripts that you want the Scripting agent to run. Scripts in
the configuration file are contained within XML tags that define the beginning and end of the script and various
input parameters required to pass data to the script. Scripts are written using Windows PowerShell syntax. The
configuration file is an XML file that uses the elements or attributes in the following table.
Attributes of Scripting agent configuration file
ELEMENT ATTRIBUTE DESCRIPTION

Configuration Not applicable This element contains all the scripts

that the Scripting agent cmdlet
extension agent can run. The
Feature tag is a child of this tag.

There is only one Configuration

tag in the configuration file.

Feature Not applicable This element contains a set of

scripts that relate to a feature. Each
script, defined in the ApiCall
child tag, extends a specific part of
the cmdlet execution pipeline. This
tag contains the Name and
Cmdlets attributes.

There can be multiple Feature

tags under the Configuration
tag.

Name This attribute contains the name of

the feature. Use this attribute to
help identify which feature is
extended by the scripts contained
within the tag.

Cmdlets This attribute contains a list of the

Exchange cmdlets used by the set
of scripts in this feature extension.
You can specify multiple cmdlets by
separating each cmdlet with a
comma.

ApiCall Not applicable This element contains scripts that

can extend a part of the cmdlet
execution pipeline. Each script is
defined by the API call name in the
cmdlet execution pipeline it's
extending. The following are the
API names that can be extended:

ProvisionDefaultProperties

UpdateAffectedIConfigurable

Validate

OnComplete
 ELEMENT ATTRIBUTE DESCRIPTION

Name This attribute includes the name of

the API call that's extending the
cmdlet execution pipeline.

Common Not applicable This element contains functions

that can be used by any script in
the configuration file.

Every Exchange 2013 server includes the file ScriptingAgentConfig.xml.sample in the <installation
path>\V15\Bin\CmdletExtensionAgents folder. This file must be renamed to ScriptingAgentConfig.xml on every
Exchange 2013 server if you enable the Scripting Agent cmdlet extension agent. The sample configuration file
contains sample scripts that you can use to help you understand how to add scripts to the configuration file.
After you add a script to the configuration file, or if you make a change to the configuration file, you must update
the file on every Exchange 2013 server in your organization. This must be done to make sure that each server
contains an up-to-date version of the scripts that the Scripting Agent cmdlet extension agent runs.
Some characters typically used in scripts also have a special meaning in XML. To use these characters in your
script, use escape sequences. For example, the following characters use an escape sequence:
Instead of a greater than sign ( > ), use &gt;

Instead of a less than sign ( < ), use $lt;

Instead of an ampersand ( & ), use &amp;

Enable the Scripting agent

The Scripting agent cmdlet extension agent is disabled by default. When you enable the Scripting agent , the
agent is enabled for the entire Exchange 2013 organization. Before you enable the Scripting agent , verify that the
Scripting agent configuration file has been correctly renamed and updated with your scripts on every Exchange
2013 server. You will receive an error message each time a cmdlet runs if you don't rename the configuration file
correctly or copy a configuration file to this computer from another Exchange 2013 server.
To enable the Scripting agent , you must do the following:
1. Rename the ScriptingAgentConfig.xml.sample file in <installation
path>\V15\Bin\CmdletExtensionAgents to ScriptingAgentConfig.xml on every Exchange 2013 server
in your organization.

NOTE
You can copy the configuration file from one Exchange 2013 server to other Exchange 2013 servers. Be sure you
update the configuration file you want to copy before you copy it.

2. Add your script to the renamed configuration file on every Exchange 2013 server in your organization.
3. Enable the Scripting agent cmdlet extension agent. For more information about enabling cmdlet
extension agents, see Manage cmdlet extension agents.

Scripting Agent priority

By default, the Scripting agent cmdlet extension agent runs after every other agent, with the exception of the
Scripting agent agent. If you want a script you created to replace an existing agent, you must either disable the
other agent or change the priority of either agent so that the Scripting agent cmdlet extension agent runs first.
For more information about how to disable or change the priority of agents, see Manage cmdlet extension agents.
 Manage cmdlet extension agents
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic shows you how to enable, disable, view, and change the priority of cmdlet extension agents in Microsoft
Exchange Server 2013. For more information about cmdlet extension agents in Exchange 2013, see Cmdlet
extension agents.

What do you need to know before you begin?

Estimated time to complete each procedure: less than 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Cmdlet extension agents" entry in the Exchange and Shell infrastructure
permissions topic.
Before you enable the Scripting Agent , you must verify that it's configured correctly. For more information
about the Scripting Agent , see Cmdlet extension agents.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Enable a cmdlet extension agent

When you enable a cmdlet extension agent in Exchange 2013, the agent is run on every server running Exchange
2013 in the organization. When an agent is enabled, it's made available to cmdlets, which can then use the agent
to perform additional operations.

WARNING
Before you enable an agent, be sure that you're aware of how the agent works and what impact the agent will have on your
organization.

This example enables a cmdlet extension agent by using the Enable-CmdletExtensionAgent cmdlet. You must
specify the name of the agent you want to enable when you run the cmdlet. Before you enable the
Scripting Agent , you need to make sure that you've deployed the ScriptingAgentConfig.xml configuration file to
all the servers in your organization. If you don't deploy the configuration file first and you enable the
Scripting ``Agent , all non-Get cmdlets fail when they're run. This example enables the Scripting Agent .

Enable-CmdletExtensionAgent "Scripting Agent"

For detailed syntax and parameter information, see Enable-CmdletExtensionAgent.

Disable a cmdlet extension agent
When you disable a cmdlet extension agent in Exchange 2013, the agent is disabled on every server running
Exchange 2013 in the organization. When an agent is disabled, it's not made available to cmdlets. Cmdlets can no
longer use the agent to perform additional operations.

WARNING
Before you disable an agent, be sure that you're aware of how the agent works and what impact disabling the agent will
have on your organization.

To disable a cmdlet extension agent, use the Disable-CmdletExtensionAgent cmdlet. Specify the name of the
agent you want to disable when you run the cmdlet. This example disables the Scripting Agent .

Disable-CmdletExtensionAgent "Scripting Agent"

For detailed syntax and parameter information, see Disable-CmdletExtensionAgent.

View existing cmdlet extension agents

Viewing cmdlet extension agents enables you to see which agents are run first and which agents are enabled in an
Exchange 2013 organization. For more information about pipelining and the Format-Table cmdlet, see the
following topics:
Pipelining
Working with command output
This example gets the details of a specific cmdlet extension agent by using the Get-CmdletExtensionAgent
cmdlet. In this example, the details of the Mailbox Permissions Agent are returned.

Get-CmdletExtensionAgent "Mailbox Permissions Agent"

This example gets multiple cmdlet extension agents by using the Get-CmdletExtensionAgent cmdlet, and then
pipes the output to the Format-Table cmdlet. This example displays a list of all of the cmdlet extension agents in
the organization, and by using the Format-Table cmdlet, the Name, Enabled, and Priority properties of each
agent are displayed in a table.

Get-CmdletExtensionAgent | Format-Table Name, Enabled, Priority

For detailed syntax and parameter information, see Get-CmdletExtensionAgent.

Change the priority of a cmdlet extension agent

The ability to change the priority of a cmdlet extension agent in Exchange 2013 is useful when you want a certain
agent to be called by a cmdlet before another agent. This is especially useful if you create a custom script that's
run in the Scripting Agent , and you want that script to take precedence over a built-in agent. For more
information about the Scripting Agent , see Cmdlet extension agents.
 WARNING
Changing the priority or replacing the functionality of a built-in agent is an advanced operation. Be sure that you completely
understand the changes you're making.

Agents are ordered from zero to the maximum number of agents. The closer to zero the agent is, the higher the
priority of the agent. Agents with a higher priority are called first. For more information about agent priorities, see
Cmdlet extension agents.
This example changes the priority of a cmdlet extension agent by using the Set-CmdletExtensionAgent cmdlet.
In this example, the priority of the Scripting Agent is changed to 3.

Set-CmdletExtensionAgent "Scripting Agent" -Priority 3

For detailed syntax and parameter information, see Set-CmdletExtensionAgent.

 Exchange Management Shell quick reference for
Exchange 2013
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic describes the most frequently used cmdlets available in the release to manufacturing (RTM ) and later
versions of Microsoft Exchange Server 2013 and provides examples of their use.

NOTE
More content will be added about other areas of Exchange 2013 soon.

For more information about the Exchange Management Shell in Exchange 2013 and all the available cmdlets, see
the following topics:
Using PowerShell with Exchange 2013 (Exchange Management Shell)
Exchange 2013 cmdlets

What would you like to learn about?

Common cmdlet actions
The following verbs are supported by most cmdlets and are associated with a specific action.

New The New verb creates an instance of something, such as a

new configuration setting, a new database, or a new SMTP
connector.

Remove The Remove verb removes an instance of something, such

as a mailbox or transport rule.
All Remove cmdlets support the WhatIf and Confirm
parameters. For more information about these
parameters, see Important Parameters.

Enable The Enable verb enables a setting or mail-enables a

recipient.

Disable The Disable verb disables an enabled setting or mail-

disables a recipient.
All Disable tasks also support the WhatIf and Confirm
parameters. For more information about these
parameters, see Important Parameters.
 Set The Set verb modifies specific settings of an object, such as
the alias of a contact or the deleted item retention of a
mailbox database.

Get The Get verb queries a specific object or a subset of a type

of object, such as a specific mailbox, all mailbox users, or
mailbox users in a domain.

Important parameters
The following parameters help you control how your commands run and indicate exactly what a command will do
before it affects data.

Identity The Identity parameter identifies the unique object for the
task. It's typically used with Enable, Disable, Remove, Set,
and Get cmdlets. Identity is also a positional parameter,
which means that you don't have to specify Identity when
you specify the parameter's value on the command line.
For example, Get-Mailbox -Identity user1 queries for the
mailbox of user1. Get-Mailbox user1 is equivalent to Get-
Mailbox -Identity user1.

WhatIf The WhatIf parameter instructs the cmdlet to simulate the

actions that it would take on the object. By using the
WhatIf parameter, you can view what changes would
occur without actually applying any of the changes. The
default value is $true.

Confirm The Confirm parameter causes the cmdlet to pause

processing and requires the administrator to acknowledge
what the cmdlet will do before processing continues. The
default value is $true.

Validate The Validate parameter causes the cmdlet to check that

all prerequisites for running the operation are satisfied and
that the operation will complete successfully.

Tips and tricks

The following commands are associated with various tasks that you can use when administering Exchange 2013.

Get-Command This cmdlet retrieves all tasks that can be executed in

Exchange 2013.

Get-Command *keyword* This cmdlet retrieves tasks that have keyword in the
cmdlet.

Get-task | Get-Member This cmdlet retrieves all properties and methods of task.
 Get-task | Format-List This cmdlet displays the output of the query in a
formatted list. You can pipe the output of any Get cmdlet
to Format-List to view the whole set of properties that
exist on the object returned by that command, or you can
specify individual properties that you want to view,
separated by commas, as in the following example: Get-
Mailbox *john* | Format-List alias,*quota

Help task This cmdlet retrieves Exchange Management Shell help

information for any task in Exchange 2013, as in the
following example: Help Get-Mailbox

Get-task | Format-List > file.txt This cmdlet exports the output of task to a text file: file.txt

Permissions
Get-RoleGroupMember "Organization Management" This command retrieves the members of the Organization
Management management role group.

Get-ManagementRoleAssignment -Role "Mail Recipient This command retrieves a list of all the users who are
Creation" -GetEffectiveUsers granted permissions provided by the Mail Recipient
Creation management role. This includes users who are
members of role groups or universal security groups
(USGs) that are assigned the Mail Recipient Creation role.
This doesn't include users who are members of linked role
groups in another forest.

Get-ManagementRoleAssignment -RoleAssignee This command retrieves a list of cmdlets that the user
Administrator | Get-ManagementRole | Get- Administrator can run.
ManagementRoleEntry

ForEach ($RoleEntry in Get-ManagementRoleEntry This command retrieves a list of all the users who can run
*\Remove-Mailbox -parameters Identity) {Get- the Remove-Mailbox cmdlet.
ManagementRoleAssignment -Role $RoleEntry.Role -
GetEffectiveUsers -Delegating $False | Where-Object
{$_.EffectiveUserName -Ne "All Group Members"} | FL Role,
EffectiveUserName, AssignmentChain}

Get-ManagementRoleAssignment -WritableRecipient This command retrieves a list of all users who can modify
kima -GetEffectiveUsers | FT RoleAssigneeName, the mailbox of kima.
EffectiveUserName, Role, AssignmentChain
 New-ManagementScope "Seattle Users" - This command creates a new management scope and
RecipientRestrictionFilter { City -Eq "Seattle" } management role group to enable members of the role
group to manage recipients in Seattle.
New-RoleGroup "Seattle Admins" -Roles "Mail
Recipients", "Mail Recipient Creation", "Mailbox Import First, the Seattle Users management scope is created,
Export", -CustomRecipientWriteScope "Seattle Users" which matches only recipients who have Seattle in the
City attribute on their user object.
Then, a new role group called Seattle Admins is created
and the Mail Recipients, Mail Recipient Creation, and
Mailbox Import Export roles are assigned. The role group
is scoped so that its members can manage only users who
match the Seattle Users recipient filter scope.

New-ManagementScope "Vancouver Servers" - This command creates a new management scope and
ServerRestrictionFilter { ServerSite -Eq "Vancouver" } copies an existing role group to enable members of the
new role group to manage only servers in the Vancouver
$RoleGroup = Get-RoleGroup "Server Management" Active Directory site.
New-RoleGroup "Vancouver Server Management" -Roles First, the Vancouver Servers management scope is
$RoleGroup.Roles -CustomConfigWriteScope "Vancouver created, which matches only servers that are located in
Servers" the Vancouver Active Directory site. The Active Directory
site is stored in the ServerSite attribute on the server
objects.
Then, a new role group called Vancouver Server
Management is created that's a copy of the Server
Management role group. This new role group, however, is
scoped to allow its members to manage only servers that
match the Vancouver Servers configuration filter scope.

Add-RoleGroupMember "Organization Management" - This command adds the user davids to the Organization
Member davids Management role group.

Get-ManagementRoleAssignment -Role "Mail Recipient This command removes the Mail Recipient Creation role
Creation" -RoleAssignee "Seattle Admins" | Remove- from the Seattle Admins role group. This command is
ManagementRoleAssignment useful because you don't need to know the name of the
management role assignment that assigns the role to the
role group.

Remote Shell
$Session = New-PSSession -ConfigurationName These commands open a new remote Shell session
Microsoft.Exchange -ConnectionUri between a local domain-joined computer and a remote
http://ExServer.contoso.com/PowerShell/ -Authentication Exchange 2013 server with the FQDN
Kerberos ExServer.contoso.com. Use this command if you want to
administer a remote Exchange 2013 server and only have
Import-PSSession $Session the Windows Management Framework, which includes the
Windows PowerShell command-line interface, installed on
your local computer. This command uses your current
logon credentials to authenticate against the remote
Exchange 2013 server.
$UserCredential = Get-Credential These commands open a new remote Shell session
between a local domain-joined computer and a remote
$Session = New-PSSession -ConfigurationName Exchange 2013 server with the FQDN
Microsoft.Exchange -ConnectionUri ExServer.contoso.com. Use this command if you want to
http://ExServer.contoso.com/PowerShell/ -Authentication administer a remote Exchange 2013 server and only have
Kerberos -Credential $UserCredential the Windows Management Framework, which includes
Import-PSSession $Session Windows PowerShell, installed on your local computer. This
command uses credentials you specify explicitly to
authenticate against the remote Exchange 2013 server.

Remove-PSSession $Session This command closes the remote Shell session between a
local computer and the remote Exchange 2013 server.

Import-RecipientDataProperty -Identity "Tony Smith" - This command shows an example of the syntax, shown in
SpokenName -FileData ([Byte[]]$(Get-Content -Path italics, required to import a file into a remote Exchange
"M:\AudioFiles\TonySmith.wma" -Encoding Byte - 2013 server using the FileData parameter on a cmdlet.
ReadCount 0)) The syntax encapsulates the data contained in the
M:\AudioFiles\TonySmith.wma file and streams the data to
the FileData property on the Import-
RecipientDataProperty cmdlet.
The FileData parameter accepts data from a file on your
local computer using this syntax on most cmdlets.

Export-RecipientDataProperty -Identity This command shows an example of the syntax, shown in

[email protected] -SpokenName | ForEach {$_.FileData | italics, required to export a file from a remote Exchange
Add-Content C:\tonysmith.wma -Encoding Byte} 2013 server. The syntax encapsulates the data stored in
the FileData property on the object returned by the
cmdlet and then streams the data to your local computer.
The data is then stored in the C:\tonysmith.wma file.
Most cmdlets that output objects with a FileData property
use this syntax to export data to a file on your local
computer.
 Filterable properties for the -ContentFilter parameter
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic lists the filterable properties for the ContentFilter parameter. The ContentFilter parameter is used to
export messages to a .pst file that match the filter. The ContentFilter parameter is used in the New -
MailboxExportRequest cmdlet.

Filterable properties
Many of the properties for the ContentFilter parameter accept wildcard characters. If you use a wildcard character,
use the -like operator instead of the -eq operator. The -like operator is used to find pattern matches in rich types,
such as strings, whereas the -eq operator is used to find an exact match.
The following table contains a list of the filterable properties for the ContentFilter parameter. This table lists the
name of the property, a description, the acceptable values, and a syntax example. For more information about
OPATH filters, see Filters in recipient Shell commands.

PROPERTY DESCRIPTION VALUES EXAMPLE SYNTAX

All This property returns all String

messages that have a -ContentFilter {All
particular string in any Wildcard -like '*Ayla*'}
of the indexed
properties. For example,
use this property if you
want to export all
messages that have
"Ayla" as the recipient,
the sender, or have the
name mentioned in the
message body.

Attachment This property returns String

messages that have the -ContentFilter
specified string in the Wildcard {Attachment -like
content of an '*.jpg'}
attachment or in the
attachment's file name.

BCC This property returns Display name

sent messages that have -ContentFilter
the specified recipient in Alias {(BCC -eq
the Bcc field. '[email protected]')
SMTP address -or (BCC -eq
LegacyDN '[email protected]')
}
Wildcard
PROPERTY DESCRIPTION VALUES EXAMPLE SYNTAX

Body This property returns String

messages that have the -ContentFilter
specified string within Wildcard {Body -like
the message body. '*prospectus*'}

Category This property returns String

messages that have a -ContentFilter
matching category. Wildcard {Category -like
Categories are set by '*Blue*'}
users or Inbox rules.

CC This property returns Display name

sent messages that have -ContentFilter {(CC
the specified recipient in Alias -eq
the Cc field. '[email protected]')
SMTP address -or (CC -eq
LegacyDN '[email protected]')
}
Wildcard

Expires This property returns Date-Time stamp

messages that have a -ContentFilter
specified expiration time {Expires -lt
stamp. '01/01/2013'}

HasAttachment This property returns Boolean

messages with or -ContentFilter
without attachments. $true or $false {HasAttachment -eq
$true}

Importance This property returns 0 or "Low"

messages that have a -ContentFilter
specified importance 1 or "Normal" {Importance -eq
level. 'high'}
2 or "High"

-ContentFilter
{Importance -eq 2}

IsFlagged This property returns Boolean

messages that have -ContentFilter
been flagged by the user $true or $false {IsFlagged -eq
or Inbox rule. $true}

IsRead This property returns Boolean

messages that have -ContentFilter
been read or not read by $true or $false {IsRead -eq $true}
the user.
PROPERTY DESCRIPTION VALUES EXAMPLE SYNTAX

MessageKind This property returns Calendar

messages that are of the -ContentFilter
specified type. Contact {MessageKind -eq
'Calendar'}
Doc
Email
-ContentFilter
Fax {MessageKind -ne
InstantMessage 'Email'}

Journal
Note
Post
RSSFeed
Task
Voicemail

MessageLocalee This property returns CultureInfo

messages that are of the -ContentFilter
specified locale. {MessageLocale -ne
'en-US'}

-ContentFilter
{MessageLocale -eq
'tr-TR'}

Participants This property returns Display name

messages that have the -ContentFilter
specified recipient in the Alias {(Participants -eq
To, Bcc, or Cc fields. '[email protected]')
SMTP address -or (Participants -
LegacyDN eq
'[email protected]')
Wildcard }

PolicyTag This property returns String

messages that have a -ContentFilter
policy tag. The Exchange Wildcard {PolicyTag -ne
store persists policy tags '00000000-0000-
0000-0000-
as GUIDs. Therefore, the
000000000000'}
string can contain either
an explicit GUID value,
which is then searched
by the PR_POLICY_TAG,
or a wildcard string.
If the supplied value isn't
a GUID, the command
uses Active Directory
information to resolve
names to GUIDs.
PROPERTY DESCRIPTION VALUES EXAMPLE SYNTAX

Received This property returns Date-Time stamp

messages that were -ContentFilter
received with the {Received -lt
specified Received time '01/01/2013 9:00'}
stamp.

-ContentFilter
{(Received -lt
'01/01/2013') -and
(Received -gt
'01/01/2012')}

Sender This property returns Display name

messages that were ContentFilter
received from the Alias {Sender -eq 'tony'}
specified sender. SMTP address
LegacyDN
Wildcard

Sent This property returns Date-Time stamp

messages that were sent -ContentFilter
by with the specified {Sent -lt
Sent time stamp. '01/01/2013 9:00'}

-ContentFilter
{(Sent -lt
'01/01/2013') -and
(Sent -gt
'01/01/2012')}

Size This property returns B (bytes)

messages that are of a -ContentFilter
specific size. KB (kilobytes) {Size -gt '10KB'}
MB (megabytes)

Subject This property returns String

messages that have the -ContentFilter
specified string within Wildcard {Subject -like
the subject of the '*meeting*'}
message.

To This property returns Display name

sent messages that have -ContentFilter {To
the specified recipient in Alias -eq 'aylakol'}
the To field. SMTP address
LegacyDN
Wildcard
 Multi-tenancy in Exchange 2013
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

A multi-tenant (hosted) Exchange 2013 deployment is defined as one where the Exchange organization is
configured to host multiple and discrete organizations or business units (the tenants) that ordinarily don't share
email, data, users, global address lists (GALs), or other commonly used Exchange objects. This sharing of hardware,
software and resources (all while maintaining a logical separation between tenants), allows organizations to
leverage the simplicity of a standard Exchange deployment while providing multi-tenant functionality and services
to meet their hosting needs.

Multi-tenancy in Exchange 2013 organizations

In Exchange 2013, we continue to support hosting by using a standard, on-premises Exchange installation similar
to the approach used in Exchange 2010 Service Pack 2 (SP2). We discontinued the /hosting mode switch and are
emphasizing the use of address book policies (ABPs) in combination with hosting management solutions and
automation tools provided by approved Independent Software Vendors (ISVs). These solutions are built on a
framework of Microsoft-approved configuration guidelines and practices and will offer Exchange organizations an
easier, more robust way to provide hosting services and features.
Exchange 2013 supports multi-tenancy by leveraging the following primary components and features:
Active Directory: Instead of having separate ExchangeOrganization Active Directory containers for each
business unit in a multi-tenant Exchange organization, Exchange 2013 multi-tenancy is supported by using
a single ExchangeOrganization Active Directory container. This allows for a simpler Active Directory
structure and reduces the likelihood of Active Directory-related permission problems.
To learn more about Active Directory changes in Exchange 2013, see Active Directory.
Address book policies (ABPs): Introduced in Exchange 2010 SP2, ABPs are used in Exchange 2013 to
control user access to an address list, the global address list (GAL ), and an offline address books (OABs) in
the Exchange organization. ABPs group these different Active Directory objects into a single, virtual object
that can be assigned to individual users and to create a logical grouping of these resources along a multi-
tenant organizational structure. ABP functionality in Exchange 2013 is similar to what it was in Exchange
2010 SP2.
To learn more about ABPs in Exchange 2013, see Address book policies.
Hosting management solutions: Some administrators using Exchange 2013 to provide a hosted
Exchange solution will benefit from using a customized hosting management approach. Due to some
limitations of the Exchange admin center (EAC ), Microsoft works with third-party vendors to assist them in
the development of control panel and automation solutions that are in compliance with the guidelines and
approved framework for hosted Exchange 2013 organizations. We recommend that organizations
configuring a hosted Exchange solution leverage these tools to manage their hosted organizations where
circumstances require it.
To learn more about hosted management solutions, including validated solution vendors, see Exchange
Server 2013 hosting and multi-tenancy solutions and guidance
 Update your Exchange organization when Daylight
Saving Time or the time zone changes
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

If the country or region where your organization or some of your users reside has changed their policy of
recognizing Daylight Saving Time (DST), or changed the local time offset from Coordinated Universal Time (UTC ),
you need may need to update Microsoft Windows, Microsoft Exchange, Microsoft Outlook, or other programs to
accommodate these changes.
For more information about DST changes around the world, including links, see the Microsoft Daylight Saving
Time Help and Support Center. Also visit the support Web sites of your other software suppliers to see if they
require any additional updates.
Even if your time zone hasn't changed, if you interact with other computers or users globally, your computer needs
to be able to perform accurate date and time calculations for events elsewhere in the world.
Installing time zone updates as soon as possible minimizes the number of meetings or appointments that are
scheduled during the transition from the old time and date to the new one.

Step 1: Install the Windows DST update on all client and desktop
computers
Because the Office 365 authentication system is updated when DST or a time zone changes, all Office 365 client
computers need to be updated or they may experience connectivity issues.
Make sure all client and desktop computers have installed the Windows DST update. For more information, see
How to configure daylight saving time for Microsoft Windows operating systems.

Step 2: Install the Windows DST update on all servers

1. Update all your on-premises servers with the Windows DST update.
2. If you're running Office 365, update any servers that interact with the Office 365 authentication system, such
as DirSync or AD FS servers. These servers must be updated to ensure uptime.
Note: If you're updating server clusters, make sure you follow the usual process for updating clusters. You update
the passive server first, fail over to the passive server (which becomes active), and then update the formerly active
(now passive) server. For more information about how to update server clusters and high-availability server
clusters, see Update Exchange Server Clusters and High Availability Servers and How to update Windows Server
failover clusters.

Step 3: Update Exchange and Outlook, where necessary, on client and

desktop computers
1. If your users are using Outlook 2007 or older clients, determine which of the Exchange or Outlook time
zone tools to run, using the table following this procedure.
2. Send a message to your users who need to update their computers, giving them a link to the appropriate
tool.
The following table shows when users should run the Exchange Calendar Update Tool or the Time Zone Data
Update Tool for Microsoft Office Outlook. Find which version your organization's servers are running, and then
determine which client programs your users are running.

Client Version

Organization Outlook 2003 or Outlook 2010 Outlook 2013

version Outlook 2007

Exchange 2003 Exchange No action No action

on premises Calendar Tool or required required
Time Zone Data
Update Tool for
Microsoft Office
Outlook

Exchange 2007 Exchange No action No action

on premises Calendar Tool or required required
Time Zone Data
Update Tool for
Microsoft Office
Outlook

Exchange 2010 Exchange No action No action

on premises Calendar Tool or required required
Time Zone Data
Update Tool for
Microsoft Office
Outlook

Exchange 2013 Time Zone Data No action No action

on premises Update Tool for required required
Microsoft Office
Outlook

BPOS-S Time Zone Data No action No action

(Exchange 2007) Update Tool for required required
Microsoft Office
Outlook

BPOS-D Time Zone Data No action No action

(Exchange 2010) Update Tool for required required
Microsoft Office
Outlook
Office 365 Time Zone Data No action No action
(Exchange 2010) Update Tool for required required
Microsoft Office
Outlook (not
supported with
Outlook 2003)

Office 365 Time Zone Data No action No action

(Exchange 2013) Update Tool for required required
Microsoft Office
Outlook (not
supported with
Outlook 2003)
 Permissions
6/14/2019 • 15 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 includes a large set of predefined permissions, based on the Role Based Access
Control (RBAC ) permissions model, which you can use right away to easily grant permissions to your
administrators and users. You can use the permissions features in Exchange 2013 so that you can get your new
organization up and running quickly.

NOTE
Several RBAC features and concepts aren't discussed in this topic because they're advanced features. If the functionality
discussed in this topic doesn't meet your needs, and you want to further customize your permissions model, see
Understanding Role Based Access Control.

Role-based permissions
In Exchange 2013, the permissions that you grant to administrators and users are based on management roles.
A role defines the set of tasks that an administrator or user can perform. For example, a management role called
Mail Recipients defines the tasks that someone can perform on a set of mailboxes, contacts, and distribution
groups. When a role is assigned to an administrator or user, that person is granted the permissions provided by
the role.
There are two types of roles, administrative roles and end-user roles:
Administrative roles: These roles contain permissions that can be assigned to administrators or
specialist users using role groups that manage a part of the Exchange organization, such as recipients,
servers, or databases.
End-user roles: These roles, assigned using role assignment policies, enable users to manage aspects of
their own mailbox and distribution groups that they own. End-user roles begin with the prefix My .

Roles give permissions to perform tasks to administrators and users by making cmdlets available to those who
are assigned the roles. Because the Exchange admin center (EAC ) and Exchange Management Shell use cmdlets
to manage Exchange, granting access to a cmdlet gives the administrator or user permission to perform the task
in each of the Exchange management interfaces.
Exchange 2013 includes approximately 86 roles that you can use to grant permissions. For a list of roles
included with Exchange 2013, see Built-in management roles.

Role groups and role assignment policies

Roles grant permissions to perform tasks in Exchange 2013, but you need an easy way to assign them to
administrators and users. Exchange 2013 provides you with the following to help you do that:
Role groups: Role groups enable you to grant permissions to administrators and specialist users.
Role assignment policies: Role assignment policies enable you to grant permissions to end users to
change settings on their own mailbox or distribution groups that they own.
For more information about role groups and role assignment policies, see the following sections.
Role groups
Every administrator that manages Exchange 2013 must be assigned at least one or more roles. Administrators
might have more than one role because they may perform job functions that span multiple areas in Exchange.
For example, one administrator might manage both recipients and Exchange servers. In this case, that
administrator might be assigned both the Mail Recipients and Exchange Servers roles.
To make it easier to assign multiple roles to an administrator, Exchange 2013 includes role groups. Role groups
are special universal security groups (USGs) used by Exchange 2013 that can contain Active Directory users,
USGs, and other role groups. When a role is assigned to a role group, the permissions granted by the role are
granted to all the members of the role group. This enables you to assign many roles to many role group
members at once. Role groups typically encompass broader management areas, such as recipient management.
They're used only with administrative roles, and not end-user roles.

NOTE
It's possible to assign a role directly to a user or USG without using a role group. However, that method of role
assignment is an advanced procedure and isn't covered in this topic. We recommend that you use role groups to manage
permissions.

The following figure shows the relationship between users, role groups, and roles.
Roles, role groups, and role group members

Exchange 2013 includes several built-in role groups, each one providing permissions to manage specific areas in
Exchange 2013. Some role groups may overlap with others. The following table lists each role group with a
description of its use. If you want to see the roles assigned to each role group, click the name of the role group in
the "Role group" column, and then open the "Management Roles Assigned to This Role Group" section.
Built-in role groups
ROLE GROUP DESCRIPTION
ROLE GROUP DESCRIPTION

Organization Management Administrators who are members of the Organization

Management role group have administrative access to
the entire Exchange 2013 organization and can perform
almost any task against any Exchange 2013 object, with
some exceptions, such as the Discovery Management
role.

IMPORTANT
Because the Organization Management role group is a
powerful role, only users or USGs that perform
organizational-level administrative tasks that can
potentially impact the entire Exchange organization
should be members of this role group.

View-only Organization Management Administrators who are members of the View Only
Organization Management role group can view the
properties of any object in the Exchange organization.

Recipient Management Administrators who are members of the Recipient

Management role group have administrative access to
create or modify Exchange 2013 recipients within the
Exchange 2013 organization.

UM Management Administrators who are members of the UM

Management role group can manage features in the
Exchange organization such as Unified Messaging (UM)
service configuration, UM properties on mailboxes, UM
prompts, and UM auto attendant configuration.

Help Desk The Help Desk role group, by default, enables members
to view and modify the Microsoft Office Outlook Web
App options of any user in the organization. These
options might include modifying the user's display name,
address, and phone number. They don't include options
that aren't available in Outlook Web App options, such
as modifying the size of a mailbox or configuring the
mailbox database on which a mailbox is located.

Hygiene Management Administrators who are members of the Hygiene

Management role group can configure the antivirus and
anti-spam features of Exchange 2013. Third-party
programs that integrate with Exchange 2013 can add
service accounts to this role group to grant those
programs access to the cmdlets required to retrieve and
configure the Exchange configuration.

Records Management Users who are members of the Records Management

role group can configure compliance features, such as
retention policy tags, message classifications, and
transport rules.
 ROLE GROUP DESCRIPTION

Discovery Management Administrators or users who are members of the

Discovery Management role group can perform searches
of mailboxes in the Exchange organization for data that
meets specific criteria and can also configure legal holds
on mailboxes.

Public Folder Management Administrators who are members of the Public Folder
Management role group can manage public folders on
servers running Exchange 2013.

Server Management Administrators who are members of the Server

Management role group can configure server-specific
configuration of transport, Unified Messaging, client
access, and mailbox features such as database copies,
certificates, transport queues and Send connectors,
virtual directories, and client access protocols.

Delegated Setup Administrators who are members of the Delegated Setup

role group can deploy servers running Exchange 2013
that have been previously provisioned by a member of
the Organization Management role group.

Compliance Management Users who are members of the Compliance Management

role group can configure and manage Exchange
compliance settings in accordance with their
organization's policy.

If you work in a small organization that has only a few administrators, you might need to add those
administrators to the Organization Management role group only, and you may never need to use the other role
groups. If you work in a larger organization, you might have administrators who perform specific tasks
administering Exchange, such as recipient or server management. In those cases, you might add one
administrator to the Recipient Management role group, and another administrator to the Server Management
role group. Those administrators can then manage their specific areas of Exchange 2013 but won't have
permissions to manage areas they're not responsible for.
If the built-in role groups in Exchange 2013 don't match the job function of your administrators, you can create
role groups and add roles to them. For more information, see Work with Role Groups later in this topic.

Role assignment policies

Exchange 2013 provides role assignment policies so that you can control what settings your users can configure
on their own mailboxes and on distribution groups they own. These settings include their display name, contact
information, voice mail settings, and distribution group membership.
Your Exchange 2013 organization can have multiple role assignment policies that provide different levels of
permissions for the different types of users in your organizations. Some users can be allowed to change their
address or create distribution groups, while others can't, depending on the role assignment policy associated
with their mailbox. Role assignment policies are added directly to mailboxes, and each mailbox can only be
associated with one role assignment policy at a time.
Of the role assignment policies in your organization, one is marked as default. The default role assignment
policy is associated with new mailboxes that aren't explicitly assigned a specific role assignment policy when
they're created. The default role assignment policy should contain the permissions that should be applied to the
majority of your mailboxes.
Permissions are added to role assignment policies using end-user roles. End-user roles begin with My and grant
permissions for users to manage only their mailbox or distribution groups they own. They can't be used to
manage any other mailbox. Only end-user roles can be assigned to role assignment policies.
When an end-user role is assigned to a role assignment policy, all of the mailboxes associated with that role
assignment policy receive the permissions granted by the role. This enables you to add or remove permissions
to sets of users without having to configure individual mailboxes. The following figure shows:
End-user roles are assigned to role assignment policies. Role assignment policies can share the same end-
user roles.
Role assignment policies are associated with mailboxes. Each mailbox can only be associated with one
role assignment policy.
After a mailbox is associated with a role assignment policy, the end-user roles are applied to that mailbox.
The permissions granted by the roles are granted to the user of the mailbox.
Roles, role assignment policies, and mailboxes

The Default Role Assignment Policy role assignment policy is included with Exchange 2013. As the name
implies, it's the default role assignment policy. If you want to change the permissions provided by this role
assignment policy, or if you want to create role assignment policies, see Work with Role Assignment Policies
later in this topic.

Work with role groups

To manage your permissions using role groups in Exchange 2013, we recommend that you use the Exchange
admin center. When you use the EAC to manage role groups, you can add and remove roles and members,
create role groups, and copy role groups with a few clicks of your mouse. The EAC provides simple dialog boxes,
such as the new role group dialog box, shown in the following figure, to perform these tasks.
New role group dialog box in the EAC
Exchange 2013 includes several role groups that separate permissions into specific administrative areas. If these
existing role groups provide the permissions your administrators need to manage your Exchange 2013
organization, you need only add your administrators as members of the appropriate role groups. After you add
administrators to a role group, they can administer the features that relate to that role group. To add or remove
members to or from a role group, open the role group in the EAC, and then add or remove members from the
membership list. For a list of built-in role groups, see Built-in role groups.

IMPORTANT
If an administrator is a member of more than one role group, Exchange 2013 grants the administrator all of the
permissions provided by the role groups he or she is a member of.

If none of the role groups included with Exchange 2013 have the permissions you need, you can use the EAC to
create a role group and add the roles that have the permissions you need. For your new role group, you will:
1. Choose a name for your role group.
2. Select the roles you want to add to the role group.
3. Add members to the role group.
4. Save the role group.
After you create the role group, you manage it like any other role group.
If there's an existing role group that has some, but not all of the permissions you need, you can copy it and then
make changes to create a role group. You can copy an existing role group and make changes to it, without
affecting the original role group. As part of copying the role group, you can add a new name and description,
add and remove roles to and from the new role group, and add new members. When you create or copy a role
group, you use the same dialog box that's shown in the preceding figure.
Existing role groups can also be modified. You can add and remove roles from existing role groups, and add and
remove members from it at the same time, using an EAC dialog box similar to the one in the preceding figure.
By adding and removing roles to and from role groups, you turn on and off administrative features for members
of that role group. For a list of roles you can add to a role group, see Built-in management roles.

NOTE
Although you can change which roles are assigned to built-in role groups, we recommend that you copy built-in role
groups, modify the role group copy, and then add members to the role group copy.

Work with role assignment policies

To manage the permissions that you grant end users to manage their own mailbox in Exchange 2013, we
recommend that you use the EAC. When you use the EAC to manage end-user permissions, you can add roles,
remove roles, and create role assignment policies with a few clicks of your mouse. The EAC provides simple
dialog boxes, such as the role assignment policy dialog box, shown in the following figure, to perform these
tasks.
Role assignment policy dialog box in the EAC
Exchange 2013 includes a role assignment policy named Default Role Assignment Policy. This role assignment
policy enables users whose mailboxes are associated with it to do the following:
Join or leave distribution groups that allow members to manage their own membership.
View and modify basic mailbox settings on their own mailbox, such as Inbox rules, spelling behavior, junk
mail settings, and Microsoft ActiveSync devices.
Modify their contact information, such as work address and phone number, mobile phone number, and
pager number.
Create, modify, or view text message settings.
View or modify voice mail settings.
View and modify their marketplace apps.
Create team mailboxes and connect them to Microsoft SharePoint lists.
If you want to add or remove permissions from the Default Role Assignment Policy or any other role
assignment policy, you can use the EAC. The dialog box you use is similar to the one in the preceding figure.
When you open the role assignment policy in the EAC, select the check box next to the roles you want to assign
to it or clear the check box next to the roles you want to remove. The change you make to the role assignment
policy is applied to every mailbox associated with it.
If you want to assign different end-user permissions to the various types of users in your organization, you can
create role assignment policies. When you create a role assignment policy, you see a dialog box similar to the
one in the preceding figure. You can specify a new name for the role assignment policy, and then select the roles
you want to assign to the role assignment policy. After you create a role assignment policy, you can associate it
with mailboxes using the EAC.
If you want to change which role assignment policy is the default, you must use the Shell. When you change the
default role assignment policy, any mailboxes that are created will be associated with the new default role
assignment policy if one wasn't explicitly specified. The role assignment policy associated with existing mailboxes
doesn't change when you select a new default role assignment policy.

NOTE
If you select a check box for a role that has child roles, the check boxes for the child roles are also selected. If you clear the
check box for a role with child roles, the check boxes for the child roles are also cleared.
For detailed steps about how to create role assignment policies or make changes to existing role assignment policies, see
the following topics:
Manage role assignment policies
Change the assignment policy on a mailbox

Permissions documentation
The following table contains links to topics that will help you learn about and manage permissions in Exchange
2013.

TOPIC DESCRIPTION

Understanding Role Based Access Control Learn about each of the components that make up
RBAC and how you can create advanced permissions
models if role groups and management roles aren't
enough.

Understanding multiple-forest permissions Learn about implementing RBAC permissions in

organizations with account and resource forests.

Understanding split permissions Learn about splitting Exchange and security principal
management using RBAC and Active Directory split
permissions.

Understanding permissions coexistence with Exchange Configure permissions to enable administration of

2007 and Exchange 2010 Exchange 2013 in existing Exchange 2007 and Exchange
2010 organizations.

Manage role groups Configure permissions for Exchange administrators and

specialist users using role groups.

Manage role group members Add members to and from role groups. By adding and
removing members to and from role groups, you
configure who's able to administer Exchange features.
TOPIC DESCRIPTION

Manage linked role groups Configure permissions for Exchange administrators and
specialist users in multi-forest Exchange deployments.

Manage role assignment policies Configure which features end-users have access to on
their mailboxes using role assignment policies.

Change the assignment policy on a mailbox Configure which role assignment policy is applied to one
or more mailboxes.

Create linked role groups that mirror built-in role groups Re-create the built-in role groups as linked role groups
in multi-forest Exchange deployments.

View effective permissions View who has permissions to administer Exchange

features.

Feature permissions Learn more about the permissions required to manage

Exchange features and services.

Advanced permissions Use advanced RBAC features to create highly customized

permission models to fit the needs of any organization.
 Understanding Role Based Access Control
6/14/2019 • 14 minutes to read • Edit Online

Applies to: Exchange Server 2013

Role Based Access Control (RBAC ) is the permissions model used in Microsoft Exchange Server
2013. With RBAC, you don't need to modify and manage access control lists (ACLs), which was
done in Exchange Server 2007. ACLs created several challenges in Exchange 2007, such as
modifying ACLs without causing unintended consequences, maintaining ACL modifications
through upgrades, and troubleshooting problems that occurred due to using ACLs in a
nonstandard way.
RBAC enables you to control, at both broad and granular levels, what administrators and end-
users can do. RBAC also enables you to more closely align the roles you assign users and
administrators to the actual roles they hold within your organization. In Exchange 2007, the
server permissions model applied only to the administrators who managed the Exchange 2007
infrastructure. In Exchange 2013, RBAC now controls both the administrative tasks that can be
performed and the extent to which users can now administer their own mailbox and distribution
groups.
RBAC has two primary ways of assigning permissions to users in your organization, depending
on whether the user is an administrator or specialist user, or an end-user: management role
groups and management role assignment policies. Each method associates users with the
permissions they need to perform their jobs. A third, more advanced method, direct user role
assignment, can also be used. The following sections in this topic explain RBAC and provide
examples of its use.

NOTE
This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2013
permissions, such as using the Exchange admin center (EAC) to add and remove members to and from
role groups, create and modify role groups, or create and modify role assignment policies, see
Permissions.

Management role groups

Management role groups associate management roles to a group of administrators or specialist
users. Administrators manage a broad Exchange organization or recipient configuration.
Specialist users manage the specific features of Exchange, such as compliance. Or they may have
limited management abilities, such as Help desk members, but aren't given broad administrative
rights. Role groups typically associate administrative management roles that enable
administrators and specialist users to manage the configuration of their organization and
recipients. For example, whether administrators can manage recipients or use mailbox discovery
features is controlled using role groups.
Adding or removing users to or from role groups is how you most often assign permissions to
administrators or specialist users. For more information, see Understanding management role
groups.
Role groups consist of the following components that define what administrators and specialist
users can do:
 Management role group: The management role group is a special universal security
group (USG ) that contains mailboxes, users, USGs, and other role groups that are
members of the role group. This is where you add and remove members, and it's also what
management roles are assigned to. The combination of all the roles on a role group
defines everything that users added to a role group can manage in the Exchange
organization.
Management role: A management role is a container for a grouping of management role
entries. Roles are used to define the specific tasks that can be performed by the members
of a role group that's assigned the role. A management role entry is a cmdlet, script, or
special permission that enables each specific task in a role to be performed. For more
information, see Understanding management roles.
Management role assignment: A management role assignment links a role and a role
group. Assigning a role to a role group grants members of the role group the ability to use
the cmdlets and parameters defined in the role. Role assignments can use management
scopes to control where the assignment can be used. For more information, see
Understanding management role assignments.
Management role scope: A management role scope is the scope of influence or impact
on a role assignment. When a role is assigned with a scope to a role group, the
management scope targets specifically what objects that assignment is allowed to manage.
The assignment, and its scope, are then given to the members of the role group, and
restrict what those members can manage. A scope can consist of a list of servers or
databases, organizational units (OUs), or filters on server, database or recipient objects. For
more information, see Understanding management role scopes.
When you add a user to a role group, the user is given all of the roles assigned to the role group.
If scopes are applied to any of the role assignments between the role group and the roles, those
scopes control what server configuration or recipients the user can manage.
If you want to change what roles are assigned to role groups, you need to change the role
assignments that link the role groups to roles. Unless the assignments built into Exchange 2013
don't suit your needs, you won't have to change these assignments. For more information, see
Understanding management role assignments.
For more information about role groups, see Understanding management role groups.

Management role assignment policies

Management role assignment policies associate end-user management roles to users. Role
assignment policies consist of roles that control what a user can do with his or her mailbox or
distribution groups. These roles don't allow management of features that aren't directly
associated with the user. When you create a role assignment policy, you define everything a user
can do with his or her mailbox. For example, a role assignment policy may allow a user to set the
display name, set up voice mail, and configure Inbox rules. Another role assignment policy might
allow a user to change the address, use text messaging, and set up distribution groups. Every user
with an Exchange 2013 mailbox, including administrators, is given a role assignment policy by
default. You can decide which role assignment policy should be assigned by default, choose what
the default role assignment policy should include, override the default for certain mailboxes, or
not assign role assignment policies by default at all.
Assigning a user to an assignment policy is how you most often manage permissions for users to
manage their own mailbox and distribution group options. For more information, see
Understanding management role assignment policies.
Role assignment policies consist of the following components that define what users can do with
their own mailboxes. Notice that some of the same components also apply to role groups. When
used with role assignment policies, these components are limited to enable users to manage only
their own mailbox:
Management role assignment policy: The management role assignment policy is a
special object in Exchange 2013. Users are associated with the role assignment policy
when their mailboxes are created or if you change the role assignment policy on a mailbox.
This is also what you assign end-user management roles to. The combination of all the
roles on a role assignment policy defines everything that the user can manage on his or
her mailbox or distribution groups.
Management role: A management role is a container for a grouping of management role
entries. Roles are used to define the specific tasks that a user can do with his or her
mailbox or distribution groups. A management role entry is a cmdlet, script or special
permission that enables each specific task in a management role to be performed. You can
only use end-user roles with role assignment policies. For more information, see
Understanding management roles.
Management role assignment: A management role assignment is the link between a
role and a role assignment policy. Assigning a role to a role assignment policy grants the
ability to use the cmdlets and parameters defined in the role. When you create a role
assignment between a role assignment policy and a role, you can't specify any scope. The
scope applied by the assignment is either Self or MyGAL . All role assignments are scoped
to the user's mailbox or distribution groups. For more information, see Understanding
management role assignments.
If you want to change what roles are assigned to role assignment policies, you need to change the
role assignments that link the role assignment policies to roles. Unless the assignments built into
Exchange 2013 don't suit your needs, you won't have to change these assignments. For more
information, see Understanding management role assignments.
For more information, see Understanding management role assignment policies.

Direct user role assignment

Direct role assignment is an advanced method for assigning management roles directly to a user
or USG without using a role group or role assignment policy. Direct role assignments can be
useful when you need to provide a granular set of permissions to a specific user and no others.
However, using direct role assignments can significantly increase the complexity of your
permissions model. If a user changes jobs or leaves the company, you need to manually remove
the assignments and add them to the new employee. We recommend that you use role groups to
assign permissions to administrators and specialist users, and role assignment policies to assign
permissions to users.
For more information about direct user assignment, see Understanding management role
assignments.

Summary and examples

The following figure shows the components in RBAC and how they fit together:
Role groups:
 One or more administrators can be members of a role group. They can also be
members of more than one role group.
The role group is assigned one or more role assignments. These link the role group
with one or more administrative roles that define what tasks can be performed.
The role assignments can contain management scopes that define where the users
of the role group can perform actions. The scopes determine where the users of the
role group can modify configuration.
Role assignment policies:
One or more users can be associated with a role assignment policy.
The role assignment policy is assigned one or more role assignments. These link the
role assignment policy with one or more end-user roles. The end-user roles define
what the user can configure on his or her mailbox.
The role assignments between role assignment policies and roles have built-in
scopes that restrict the scope of assignments to the user's own mailbox or
distribution groups.
Direct role assignment (advanced):
A role assignment can be created directly between a user or USG and one or more
roles. The role defines what tasks the user or USG can perform.
The role assignments can contain management scopes that define where the user or
USG can perform actions. The scopes determine where the user or USG can modify
configuration.
RBAC overview

As shown in the preceding figure, many components in RBAC are related to each other. It's how
each component is put together that defines the permissions applied to each administrator or
user. The following examples provide some additional context about how role groups and role
assignment policies are used in an organization.

Jane the Administrator

Jane is an administrator for the medium-size company, Contoso. She's responsible for managing
the company's recipients in their Vancouver office. When the permissions model for Contoso was
created, Jane was made a member of the Recipient Management - Vancouver custom role group.
The Recipient Management - Vancouver custom role group most closely matches her job's duties,
which include creating and removing recipients, such as mailboxes and contacts, managing
distribution group membership and mailbox properties, and similar tasks.
In addition to the Recipient Management - Vancouver custom role group, Jane also needs a role
assignment policy to manage her own mailbox's configuration settings. The organization
administrators have decided that all users, except for senior management, receive the same
permissions when they manage their own mailboxes. They can configure their voice mail, set up
retention policies and change their address information. The default role assignment policy
provided with Exchange 2013 now reflects these requirements.

NOTE
You may have noticed that because Jane is a member of the Recipient Management - Vancouver custom
role group, that should give her permissions to manage her own mailbox. This is true; however, the role
group doesn't provide her all of the permissions necessary to manage all of the features of her mailbox.
The permissions needed to manage voice mail and retention policy settings aren't included in her role
group. Those are provided only by the default role assignment policy assigned to her.

To allow for this, consider the role group, which provides Jane's administrative permissions over
the recipients in Vancouver:
1. A custom role group called Recipient Management - Vancouver was created. When it was
created, the following occurred:
a. The role group was assigned all of the same management roles that are also
assigned to the Recipient Management built-in role group. This gives users added
to the Recipient Management - Vancouver custom role group the same permissions
as those users added to the Recipient Management role group. However, the
following steps limit where they can use those permissions.
b. The Vancouver Recipients custom management scope was created, which matches
only recipients who are located in Vancouver. This was done by creating a scope
that filters on a user's city or other unique information.
c. The role group was created with the Vancouver Recipients custom management
scope. This means while administrators added to the Recipient Management -
Vancouver custom role group have full recipient management permissions, they can
only use those permissions against recipients based in Vancouver.
For more information about creating a custom role group, see Manage role groups.
2. Jane is then added as a member of the Recipient Management - Vancouver custom role
group.
For more information about adding members to a role group, see Manage role group
members.
To give Jane the ability to manage her own mailbox settings, a role assignment policy needs to be
configured with the required permissions. The default role assignment policy is used to provide
users with the permissions they need to configure their own mailbox. All end-user roles are
removed from the default role assignment policy, except for: MyBaseOptions ,
MyContactInformation , MyVoicemail , and MyRetentionPolicies . MyBaseOptions is included
because this management role provides the basic user functionality in Outlook Web App, such as
Inbox rules, calendar configuration, and other tasks.
Nothing else needs to be done because Jane is already assigned the default role assignment
policy. This means that the changes made to that role assignment policy are immediately applied
to her mailbox, and any other mailboxes also assigned to the default role assignment policy.
For more information about customizing the default role assignment policy, see Manage role
assignment policies.

Joe the Specialist

Joe works for Contoso, the same company that Jane works for. He's responsible for performing
legal discovery, setting the retention policies, and configuring transport rules and journaling for
the whole organization. As with Jane, when the permissions model for Contoso was created, Joe
was added to the role groups that match his job duties. The Records Management role group
provides Joe with the permissions to configure retention policies, journaling, and transport rules.
The Discovery Management role group provides him with the ability to perform mailbox
searches.
As with Jane, Joe also needs permissions to manage his own mailbox. He is given the same
permissions as Jane: He can set up his voice mail and retention policies, and change his address
information.
To give Joe the permissions to perform his job duties, Joe is added to the Records Management
and Discovery Management role groups. The role groups don't need to be changed in any way
because they already provide him with the permissions he needs, and the management scopes
applied to them encompass the entire organization.
For more information about adding a user to a role group, see Manage role group members.
Joe's mailbox is also assigned the same default role assignment policy that's applied to Jane's
mailbox. This gives him all the permissions he needs to manage the features of his mailbox that
he's allowed to manage.

Isabel the Vice President

Isabel is the Vice President of Marketing at Contoso. Isabel, as part of the senior leadership team
of Contoso, is given more permissions than the average user. This includes the permissions she's
provided to manage her mailbox, with one exception: Isabel isn't allowed to manage her own
retention policies for legal compliance reasons. Isabel can configure her voice mail, change her
contact information, change her profile information, create and manage her own distribution
groups, and add or remove herself from existing distribution groups owned by others.
So, Isabel is given different permissions on her own mailbox. Most users at Contoso are assigned
to the default role assignment policy. However, senior leadership is assigned to the Senior
Leadership role assignment policy. The following is done to create the custom role assignment
policy:
1. A custom role assignment policy called Senior Leadership is created. The role assignment
policy is assigned the MyBaseOptions , MyContactInformation , MyVoicemail ,
MyProfileInformation , MyDistributionGroupMembership , and MyDistributionGroups roles.
MyBaseOptions is included because this role provides the basic user functionality in
Outlook Web App, such as Inbox rules, calendar configuration, and other tasks.
2. Isabel is then manually assigned the Senior Leadership role assignment policy.
Isabel's mailbox now has the permissions provided by the Senior Leadership role assignment
policy. Any changes made to this role assignment policy are automatically applied to her mailbox,
and any other mailboxes also assigned to the same role assignment policy.

For more information

Manage role assignment policies
Change the assignment policy on a mailbox
 Understanding management role groups
6/14/2019 • 13 minutes to read • Edit Online

Applies to: Exchange Server 2013

A management role group is a universal security group (USG ) used in the Role Based Access Control (RBAC )
permissions model in Microsoft Exchange Server 2013. A management role group simplifies the assignment of
management roles to a group of users. All members of a role group are assigned the same set of roles. Role
groups are assigned administrator and specialist roles that define major administrative tasks in Exchange 2013
such as organization management, recipient management, and other tasks. Role groups enable you to more
easily assign a broader set of permissions to a group of administrators or specialist users.

NOTE
This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2013 permissions, such as
using the Exchange admin center (EAC) to add and remove members to and from role groups, create and modify role
groups, or create and modify role assignment policies, see Permissions.

If you want to assign permissions to users to manage their own mailbox or distribution groups, see Understanding
management role assignment policies.

Role group layers

The following are the layers that make up the role group model:
Role group member: A role group member is a mailbox, universal security group (USG ), or other role
group that can be added as a member of a role group. When a mailbox, USG, or another role group is
added as a member of a role group, the assignments that have been made between management roles
and a role group are applied to the new member. This grants the new member all of the permissions
provided by the management roles.
Management role group: The management role group is a special USG that contains mailboxes,
USGs, and other role groups that are members of the role group. This is where you add and remove
members, and it's also what management roles are assigned to. The combination of all the roles on a
role group defines everything that members added to a role group can manage in the Exchange
organization.
Management role assignment: A management role assignment links a management role and a role
group. Assigning a management role to a role group grants members of the role group the ability to use
the cmdlets and parameters defined in the management role. Role assignments can use management
scopes to control where the assignment can be used. For more information, see Understanding
management role assignments.
Management role scope: A management role scope is the scope of influence or impact on a role
assignment. When a role is assigned with a scope to a role group, the management scope targets
specifically what objects that assignment is allowed to manage. The assignment, and its scope, are then
given to the members of the role group, which restricts what those members can manage. A scope can
be made up of lists of servers or databases, organizational units, or filters on server, database or
recipient objects. For more information, see Understanding management role scopes.
Management role: A management role is a container for a grouping of management role entries.
 Roles are used to define the specific tasks that can be performed by the members of a role group
assigned the role. For more information, see Understanding management roles.
Management role entries: Management role entries are the individual entries on a management role
that provide access to cmdlets, scripts, and other special permissions that enable access to perform a
specific task. Most often, role entries consist of a single cmdlet or script and the parameters that can be
accessed by the management role, and therefore the role group to which the role is assigned.
The following figure shows each of the role group layers in the preceding list and how each of the layers relates
to the other.
Management role group layers

For more information about RBAC, see Understanding Role Based Access Control.

Role group management

When you create a role group, you create the USG that holds the members of the role group, and you create
the assignments between the role group and the management roles you specify. Optionally, you can also
specify a management scope to apply to the role assignments, and you can add any mailboxes that you want to
be members of the new role group.
After you create a role group, each layer becomes an independent object. The role group continues to be the
central point at which all of the layers are joined together, however, each layer is managed individually. For
example, to modify the management scope that you applied to the role group when it was created, you need to
change the scope on each individual role assignment after the role group is created. The management of the
role group model is performed using the cmdlets that manage the individual layers of the role group model.
The following table lists the role group layer and the procedural topics that you can use to manage each layer.
Role group management topics
ROLE GROUP MODEL LAYER MANAGEMENT TOPIC

Role group member Manage role group members

 ROLE GROUP MODEL LAYER MANAGEMENT TOPIC

Role group Manage role groups

Management roles and assignments Manage role groups

Management role entries Add a role entry to a role

Change a role entry
Remove a role entry from a role

NOTE
Changing the management role entries in
management roles in a role group is an advanced
task and is generally not required in most cases.
Instead, you may be able to use a pre-existing
management role that suits your requirements. For
more information, see Built-in role groups.

Built-in role groups

Built-in roles groups are roles shipped with Exchange 2013. They provide you with a set of role groups that you
can use to provide varying levels of administrative permissions to groups of users. You can add or remove
users to or from any built-in role group. You can also add or remove role assignments to or from most role
groups. The only exceptions are the following:
You can't remove any delegating role assignments from the Organization Management role group.
You can't remove the Role Management role from the Organization Management role group.
The following table lists all the built-in role groups included with Exchange 2013. For more information about
built-in role groups, see Built-in role groups.
Built-in role groups
ROLE GROUP DESCRIPTION

Organization Management Administrators who are members of the Organization

Management role group have administrative access to
the entire Exchange 2013 organization and can perform
almost any task against any Exchange 2013 object, with
some exceptions. By default, members of this role group
can't perform mailbox searches and management of
unscoped top-level management roles.

View-only Organization Management Administrators who are members of the View Only
Organization Management role group can view the
properties of any object in the Exchange organization.
ROLE GROUP DESCRIPTION

Recipient Management Administrators who are members of the Recipient

Management role group have administrative access to
create or modify Exchange 2013 recipients within the
Exchange 2013 organization.

UM Management Administrators who are members of the UM

Management role group can manage features in the
Exchange organization such as Unified Messaging (UM)
service configuration, UM properties on mailboxes, UM
prompts, and UM auto attendant configuration.

Discovery Management Administrators or users who are members of the

Discovery Management role group can perform
searches of mailboxes in the Exchange organization for
data that meets specific criteria and can also configure
litigation holds on mailboxes.

Records Management Users who are members of the Records Management

role group can configure compliance features, such as
retention policy tags, message classifications, transport
rules, and more.

Server Management Administrators who are members of this role group can
configure server-specific configuration of transport ,
client access, and mailbox features such as database
copies, certificates, transport queues and Send
connectors, virtual directories, and client access
protocols.

Help Desk Users who are members of the Help Desk role group
can perform limited recipient management of Exchange
2013 recipients.

Hygiene Management Users who are members of the Hygiene Management

role group can configure the anti-spam and anti-
malware features of Exchange 2013. Third-party
programs that integrate with Exchange 2013 can add
service accounts to this role group to grant those
programs access to the cmdlets required to retrieve and
configure the Exchange configuration.

Compliance Management Users who are members of the Compliance

Management role group can configure and manage
Exchange compliance configuration in accordance with
their policies.

Public Folder Management Administrators who are members of the Public Folder
Management role group can manage public folders on
servers running Exchange 2013.
 ROLE GROUP DESCRIPTION

Delegated Setup Administrators who are members of the Delegated

Setup role group can deploy servers running Exchange
2013 that have been previously provisioned by a
member of the Organization Management role group.

Linked role groups

Linked role groups are used in organizations that install Exchange 2013 in a dedicated resource forest and
place users in other, trusted foreign forests. Linked role groups, as the name implies, create a link between a
role group in the Exchange forest and a USG in a foreign forest. This is useful when the Active Directory
Domain Services (AD DS ) user accounts of the administrators you want to administer Exchange don't reside in
the same resource forest as Exchange. Linked role groups can only be associated with one foreign USG.
Additionally, you don't need to create a two-way trust between the Exchange forest and the foreign forest. The
Exchange forest needs to trust the foreign forest but the foreign forest doesn't need to trust the Exchange
forest.
For more information about permissions in multiple-forest topologies, see Understanding multiple-forest
permissions.
A linked role group consists of two parts:
Linked role group: The linked role group is a container object that associates the foreign USG with the
management role assignments assigned to the role group.
Foreign USG: The foreign USG contains the members that should be granted the permissions provided
by the linked role group.
When you create a linked role group, you provide a domain controller in the foreign forest that contains the
users you want to manage the Exchange forest and the USG that contains those users as members, the foreign
USG name, and the credentials required to access the foreign forest. Exchange adds the security identifier (SID )
of the foreign USG to the linked role group. Because the USG SID is the only identification of the foreign USG,
we strongly recommend that you specify the foreign forest in the name of the role group if you have multiple
foreign forests.
A linked role group doesn't contain any members. All of the members of that role group are managed using
the foreign USG. This means you can't use the Update-RoleGroupMember, Add-RoleGroupMember, or
Remove-RoleGroupMember cmdlets to add or remove role group members. When you add members to the
foreign USG, they are given the permissions provided by the linked role group.
You can't change a standard role group, which contains its own members, to a linked role group and vice versa.
If you want to change a role group from a standard role group to a linked role group, you must create a new
linked role group and replicate the management role assignments that are present on the standard role group
on the linked role group. This is also the case for built-in role groups because they're standard role groups. If
you want to perform all of the management of your Exchange forest from a foreign forest, you need to create
new linked role groups and add the management roles that exist on the built-in role groups to the new linked
role groups. For more information about how to accomplish this, see Create linked role groups that mirror
built-in role groups.

Role group delegation

By default, members of the Organization Management role group can add and remove members to and from
role groups. However, you might want to enable users who aren't members of the Organization Management
role group to add and remove role group members. If so, you can use role group delegation.
Role group delegation is controlled by the ManagedBy property on each role group. The ManagedBy
property contains a list of users who can add and remove members to and from that role group or change the
configuration of a role group. The users aren't assigned any permissions given by the role group unless they're
also members of the role group.
If the ManagedBy property is set on a role group, only those users who are listed as role group managers on
that property can modify a role group or the membership of a role group by default. However, an optional
parameter on cmdlets that modify role groups or role group membership can override that restriction. The
BypassSecurityGroupManagerCheck switch can be used by users who are members of the Organization
Management role or are assigned, either directly or indirectly, the Role Management management role. When
this switch is used, the ManagedBy property is ignored and the user can modify the role group or role group
membership.
If the ManagedBy property isn't set on a role group, only users who are members of the Organization
Management role or are assigned, either directly or indirectly, the Role Management management role can
modify a role group or role group membership.

NOTE
Roles assigned to a role group may be assigned using delegating role assignments. With delegating role assignments,
members of a role group that's assigned a delegated role can assign that role to another role group, assignment policy,
user, or USG. Members of the role group can assign only that role and can't delegate the role group, unless they're also
added to the ManagedBy property. For more information about delegated role assignments, see Understanding
management role assignments.

For more information about how to manage role group delegation, see Manage role groups.

Role group membership

When a user is made a member of a role group, the management roles assigned to the role group are assigned
to the user. If a user is a member of multiple role groups, the management roles from each role group are
aggregated and assigned to the user. Users, USGs, and other role groups can be members of role groups.
Only users who are members of the Organization Management or Role Management role groups and users
who have been delegated the ability to add and remove users to or from role groups can manage role group
membership.
For more information about how to manage role group membership, see Manage role group members.

Role group creation workflow

As mentioned previously, a role group is made up of several layers. To help you understand what happens
when a role group is created, consider the following example, which creates a new role group.

New-RoleGroup -Name "Seattle Recipient Management" -Roles "Mail Recipients", "Distribution Groups", "Move
Mailboxes", "UM Mailboxes" -CustomRecipientWriteScope "Seattle Users", -ManagedBy "Brian", "David", "Katie"
-Members "Ray", "Jenn", "Maria", "Chris", "Maija", "Carter", "Jenny", "Sam", "Lukas", "Isabel", "Katie"

When the preceding command is run, the following happens:

1. A new role group object, which is a special USG, called Seattle Recipient Management is created under
Microsoft Exchange Security Groups OU in the forest root domain.
2. The mailboxes for Ray, Jenn, Maria, Chris, Maija, Carter, Jenny, Sam, Lukas, Isabel, and Katie are added
as members of the role group. These users receive the permissions provided by this role group.
3. The users Brian and David are added to the ManagedBy property of the role group. These users can
add and remove members to and from the role group but won't be given any permissions provided by
the role group because they're not members. Katie is also added to the ManagedBy property of the
role group. Because she's added to the ManagedBy property, and she's a member of the role group, she
can add or remove members to and from the role group, and she also receives the permissions provided
by the role group.
4. The following management role assignments are created. The role assignments assign each
management role specified in the command to the role group. The management scope Seattle Users is
added to each role assignment. The name of each role assignment is a combination of the management
role being assigned and the role group name.
Mail Recipients_Seattle Recipient Management

Distribution Groups_Seattle Recipient Management

Move Mailboxes_Seattle Recipient Management

UM Mailboxes_Seattle Recipient Management

If you compare the results of this command to the Management role group layers figure earlier in this topic,
you can see where each step correlates to the role group layers. You can then refer to the Management role
group management topics shown in "Role group management" earlier in this topic to manage each role group
layer.
 Understanding management role assignment
policies
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

A management role assignment policy is a collection of one or more end-user management roles that enables
end users to manage their own Microsoft Exchange Server 2013 mailbox and distribution group configuration.
Role assignment policies, which are part of the Role Based Access Control (RBAC ) permissions model in
Exchange 2013, enable you to control what specific mailbox and distribution group configuration settings your
end users can modify. Different groups of users can have role assignment policies specialized to them.

NOTE
This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2013 permissions, such as using
the Exchange admin center (EAC) to add and remove members to and from role groups, create and modify role groups, or
create and modify role assignment policies, see Permissions.

For more information about RBAC, see Understanding Role Based Access Control.

Role assignment policy layers

The following list describes the layers that make up the role assignment policy model:
Mailbox: Mailboxes are assigned a single role assignment policy. When a mailbox is assigned a role
assignment policy, the assignments between management roles and a role assignment policy are applied
to the mailbox. This grants the mailbox all of the permissions provided by the management roles.
Management role assignment policy: The management role assignment policy is a special object in
Exchange 2013. Users are associated with a role assignment policy when their mailboxes are created, or if
you change the role assignment policy on a mailbox. This is also what you assign end-user management
roles to. The combination of all the roles on a role assignment policy defines everything that the user can
manage on his or her mailbox or distribution groups.
Management role assignment: A management role assignment is the link between a management role
and a role assignment policy. Assigning a management role to a role assignment policy grants the ability
to use the cmdlets and parameters defined in the management role. When you create a role assignment
between a role assignment policy and a management role, you can't specify any scope. The scope applied
by the assignment is based on the management role and is either Self or MyGAL . For more information,
see Understanding management role assignments.
Management role: A management role is a container for a grouping of management role entries. Roles
are used to define the specific tasks that a user can do with his or her mailbox or distribution groups. A
management role entry is a cmdlet, script, or special permission that enables each specific task in a
management role to be performed. You can only use end-user management roles with role assignment
policies. For more information, see Understanding management roles.
Management role entry: Management role entries are the individual entries on a management role that
determine what cmdlets and parameters are available to the management role and the role group. Each
role entry consists of a single cmdlet and the parameters that can be accessed by the management role.
The following figure shows each of the role assignment policy layers in the preceding list and how each of the
layers relates to the other.
Management role assignment policy model

For more information about management roles, role assignments, and scopes, see Understanding Role Based
Access Control.

Default and explicit role assignment policies

The following sections describe the two types of role assignment policies in Exchange 2013.

Default role assignment policy

A default role assignment policy is one assigned to a mailbox when the mailbox is created or moved to a server
running Exchange 2013, and a role assignment policy wasn't provided using the RoleAssignmentPolicy
parameter on the New-Mailbox or Enable-Mailbox cmdlets.
Exchange 2013 includes a default role assignment policy that provides end users with the permissions most
commonly used. You can change the default permissions on the default role assignment policy by adding or
removing management roles to or from it.
If you want to replace the built-in default role assignment policy with your own default role assignment policy,
you can use the Set-RoleAssignmentPolicy cmdlet to select a new default. When you do this, any new
mailboxes are assigned the role assignment policy you specified by default if you don't explicitly specify a role
assignment policy.
When you change the default role assignment policy, mailboxes assigned the default role assignment policy
aren't automatically assigned the new default role assignment policy. If you want to update previously created
mailboxes to use the role assignment policy you've set as default, you must use the Set-Mailbox cmdlet to do
so.

Explicit Role Assignment Policy

An explicit role assignment policy is a policy that you assign to a mailbox manually using the
RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox, or Enable-Mailbox cmdlets. When you
assign an explicit role assignment policy, the new policy takes effect immediately and replaces the previously
assigned explicit role assignment policy.

Using role assignment policies

Role assignment policies enable you to tailor permissions based on what business needs your users need to be
able to configure. If the default role assignment policy meets your needs, you don't need to do any
customization. However, if you have many different user groups with specialized needs, you can create role
assignment policies for each of them.
The default role assignment policy you use should contain the permissions that apply to your broadest set of
users. Then, create role assignment policies for each of your specialized user groups and tailor those role
assignment policies to grant more or less restrictive permissions to them. When you organize your role
assignment policies this way, you reduce complexity by only explicitly assigning role assignment policies to your
specialized users while the majority of your users receive the more common permissions provided by the default
role assignment policy.
A mailbox can have only one role assignment policy. All users, including administrators and specialist users, are
assigned one role assignment policy. If you want a user to have a different set of permissions, you must assign
that user's mailbox another role assignment policy with the required permissions.

Role assignment policy management

To add a new role assignment policy, you first create one and decide whether it should be the default role
assignment policy. After you create a role assignment policy, you assign management roles to the role
assignment policy, and then assign the role assignment policy to mailboxes. You can later choose to add or
remove management roles or choose a different role assignment policy to be the default.
The following table lists the role assignment policy layer and the procedural topics that you can use to manage
each layer.
Role assignment policy management topics
ROLE ASSIGNMENT POLICY MODEL LAYER MANAGEMENT TOPICS

Mailbox Manage user mailboxes

Change the assignment policy on a mailbox

Role assignment policy Manage role assignment policies

Management roles and assignments Manage role assignment policies

Management role entries Add a role entry to a role

Change a role entry
Remove a role entry from a role

NOTE
Changing the management role entries in management
roles in a role assignment policy is an advanced task
and is generally not required in most cases. You may,
instead, be able to use a preexisting management role
that suits your requirements. For more information, see
Built-in role groups.
 Understanding management roles
6/14/2019 • 29 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management roles are part of the Role Based Access Control (RBAC ) permissions model used in
Microsoft Exchange Server 2013. Roles act as a logical grouping of cmdlets that are combined to
provide access to view or modify the configuration of Exchange 2013 components, such as
mailboxes, transport rules, and recipients. Management roles can be further combined into larger
groupings called management role groups and management role assignment policies, which enable
management of feature areas and recipient configuration. Role groups and role assignment policies
assign permissions to administrators and end users, respectively. For more information about
management role groups and management role assignment policies, see Understanding Role
Based Access Control.

NOTE
This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2013
permissions, such as using the Exchange admin center (EAC) to add and remove members to and from role
groups, create and modify role groups, or create and modify role assignment policies, see Permissions.

Management role scopes and management role assignments are important components for the
operation of management roles. For more information about these components, see the following
topics:
Understanding management role scopes
Understanding management role assignments
Looking for management tasks related to management roles? See Permissions.

Built-in management roles

Exchange 2013 provides many built-in management roles that you can use to administer your
organization. Each role includes the cmdlets and parameters necessary for users to manage specific
Exchange components. The following are examples of some built-in management roles:
Mail Recipients: Enables administrators to manage mailboxes, contacts, and mail users.
Transport Rules: Enables administrators or specialist users assigned the role to manage the
transport rules feature.
Distribution Groups: Enables administrators or specialist users assigned the role to
manage distribution groups and distribution group members.
MyPersonalInformation: Enables end users to modify their own home phone number and
Web site address.
For a complete list of the management roles included with Exchange 2013, see Built-in
management roles.
You can take the built-in roles provided with Exchange 2013 and combine them in any way to
create a permissions model that works with your business. For example, if you want members of a
role group to manage recipients and public folders, you assign both the Mail Recipients and Public
Folders roles to the role group. Most often, you assign roles to role groups or role assignment
policies. You can also assign management roles directly to users if you want to control permissions
at a granular level. We recommend that you use role groups and role assignment policies rather
than direct user role assignment to simplify your permissions model.

NOTE
You can only assign end-user management roles to role assignment policies.

Built-in management roles can't be changed. You can, however, create management roles based on
the built-in management roles, and then assign those new roles to role groups or role assignment
policies. You can then change the new management roles to suit your needs. Doing so is an
advanced task that you should rarely, if ever, need to do.
For more information about creating custom roles based on the built-in Exchange roles, see
Custom Management Roles later in this topic.
You need to assign management roles for them to take effect. Most often, you assign management
roles to role groups and role assignment policies. In certain circumstances, you might also assign
roles directly to users, although this is an advanced task that you should rarely, if ever, need to do.
For more information about assigning management roles, see the following topics:
Manage role groups
Manage role assignment policies
Add a role to a user or USG
For more information about management role assignments, see Understanding management role
assignments.

Unscoped top-level management roles

Unscoped top-level management roles are a special type of management role that enables you to
grant access to custom scripts and non-Exchange cmdlets to users using RBAC. Regular
management roles provide access only to Exchange cmdlets. If you need to provide access to non-
Exchange cmdlets that run on an Exchange server, or if you need to publish a script that can be run
by your users, you need to add them to an unscoped role. They're called a top-level role because if
an unscoped role is created without deriving it from a parent role, it has no parent and is a peer of
the built-in management roles provided with Exchange 2013. To indicate that you want to create an
unscoped top-level role entry, you need to use the UnscopedTopLevel switch with the New-
ManagementRole cmdlet.
Unscoped roles are named as such because, unlike regular management roles, they can't be scoped
to a specific target. Unscoped roles are always organization wide. This means that someone
assigned an unscoped role can modify any object in the Exchange 2013 organization. For this
reason, care must be taken to make sure that scripts and cmdlets made available through an
unscoped role are thoroughly tested so that you know what they will modify, and that you carefully
assign unscoped roles.
Unscoped roles can be assigned to role assignees such as role groups, management roles, users,
and universal security groups (USGs). They can't be assigned to management role assignment
policies.
Although Exchange cmdlets can't be added as a management role entry on an unscoped role, they
can be included in scripts added as role entries. This enables you to create custom scripts that
perform Exchange tasks that you can then assign to users. A useful scenario is where a user must
perform a highly privileged task that's normally outside his or her administrative level and where
crafting a new management role or role group would be problematic. You can create a script that
performs this specific function, add it to an unscoped role, and then assign the unscoped role to the
user. The user can then perform only the specific function provided by the script.
The role entries that you add to an unscoped role must also be designated as an unscoped top-level
role entry. For more information about unscoped top-level role entries, see Unscoped Top-Level
Role Entries later in this topic.
The Organization Management role group doesn't, by default, have permissions to create or
manage unscoped role groups. This is to prevent unscoped role groups from mistakenly being
created or modified. The Organization Management role group can delegate the Unscoped Role
Management management role to itself and other role assignees. For more information about how
to create an unscoped top-level management role, see Create an unscoped role.

Custom management roles

You can create custom management roles based on built-in Exchange roles when the built-in
management roles don't match the needs of your users. When you create a custom management
role, the new child role inherits all of the management role entries of the parent role. You can then
choose which management role entries you want to keep in the custom management role and
remove all of the entries you don't want.
Custom roles become children of the role used to create the new role. You can only use
management role entries in the new child role that exist in the parent role. For more information,
see the following sections later in this topic:
Management Role Hierarchy
Management Role Entries
Creating custom management roles requires multiple steps and is an advanced task that you
should rarely, if ever, need to perform. Before you create a custom management role, make sure one
of the existing built-in management roles doesn't provide the permissions you need. For more
information about the built-in management roles, or if you want to create custom management
roles, see the following topics:
Built-in management roles
Advanced permissions
For more information about how to create a management role, see Create a role.

Management role hierarchy

Management roles exist in a parent and child hierarchy. At the top of the hierarchy are the built-in
management roles provided in Exchange 2013 by default. When you create a role, a copy of a
parent role is made. The new role is a child of the role you copied from. You can then customize the
new role to suit the needs of the administrators or users you want to assign it to.
Customized roles can be used to create roles. When you create a role from an existing customized
role, the existing customized role remains a child of its parent role, but also becomes the parent for
the new role. Each time a role is copied, the new child role can contain only the role entries that exist
in the immediate parent role.
Each management role is given a role type that can't be changed. The role type defines the base
context of use for the role. The role type is copied from the parent role when the child role is
created.
Management role hierarchy

The preceding figure illustrates the hierarchical relationship of several management roles. The Mail
Recipients and Help Desk roles are built-in roles. All of the child roles derived from these roles
inherit the role type of each built-in role. For example, all child roles derived either directly or
indirectly from the Mail Recipients role inherit the MailRecipients role type.
The Seattle Recipient Administrators custom role is a child of the Mail Recipients built-in role but
it's also the parent of the Seattle Sales Recipient Administrators custom role and the Seattle Legal
Recipient Administrators custom role. The Seattle Recipient Administrators custom role contains
only a subset of cmdlets that are available in the Mail Recipients role. The child roles of the Seattle
Recipient Administrators custom role can only contain cmdlets that also exist in that role. For
example, if a cmdlet exists in the Mail Recipients role, but the cmdlet doesn't exist in the Seattle
Recipient Administrators custom role, the cmdlet can't be added to the Seattle Sales Recipient
Administrators custom role.
All of the custom roles follow the same pattern as the roles discussed previously. For more
information about how access to cmdlets is controlled on management roles, see Management
Role Entries next in this topic.

Management role entries

Every management role, whether it's a custom Exchange role or an unscoped role, must have at
least one management role entry. An entry consists of a single cmdlet and its parameters, a script,
or a special permission that you want to make available. If a cmdlet or script doesn't appear as an
entry on a management role, that cmdlet or script isn't accessible via that role. Likewise, if a
parameter doesn't exist in an entry, the parameter on that cmdlet or script isn't accessible via that
role.
Exchange 2013 enables you to manage role entries based on built-in Exchange management top-
level roles and role entries based on unscoped top-level management roles. Roles based on built-in
Exchange top-level roles can only contain role entries that are Exchange 2013 cmdlets. To add
custom scripts or non-Exchange cmdlets so that your users can use them, you need to add them as
unscoped role entries to an unscoped top-level role. For more information about unscoped role
entries, see Unscoped Top-Level Role Entries later in this topic.
All role entries, regardless of whether the role entry is an Exchange cmdlet-based role entry or an
unscoped role entry, adhere to the same principles explained in the following sections.
For more information about managing role entries, see Management roles and role entries.

Parent and child management role relationship

As mentioned previously, a management role entry, including the cmdlet and its parameters, must
exist in the immediate parent role to add the entry to the child role. For example, if the parent role
doesn't have an entry for New-Mailbox, the child role can't be assigned that cmdlet. Additionally,
if Set-Mailbox is on the parent role but the Database parameter has been removed from the entry,
the Database parameter on the Set-Mailbox cmdlet can't be added to the entry on the child role.
Because you can't add management role entries to child roles if the entries don't appear in parent
roles, and because the role is based on a specific role type, you must carefully choose the parent
role to copy when you want to create a customized role.

Management role entry names

Management role entry names are a combination of the management role that they're associated
with, and the name of the cmdlet or script. The role name and the cmdlet or script are separated by
a backslash character (\). For example, the role entry name for the Set-Mailbox cmdlet on the Mail
Recipients role is Mail Recipients\Set-Mailbox . If the name of a role entry contains spaces, enclose
the entire name in quotation marks (").
The wildcard character (*) can be used in the role entry name to return all of the role entries that
match the input you provide. The wildcard character can be used on either side of the backslash
character. The following table contains a few variations on how you can use the wildcard character
in a role entry name.
Management role entry name with wildcard characters

EXAMPLE DESCRIPTION

*\* Returns a list of all role entries for all roles.

*\Set-Mailbox Returns a list of all role entries that contain the

Set-Mailbox cmdlet.

Mail Recipients\* Returns a list of all role entries on the Mail

Recipients role.
 EXAMPLE DESCRIPTION

Mail Recipients\*Mailbox Returns a list of all role entries on the Mail

Recipients role that contain cmdlets that end in
Mailbox.

My*\*Group* Returns a list of all role entries that contain the

string Group in the cmdlet name for all roles that
begin with My.

Unscoped top-level role entries

Unscoped top-level role entries are used with unscoped top-level management roles to create roles
based on custom scripts or non-Exchange cmdlets. Each unscoped role entry is associated with a
single custom script or a non-Exchange cmdlet. To indicate that you want to create an unscoped role
entry on an unscoped role, you need to specify the UnscopedTopLevel parameter on the Add-
ManagementRoleEntry cmdlet.
When you add the unscoped role entry, you need to specify all of the parameters that can be used
with the script or non-Exchange cmdlet. Exchange attempts to verify the parameters that you
provide when you add the role entry. Only the parameters that you add to the role entry when it's
created will be available to the users assigned to the unscoped role. If you add parameters to the
script or non-Exchange cmdlet, or if a parameter is renamed, you must update the role entry
manually. Exchange doesn't check whether existing parameters on an unscoped role entry have
changed. If a parameter on a role entry changes in a script and you try to use that parameter, the
command fails.
Scripts that you add to an unscoped role entry must reside in the Exchange 2013 scripts directory
on every server where administrators and users connect using the Exchange Management Shell. If
you try to add an unscoped role entry based on a script that doesn't exist in the Exchange 2013
scripts directory on the server you're using to add the role entry, an error occurs. The default
installation location of the Exchange 2013 scripts directory is C:\Program Files\Microsoft\Exchange
Server\V15\RemoteScripts.
Non-Exchange cmdlets that you add to an unscoped role entry must be installed on every
Exchange 2013 server where administrators and users connect using the Shell and want to use the
cmdlets. If you try to add an unscoped role entry based on a non-Exchange cmdlet that isn't
installed on the Exchange 2013 server you're using to add the role entry, an error occurs. When you
add a non-Exchange cmdlet, you must specify the Windows PowerShell snap-in name that contains
the non-Exchange cmdlet.
For more information about how to add an unscoped management role entry, see Add a role entry
to a role.

Management role types

Management role types are the foundation of all management roles. Types define the implicit
scopes defined on all management roles of a specified role type and also act as a logical grouping
of related roles. All management roles derived from the parent built-in management role have the
same role type. Refer to the Management role hierarchy figure earlier in this topic for an illustration
of this relationship. Management role types also represent the maximum set of cmdlets and their
parameters that can be added to a role associated with a role type.
Management role types are split into the following categories:
Administrative or specialist: Roles associated with an administrative or specialist role
types have a broader scope of impact in the Exchange organization. Roles of this role type
enable tasks such as server or recipient management, organization configuration,
compliance administration, auditing, and more.
User-focused: Roles associated with a user-focused role type have a scope of impact closely
tied with an individual user. Roles of this role type enable tasks such as user profile
configuration and self management, management of user-owned distribution groups, and
more.
The names of roles associated with user-focused role types and user-focused role type
names begin with My.
Specialty: Roles associated with specialty role types enable tasks that aren't administrative
or user-focused role types. Roles of this role type enable tasks such as application
impersonation and the use of non-Exchange cmdlets or scripts.
The following table lists all of the administrative management role types in Exchange 2013 and
whether the configuration that's permitted by the role type is applied across the whole Exchange
organization or only to an individual server. For more information about each of the management
roles associated with these role types, including a description of each role, who may benefit from
being assigned the role, and other information, see Built-in management roles.
Administrative role types

BUILT-IN MANAGEMENT ORGANIZATION OR

MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

Active Directory
ActiveDirectoryPermissions This role type is Organization
Permissions role associated with roles
that enable
administrators to
configure Active
Directory
permissions in an
organization. Some
features that use
Active Directory
permissions or an
access control list
(ACL) include
transport Receive
and Send
connectors, and
Send As and send
on behalf
permissions for
mailboxes.

NOTE
Permissions set
directly on Active
Directory objects
may not be
enforced
through RBAC.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

AddressLists Address Lists role This role type is Organization

associated with roles
that enable
administrators to
manage address
lists, the global
address list (GAL),
and offline address
lists in an
organization.

ApplicationImpersonation ApplicationImperson This role type is Organization

ation role associated with roles
that enable
applications to
impersonate users
in an organization
to perform tasks on
behalf of the user.

ArchiveApplication ArchiveApplication This role type is Organization

role associated with roles
that enable partner
applications to
archive items in user
mailboxes in an
organization.

AuditLogs Audit Logs role This role type is Organization

associated with roles
that enable
administrators to
manage the
administrator audit
logging
configuration in an
organization.

CmdletExtensionAgents Cmdlet Extension This role type is Organization

Agents role associated with roles
that enable
administrators to
manage cmdlet
extension agents in
an organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

DataLossPrevention Data Loss This role type is Organization

Prevention role associated with roles
that create and
manage data loss
prevention (DLP)
policies and the
rules within them in
an organization.

Database Availability
DatabaseAvailabilityGroups This role type is Organization
Groups role associated with roles
that enable
administrators to
manage database
availability groups
(DAGs) in an
organization.
Administrators
assigned this role
either directly or
indirectly are the
highest level
administrators
responsible for the
high availability
configuration in an
organization.

DatabaseCopies Database Copies This role type is Server

role associated with roles
that enable
administrators to
manage database
copies on individual
servers.

Databases Databases role This role type is Server

associated with roles
that enable
administrators to
create, manage,
mount, and
dismount mailbox
databases on
individual servers.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

DisasterRecovery Disaster Recovery This role type is Organization

role associated with roles
that enable
administrators to
restore mailboxes
and mailbox
databases, create
mailbox databases,
and perform
datacenter
switchovers and
switchbacks for
database availability
groups in an
organization.

DistributionGroups Distribution Groups This role type is Organization

role associated with roles
that enable
administrators to
create and manage
distribution groups
and distribution
group members in
an organization.

EdgeSubscriptions Edge Subscriptions This role type is Organization

role associated with roles
that enable
administrators to
manage edge
synchronization and
subscription
configuration
between Exchange
2010 Edge
Transport servers
and Exchange 2013
Mailbox servers in
an organization.

EmailAddressPolicies E-Mail Address This role type is Organization

Policies role associated with roles
that enable
administrators to
manage email
address policies in
an organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

ExchangeConnectors Exchange This role type is Organization

Connectors role associated with roles
that enable
administrators to
create, modify, view,
and remove delivery
agent connectors.

Exchange Server
ExchangeServerCertificates This role type is Server
Certificates role associated with roles
that enable
administrators to
create, import,
export, and manage
Exchange server
certificates on
individual servers.

ExchangeServers Exchange Servers This role type is Server

role associated with roles
that enable
administrators to
manage Exchange
server configuration
on individual
servers.

Exchange Virtual
ExchangeVirtualDirectories This role type is Server
Directories role associated with roles
that enable
administrators to
manage Outlook
Web App, Microsoft
ActiveSync, offline
address book (OAB),
Autodiscover,
Windows
PowerShell, and
Exchange admin
center virtual
directories on
individual servers.

FederatedSharing Federated Sharing This role type is Organization

role associated with roles
that enable
administrators to
manage cross-forest
and cross-
organization sharing
in an organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

Information
InformationRightsManagement Rights This role type is Organization
Management role associated with roles
that enable
administrators to
manage the
Information Rights
Management (IRM)
features of Exchange
in an organization.

Journaling Journaling role This role type is Organization

associated with roles
that enable
administrators to
manage journaling
configuration in an
organization.

LegalHold Legal Hold role This role type is Organization

associated with roles
that enable
administrators to
configure whether
data within a
mailbox should be
retained for
litigation purposes
in an organization.

MailboxImportExport Mailbox Import This role type is Organization

Export role associated with roles
that enable
administrators to
import and export
mailbox content and
to purge unwanted
content from a
mailbox.

MailboxSearch Mailbox Search role This role type is Organization

associated with roles
that enable
administrators to
search the content
of one or more
mailboxes in an
organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

MailboxSearchApplication MailboxSearchApplic This role type is Organization

ation role associated with roles
that enable partner
applications to set
and view the legal
hold status of a
mailbox in an
organization.

MailEnabledPublicFolders Mail Enabled Public This role type is Organization

Folders role associated with roles
that enable
administrators to
configure whether
individual public
folders are mail-
enabled or mail-
disabled in an
organization.
This role type
enables you to
manage the email
properties of public
folders only. It
doesn't enable you
to manage
properties of public
folders that aren't
email properties. To
manage properties
of public folders that
aren't email
properties, you
need to be assigned
a role associated
with the
PublicFolders
role type.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

MailRecipientCreation Mail Recipient This role type is Organization

Creation role associated with roles
that enable
administrators to
create mailboxes,
mail users, mail
contacts,
distribution groups,
and dynamic
distribution groups
in an organization.
Roles associated
with this role type
can be combined
with roles associated
with the
MailRecipients
role type to enable
the creation and
management of
recipients.
This role type
doesn't enable you
to mail-enable
public folders. To
mail-enable public
folders, you must be
assigned a role
associated with the
MailEnabledPublicFolders
role type.
If your organization
maintains a split
permissions model
where recipient
creation is
performed by a
different group from
the group that
performs recipient
management, assign
the
MailRecipientCreation
role to the group
that performs
recipient creation,
and the
MailRecipients
role to the group
that performs
recipient
management.

MailRecipients Mail Recipients role This role type is Organization

associated with roles
that enable
administrators to
manage existing
 mailboxes, mail
BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE users, mail contacts,
DESCRIPTION SERVER
distribution groups,
and dynamic
distribution groups
in an organization.
Roles associated
with this role type
can't create these
recipients but can
be combined with
roles associated with
the
MailRecipientCreation
role type to enable
the creation and
management of
recipients.
This role type
doesn't enable you
to manage mail-
enabled public
folders or
distribution groups.
To manage mail-
enabled public
folders, you must be
assigned a role
associated with the
MailEnabledPublicFolders
role type. To
manage distribution
groups, you must
be assigned a role
associated with the
DistributionGroups
role type.
If your organization
maintains a split
permissions model
where recipient
creation is
performed by a
different group from
the group that
performs recipient
management, assign
the
MailRecipientCreation
role to the group
that performs
recipient creation,
and the
MailRecipients
role to the group
that performs
recipient
management.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

MailTips Mail Tips role This role type is Organization

associated with roles
that enable
administrators to
manage MailTips in
an organization.

MessageTracking Message Tracking This role type is Organization

role associated with roles
that enable
administrators to
track messages in
an organization.

Migration Migration role This role type is Server

associated with roles
that enable
administrators to
migrate mailboxes
and mailbox content
into or out of a
server.

Monitoring Monitoring role This role type is Organization

associated with roles
that enable
administrators to
monitor the
Microsoft Exchange
services and
component
availability in an
organization. In
addition to
administrators, roles
associated with this
role type can be
used with the
service account
used by monitoring
applications to
collect information
about the state of
Exchange servers.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

MoveMailboxes Move Mailboxes This role type is Organization

role associated with roles
that enable
administrators to
move mailboxes
between servers in
an organization and
between servers in
the local
organization and
another
organization.

OfficeExtensionAppli
OfficeExtensionApplication This role type is Organization
cation role associated with roles
that enable
Microsoft Office
extension
applications to
access user
mailboxes in an
organization.

OrgCustomApps Org Custom Apps This role type is Organization

role associated with roles
that enable
administrators to
view and modify
their organization's
custom apps in an
organization.

OrgMarketplaceApps Org Marketplace This role type is Organization

Apps role associated with roles
that enable
administrators to
view and modify
their organization's
marketplace apps in
an organization.

OrganizationClientAccess Organization Client This role type is Organization

Access role associated with roles
that enable
administrators to
manage Client
Access server
settings in an
organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

OrganizationConfigurationOrganization This role type is Organization

Configuration role associated with roles
that enable
administrators to
manage
organization-wide
settings in an
organization.
Organization
configuration that
can be controlled
with this role type
include the following
and more:
Whether
MailTips are
enabled or
disabled for
the
organization.
The URL for
the managed
folder home
page.
The
Microsoft
Exchange
recipient
SMTP
address and
alternate
email
addresses.
The resource
mailbox
property
schema
configuration
.
The Help
URLs for the
Exchange
admin center
and Outlook
Web App.
This role type
doesn't include the
permissions
included in the
OrganizationClientAccess
or
OrganizationTransportSettings
role types.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

Organization
OrganizationTransportSettings This role type is Organization
Transport Settings associated with roles
role that enable
administrators to
manage
organization-wide
transport settings,
such as system
messages, Active
Directory site
configuration, and
other organization-
wide transport
settings in an
organization.
This role doesn't
enable you to create
or manage
transport Receive or
Send connectors,
queues, hygiene,
agents, remote and
accepted domains,
or rules. To create or
manage each of the
transport features,
you must be
assigned roles
associated with the
following role types:
Receive
connectors

ReceiveConnectors

Send
connectors

SendConnectors

Transport
queues
TransportQueues

Transport
hygiene
TransportHygiene

Transport
agents
TransportAgents

Remote and
accepted
domains
RemoteAndAcceptedDomains

Transport
rules
TransportRules
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

POP3AndIMAP4Protocols POP3 and IMAP4 This role type is Server

Protocols role associated with roles
that enable
administrators to
manage POP3 and
IMAP4
configuration, such
as authentication
and connection
settings, on
individual servers.

PublicFolders Public Folders role This role type is Organization

associated with roles
that enable
administrators to
manage public
folders in an
organization.
This role type
doesn't enable you
to manage whether
public folders are
mail-enabled. To
mail-enable or
disable a public
folder, you must be
assigned a role
associated with the
MailEnabledPublicFolders
role type.

ReceiveConnectors Receive Connectors This role type is Server

role associated with roles
that enable
administrators to
manage transport
Receive connector
configuration, such
as size limits on an
individual server.

RecipientPolicies Recipient Policies This role type is Organization

role associated with roles
that enable
administrators to
manage recipient
policies, such as
provisioning and
mobile device
policies, in an
organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

RemoteAndAcceptedDomains Remote and This role type is Organization

Accepted Domains associated with roles
role that enable
administrators to
manage remote and
accepted domains in
an organization.

ResetPassword Reset Password role This role type is Organization

associated with roles
that enable users to
reset their own
passwords and
administrators to
reset users'
passwords in an
organization.

RetentionManagement Retention This role type is Organization

Management role associated with roles
that enable
administrators to
manage retention
policies in an
organization.

RoleManagement Role Management This role type is Organization

role associated with roles
that enable
administrators to
manage
management role
groups, role
assignment policies,
management roles,
role entries,
assignments, and
scopes in an
organization.
Users assigned roles
associated with this
role type can
override the role
group managed
by property,
configure any role
group, and add or
remove members to
or from any role
group.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

Security Group
SecurityGroupCreationAndMembership This role type is Organization
Creation and associated with roles
Membership role that enable
administrators to
create and manage
USGs and their
memberships in an
organization.
If your organization
maintains a split
permissions model
where USG creation
and management is
performed by a
different group from
the group that
manages Exchange
servers, assign roles
associated with this
role type to that
group.

SendConnectors Send Connectors This role type is Organization

role associated with roles
that enable
administrators to
manage transport
Send connectors in
an organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

SupportDiagnostics Support Diagnostics This role type is Organization

role associated with roles
that enable
administrators to
perform advanced
diagnostics under
the direction of
Microsoft support
services in an
organization.

WARNING
Roles associated
with this role
type grant
permissions to
cmdlets and
scripts that
should only be
used under the
direction of
Microsoft
Customer
Service and
Support.

TeamMailboxes Team Mailboxes role This role type is Organization

associated with roles
that enable
administrators to
define one or more
site mailbox
provisioning policies
and manage site
mailboxes in an
organization.
Administrators
assigned roles
associated with this
role type can
manage site
mailboxes they don't
own.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

TeamMailboxLifecycl
TeamMailboxLifecycleApplication This role type is Organization
eApplication role associated with roles
that enable partner
applications to
update site mailbox
lifecycle states in an
organization.

TransportAgents Transport Agents This role type is Organization

role associated with roles
that enable
administrators to
manage transport
agents in an
organization.

TransportHygiene Transport Hygiene This role type is Organization

role associated with roles
that enable
administrators to
manage anti-spam
and anti-malware
features in an
organization.

TransportQueues Transport Queues This role type is Server

role associated with roles
that enable
administrators to
manage transport
queues on an
individual server.

TransportRules Transport Rules role This role type is Organization

associated with roles
that enable
administrators to
manage transport
rules in an
organization.

UMMailboxes UM Mailboxes role This role type is Organization

associated with roles
that enable
administrators to
manage the Unified
Messaging (UM)
configuration of
mailboxes and other
recipients in an
organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

UMPrompts UM Prompts role This role type is Organization

associated with roles
that enable
administrators to
create and manage
custom UM voice
prompts in an
organization.

UnifiedMessaging Unified Messaging This role type is Organization

role associated with roles
that enable
administrators to
manage Unified
Messaging services
in an organization.
This role doesn't
enable you to
manage UM-specific
mailbox
configuration or UM
prompts. To manage
UM-specific mailbox
configuration, use
roles associated with
the UMMailboxes
role type. To
manage UM
prompts, use the
roles associated with
the UMPrompts role
type.

UnScopedRoleManagement Unscoped Role This role type is Organization

Management role associated with roles
that enable
administrators to
create and manage
unscoped top-level
management roles
in an organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

UserOptions User Options role This role type is Organization

associated with roles
that enable
administrators to
view the Outlook
Web App options of
a user in an
organization. Roles
associated with this
role type can be
used to help a user
with diagnosing
problems with his or
her configuration.

UserApplication UserApplication role This role type is Organization

associated with roles
that enable partner
applications to act
on behalf of end
users in an
organization.

ViewOnlyAuditLogs View-Only Audit This role type is Organization

Logs role associated with roles
that enable
administrators to
search the
administrator audit
log in an
organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

ViewOnlyConfiguration View-Only This role type is Organization

Configuration role associated with roles
that enable
administrators to
view all of the non-
recipient Exchange
configuration
settings in an
organization.
Examples of
configuration that
are viewable are
server configuration,
transport
configuration,
database
configuration, and
organization-wide
configuration.
Roles associated
with this role type
can be combined
with roles associated
with the
ViewOnlyRecipients
role type to create a
role that can view
every object in an
organization.

ViewOnlyRecipients View-Only This role type is Organization

Recipients role associated with roles
that enable
administrators to
view the
configuration of
recipients, such as
mailboxes, mail
users, mail contacts,
distribution groups,
and dynamic
distribution groups.
Roles associated
with this role type
can be combined
with roles associated
with the
ViewOnlyConfiguration
role type to create a
role that can view
every object in the
organization.
 BUILT-IN MANAGEMENT ORGANIZATION OR
MANAGEMENT ROLE TYPE ROLE DESCRIPTION SERVER

WorkloadManagement WorkloadManagem This role type is Organization

ent role associated with roles
that enable
administrators to
manage workload
management
policies in an
organization.
Administrators can
configure resource
health definitions,
workload
classifications, and
enable or disable
workload
management.

The following table lists all of the user-focused management role types and their associated built-in
management roles in Exchange 2013.
User-focused role types

MANAGEMENT ROLE TYPE BUILT-IN USER-FOCUSED ROLES DESCRIPTION

MyBaseOptions MyBaseOptions role This role type is associated

with roles that enable
individual users to view and
modify the basic configuration
of their own mailbox and
associated settings.

MyContactInformation MyAddressInformation role This role type is associated

with roles that enable
MyContactInformation role individual users to modify
MyMobileInformation role their contact information. This
information includes their
MyPersonalInformation role address and phone numbers.

MyCustomApps My Custom Apps role This role type is associated

with roles that enable
individual users to view and
modify their custom apps.

MyDiagnostics MyDiagnostics role This role type is associated

with roles that enable
individual users to perform
basic diagnostics on their
mailbox, such as retrieving
calendar diagnostic
information.
MANAGEMENT ROLE TYPE BUILT-IN USER-FOCUSED ROLES DESCRIPTION

MyDistributionGroupMembership MyDistributionGroupMember This role type is associated

ship role with roles that enable
individual users to view and
modify their membership in
distribution groups in an
organization, provided that
those distribution groups
allow manipulation of group
membership.

MyDistributionGroups MyDistributionGroups role This role type is associated

with roles that enable
individual users to create,
modify, and view distribution
groups and modify, view,
remove, and add members to
distribution groups they own.

MyProfileInformation MyDisplayName role This role type is associated

with roles that enable
MyName role individual users to modify
MyProfileInformation role their name.

MyMarketplaceApps My Marketplace Apps role This role type is associated

with roles that enable
individual users to view and
modify their marketplace
apps.

MyRetentionPolicies MyRetentionPolicies role This role type is associated

with roles that enable
individual users to view their
retention tags and view and
modify their retention tag
settings and defaults.

MyTeamMailboxes MyTeamMailboxes role This role type is associated

with roles that enable
individual users to create site
mailboxes and connect them
to Microsoft SharePoint sites.

MyTextMessaging MyTextMessaging role This role type is associated

with roles that enable
individual users to create,
view, and modify their text
messaging settings.
 MANAGEMENT ROLE TYPE BUILT-IN USER-FOCUSED ROLES DESCRIPTION

MyVoiceMail MyVoiceMail role This role type is associated

with roles that enable
individual users to view and
modify their voice mail
settings.

For more information

New -ManagementRole
New -ManagementRoleAssignment
Set-ManagementRoleAssignment
New -ManagementScope
Set-ManagementScope
New -ManagementRoleAssignment
Set-ManagementRoleAssignment
 Understanding management role scopes
5/28/2019 • 23 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role scopes enable you to define the specific scope of impact or influence of a
management role when a management role assignment is created. When you apply a scope,
the role assignee assigned to the role can only modify the objects contained within that scope.
A role assignee can be a management role group, management role, management role
assignment policy, user, or universal security group (USG ). For more information about
management roles, see Understanding Role Based Access Control.

NOTE
This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2013
permissions, such as using the Exchange admin center (EAC) to add and remove members to and from
role groups, create and modify role groups, or create and modify role assignment policies, see
Permissions.

Every management role, whether it's a built-in role or a custom role, has management scopes.
Management scopes can be either of the following:
Regular: A regular scope isn't exclusive. It determines where, in Active Directory, objects
can be viewed or modified by users assigned the management role. In general, a
management role indicates what you can create or modify, and a management role
scope indicates where you can create or modify. Regular scopes can be either implicit or
explicit scopes, both of which are discussed later in this topic.
Exclusive: An exclusive scope behaves almost the same as a regular scope. The key
difference is that it enables you to deny users access to objects contained within the
exclusive scope if those users aren't assigned a role associated with the exclusive scope.
All exclusive scopes are explicit scopes, which are discussed later in this topic.
For more information about exclusive scopes, see Understanding exclusive scopes.
Scopes can be inherited from the management role, specified as a predefined relative scope on
a management role assignment, or created using custom filters and added to a management
role assignment. Scopes inherited from management roles are called implicit scopes while
predefined and custom scopes are called explicit scopes. The following sections describe each
type of scope:
Implicit Scopes
Explicit Scopes
Predefined Relative Scopes
Custom Scopes
Recipient Filter Scopes
Configuration Scopes
Each role can have the following types of scopes:
 Recipient read scope: The implicit recipient read scope determines what recipient
objects the user assigned the management role is allowed to read from Active Directory.
Recipient write scope: The implicit recipient write scope determines what recipient
objects the user assigned the management role is allowed to modify in Active Directory.
Configuration read scope: The implicit configuration read scope determines what
configuration objects the user assigned the management role is allowed to read from
Active Directory.
Configuration write scope: The implicit configuration write scope determines what
organizational, database, and server objects the user assigned the management role is
allowed to modify in Active Directory.
Recipient objects include mailboxes, distribution groups, mail enabled users, and other objects.
Configuration objects include servers running Microsoft Exchange Server 2013, and databases
located on servers running Exchange. Each type of scope can be either an implicit scope or
explicit scope.

Implicit scopes
Implicit scopes are the default scopes that apply to a management role type. Because implicit
scopes are associated with a management role type, all of the parent and child management
roles with the same role type also have the same implicit scopes. Implicit scopes apply to both
built-in management roles and also to custom management roles. For more information about
management roles and management role types, see Understanding management roles.
The following tables list all of the implicit scopes that can be defined on management roles.
Implicit scopes defined on management roles
IMPLICIT SCOPES DESCRIPTION

Organization If Organization is present in the role's

recipient write scope, the role can create or
modify recipient objects across the Exchange
organization.
If Organization is present in the role's
recipient read scope, roles can view any
recipient object across the Exchange
organization.
This scope is used only with recipient read and
write scopes.

MyGAL If MyGAL is present in the role's recipient write

scope, the role can view the properties of any
recipient within the current user's global
address list (GAL).
If MyGAL is present in the role's recipient read
scope, the role can view the properties of any
recipient within the current GAL.
This scope is used only with recipient read
scopes.
 IMPLICIT SCOPES DESCRIPTION

Self If Self is present in the role's recipient write

scope, the role can modify only the properties
of the current user's mailbox.
If Self is present in the role's recipient read
scope, the role can view only the properties of
the current user's mailbox.
This scope is used only with recipient read and
write scopes.

MyDistributionGroups If MyDistributionGroups is present in the

role's recipient write scope, the role can create
or modify distribution list objects owned by
the current user.
If MyDistributionGroups is present in the
role's recipient read scope, the role can view
distribution list objects owned by the current
user.
This scope is used only with recipient read and
write scopes.

OrganizationConfig If OrganizationConfig is present in the role's

configuration write scope, the role can create
or modify any server or database configuration
object across the Exchange organization.
If OrganizationConfig is present in the role's
configuration read scope, the role can view any
server or database configuration object across
the Exchange organization.
This scope is used only with configuration read
and write scopes.

None If None is in a scope, that scope isn't available

to the role. For example, a role that has None
in the recipient write scope can't modify
recipient objects in the Exchange organization.

If a role is assigned to a role assignee and no predefined or custom scopes are specified, the
implicit scopes defined on the role are used to control the recipient or organization objects the
user can view or modify.
The implicit write scope of a role is always equal to, or less than, the implicit read scope. This
means that a role can never modify objects that can't be seen by the scope.
You can't change the implicit scopes defined on management roles. You can, however, override
the implicit write scope and configuration scope on a management role. When a predefined
relative scope or custom scope is used on a role assignment, the implicit write scope of the role
is overridden, and the new scope takes precedence. The implicit read scope of a role can't be
overridden and always applies. For more information, see Predefined Relative Scopes and
Custom Scopes.
Expand the following table to see a list of all the built-in management roles and their implicit
scopes. For more information about each built-in role, see Built-in management roles.

Built-in management role implicit scopes

MANAGEMENT RECIPIENT READ RECIPIENT WRITE CONFIGURATION CONFIGURATION
ROLE SCOPE SCOPE READ SCOPE WRITE SCOPE

Active Organization Organization OrganizationConfig OrganizationConfig

Directory
Permissions

Address Organization Organization OrganizationConfig OrganizationConfig

Lists

ApplicationImpersonation
Organization Organization None None

ArchiveApplication Organization Organization OrganizationConfig OrganizationConfig

Audit Logs Organization Organization OrganizationConfig OrganizationConfig

Cmdlet Organization Organization OrganizationConfig OrganizationConfig

Extension
Agents

Data Loss Organization Organization OrganizationConfig OrganizationConfig

Prevention

Database Organization Organization OrganizationConfig OrganizationConfig

Availability
Groups

Database Organization Organization OrganizationConfig OrganizationConfig

Copies

Databases Organization Organization OrganizationConfig OrganizationConfig

Disaster Organization Organization OrganizationConfig OrganizationConfig

Recovery

Distribution Organization Organization OrganizationConfig OrganizationConfig

Groups

Edge Organization Organization OrganizationConfig OrganizationConfig

Subscriptions
MANAGEMENT RECIPIENT READ RECIPIENT WRITE CONFIGURATION CONFIGURATION
ROLE SCOPE SCOPE READ SCOPE WRITE SCOPE

E-Mail Organization Organization OrganizationConfig OrganizationConfig

Address
Policies

Exchange Organization Organization OrganizationConfig OrganizationConfig

Connectors

Exchange Organization Organization OrganizationConfig OrganizationConfig

Server
Certificates

Exchange Organization Organization OrganizationConfig OrganizationConfig

Servers

Exchange Organization Organization OrganizationConfig OrganizationConfig

Virtual
Directories

Federated Organization Organization OrganizationConfig OrganizationConfig

Sharing

Information Organization Organization OrganizationConfig OrganizationConfig

Rights
Management

Journaling Organization Organization OrganizationConfig OrganizationConfig

Legal Hold Organization Organization OrganizationConfig None

LegalHoldApplicationOrganization Organization OrganizationConfig OrganizationConfig

Mail Organization Organization OrganizationConfig OrganizationConfig

Enabled
Public
Folders

Mail Organization Organization OrganizationConfig OrganizationConfig

Recipient
Creation

Mail Organization Organization OrganizationConfig OrganizationConfig

Recipients

Mail Tips Organization Organization OrganizationConfig OrganizationConfig

MANAGEMENT RECIPIENT READ RECIPIENT WRITE CONFIGURATION CONFIGURATION
ROLE SCOPE SCOPE READ SCOPE WRITE SCOPE

Mailbox Organization Organization OrganizationConfig OrganizationConfig

Import
Export

Mailbox Organization Organization None None

Search

MailboxSearchApplication
Organization Organization OrganizationConfig OrganizationConfig

Message Organization Organization OrganizationConfig OrganizationConfig

Tracking

Migration Organization Organization OrganizationConfig OrganizationConfig

Monitoring Organization Organization OrganizationConfig OrganizationConfig

Move Organization Organization OrganizationConfig OrganizationConfig

Mailboxes

OfficeExtensionApplication
Self Self OrganizationConfig OrganizationConfig

My Custom Self Self OrganizationConfig OrganizationConfig

Apps

My Self Self OrganizationConfig OrganizationConfig

Marketplace
Apps

MyAddressInformationSelf Self OrganizationConfig OrganizationConfig

MyBaseOptions Self Self OrganizationConfig OrganizationConfig

MyContactInformationSelf Self OrganizationConfig OrganizationConfig

MyDiagnostics Self Self OrganizationConfig OrganizationConfig

MyDisplayName Self Self OrganizationConfig OrganizationConfig

MyDistributionGroupMembership
MyGAL MyGAL None None
MANAGEMENT RECIPIENT READ RECIPIENT WRITE CONFIGURATION CONFIGURATION
ROLE SCOPE SCOPE READ SCOPE WRITE SCOPE

MyDistributionGroupsMyGAL MyDistributionGroupsOrganizationConfig None

MyMobileInformation Self Self OrganizationConfig OrganizationConfig

MyName Self Self OrganizationConfig OrganizationConfig

MyPersonalInformation
Self Self OrganizationConfig OrganizationConfig

MyProfileInformationSelf Self OrganizationConfig OrganizationConfig

MyRetentionPolicies Self Self OrganizationConfig OrganizationConfig

MyTeamMailboxes Organization Organization OrganizationConfig OrganizationConfig

MyTextMessaging Self Self OrganizationConfig OrganizationConfig

MyVoiceMail Self Self OrganizationConfig OrganizationConfig

Organization Organization Organization OrganizationConfig OrganizationConfig

Client
Access

Organization Organization Organization OrganizationConfig OrganizationConfig

Configuration

Organization Organization Organization OrganizationConfig OrganizationConfig

Transport
Settings

POP3 And Organization Organization OrganizationConfig OrganizationConfig

IMAP4
Protocols

Public Organization Organization OrganizationConfig OrganizationConfig

Folders

Receive Organization Organization OrganizationConfig OrganizationConfig

Connectors

Recipient Organization Organization OrganizationConfig OrganizationConfig

Policies
MANAGEMENT RECIPIENT READ RECIPIENT WRITE CONFIGURATION CONFIGURATION
ROLE SCOPE SCOPE READ SCOPE WRITE SCOPE

Remote and Organization Organization OrganizationConfig OrganizationConfig

Accepted
Domains

Reset Organization Organization OrganizationConfig OrganizationConfig

Password

Retention Organization Organization OrganizationConfig OrganizationConfig

Management

Role Organization Organization OrganizationConfig OrganizationConfig

Management

Security Organization Organization OrganizationConfig OrganizationConfig

Group
Creation
and
Membership

Send Organization Organization OrganizationConfig OrganizationConfig

Connectors

Support Organization Organization OrganizationConfig OrganizationConfig

Diagnostics

TeamMailboxLifecycleApplication
Self Self OrganizationConfig OrganizationConfig

Transport Organization Organization OrganizationConfig OrganizationConfig

Agents

Transport Organization Organization OrganizationConfig OrganizationConfig

Hygiene

Transport Organization Organization OrganizationConfig OrganizationConfig

Queues

Transport Organization Organization OrganizationConfig OrganizationConfig

Rules

UM Organization Organization OrganizationConfig OrganizationConfig

Mailboxes

UM Prompts Organization Organization OrganizationConfig OrganizationConfig

 MANAGEMENT RECIPIENT READ RECIPIENT WRITE CONFIGURATION CONFIGURATION
ROLE SCOPE SCOPE READ SCOPE WRITE SCOPE

Unified Organization Organization OrganizationConfig OrganizationConfig

Messaging

UnScoped Organization Organization OrganizationConfig OrganizationConfig

Role
Management

UserApplication Organization Organization OrganizationConfig OrganizationConfig

User Organization Organization OrganizationConfig OrganizationConfig

Options

View-Only Organization None OrganizationConfig None

Audit Logs

View-Only Organization None OrganizationConfig None

Configuration

View-Only Organization None OrganizationConfig None

Recipients

WorkloadManagement Organization Organization OrganizationConfig OrganizationConfig

Explicit scopes
Explicit scopes are scopes that you set yourself to control which objects a management role can
modify. Although implicit scopes are defined on a management role, explicit scopes are defined
on a management role assignment. This enables the implicit scopes to be applied consistently
across all management roles unless you choose to use an overriding explicit scope. For more
information about management role assignments, see Understanding management role
assignments.
Explicit scopes override the implicit write and configuration scopes of a management role. They
don't override the implicit read scope of a management role. The implicit read scope continues
to define what objects the management role can read.
Explicit scopes are useful when the implicit write scope of a management role doesn't meet the
needs of your business. You can add an explicit scope to include nearly anything you want as
long as the new scope doesn't exceed the bounds of the implicit read scope. The cmdlets that
are part of a management role must be able to read information about the objects or
containers that contain objects for the cmdlets to create or modify objects. For example, if the
implicit read scope on a management role is set to Self , you can't add an explicit write scope
of Organization because the explicit write scope exceeds the bounds of the implicit read scope.
For more information, see the following sections:
Predefined Relative Scopes
 Custom Scopes

Predefined relative scopes

Exchange 2013 provides several predefined relative write scopes that you can use to modify
scope of a management role. Predefined relative scopes provide an easy way for you to more
closely match the needs of your business without having to create custom scopes manually.
They're called relative scopes because they're relative to the role assignee to which the
associated role assignment is assigned. For example, the Self predefined relative scope
restricts that write scope to the current user only. The MyDistributionGroups predefined relative
scope restricts the write scope to the distribution group the current user owns only. Predefined
relative scopes can only be used to scope recipient objects. Predefined relative scopes can't be
used to scope configuration objects. The following table lists the predefined relative scopes that
you can use.
Predefined relative scopes
IMPLICIT SCOPES DESCRIPTION

Organization If Organization is present in the role's

recipient write scope, the role can create or
modify recipient objects across the Exchange
organization.
If Organization is present in the role's
recipient read scope, roles can view any
recipient object across the Exchange
organization.
This scope is used only with recipient read and
write scopes.

Self If Self is present in the role's recipient write

scope, the role can modify only the properties
of the current user's mailbox.
If Self is present in the role's recipient read
scope, the role can view only the properties of
the current user's mailbox.
This scope is used only with recipient read and
write scopes.

MyDistributionGroups If MyDistributionGroups is present in the

role's recipient write scope, the role can create
or modify distribution list objects owned by
the current user.
If MyDistributionGroups is present in the
role's recipient read scope, the role can view
distribution list objects owned by the current
user.
This scope is used only with recipient read and
write scopes.

Predefined relative scopes are applied when you create a new management role assignment.
During the creation of the role assignment, using the New-ManagementRoleAssignment
cmdlet, you can specify a predefined relative scope using the RecipientRelativeWriteScope
parameter. When the new role assignment is created, the new predefined role overrides the
implicit write scope of the management role. You can't specify a custom recipient scope when
you create a role assignment with a predefined relative scope. You can, however, specify a
custom configuration scope if needed.
For more information about how to add a management role assignment with a predefined
relative scope, see Add a role to a user or USG.

Custom scopes
Custom scopes are needed when neither the implicit write scope nor the predefined relative
scopes meet the needs of your business. Custom scopes enable you to define, at a granular
level, the scope to which your management role will be applied. For example, you might want
to target a specific organizational unit (OU ), a specific type of recipient, or both. Or, you might
only want to allow a group of administrators to be able to manage a specific set of mailbox
databases.
As with predefined relative scopes, custom scopes override the implicit write and organization
configuration scopes defined on management roles. The implicit read scope on management
roles continue to apply and the resulting custom scope must not exceed the boundaries of the
implicit read scope. You can create the following three types of custom scopes:
OU scope: An OU scope, which is the simplest custom scope, is created using the
RecipientOrganizationalUnitScope parameter on the New-
ManagementRoleAssignment cmdlet. By specifying an OU scope when a role is
assigned, the role assignee assigned the role can modify only recipient objects within
that OU. For more information about how to add a management role assignment with
an OU scope, see Add a role to a user or USG.
Recipient filter scope: Recipient filter scopes use filters to target specific recipients
based on recipient type or other recipient properties such as department, manager,
location, and more. For more information, see the Recipient Filter Scopes section.
Configuration scope: Configuration scopes use filters or lists to target specific servers
based on server lists or filterable properties that can be defined on servers, such as an
Active Directory site or a server role. Configuration scopes can also use database scopes
to target specific databases based on database lists or filterable database properties. For
more information, see the Configuration Scopes section.
Simple and broad or complex and granular recipient and configuration custom scopes can be
created by using the New-ManagementScope cmdlet. When you create either a recipient or
configuration scope, only the recipient, server, or database objects that match their respective
scopes are returned. When these scopes are applied to a role assignment using the New-
ManagementRoleAssignment or Set-ManagementRoleAssignment cmdlets, only the
objects that match the scopes can be modified by the role assignees who are assigned the role.
After a custom scope has been created, you can't change the scope type. A recipient scope is
always a recipient scope and a configuration scope is always a configuration scope.
By default, a custom scope enables a role assignee to access a set of objects that match the
scopes you define. However, they don't actively exclude access to other role assignees who
aren't also assigned the same or equivalent scope. Any custom scope can access the same
objects if the lists or filters on those scopes match the same objects. There might be objects
where this behavior isn't wanted, such as in the case of executives. For these objects, you can
define exclusive scopes. Exclusive scopes use filters or lists in the same way as regular scopes
but unlike regular scopes, deny access to objects included in the scope to anyone who isn't part
of the same or equivalent exclusive scope. For more information about exclusive scopes, see
Understanding exclusive scopes.

Recipient filter scopes

Recipient filter scopes enable you to control which recipient objects role assignees can manage
by evaluating one or more properties on a recipient object against a value that you specify in a
filter statement. Recipients included in recipient scopes are mailboxes, mail-enabled users,
distribution groups and mail contacts. Only the recipients that match the filter you specify can
be managed by the role assignees assigned that role assignment. An example of a filter
statement is { Name -Eq "David" } where Name is the property on the recipient object that's
being evaluated and David is the value you want to evaluate against the property. The -Eq
comparison operator indicates that the value stored in the property must be equal to the value
that was specified for the filter to be true. If the filter is true, that recipient is included in scope.
Recipient filter scopes are created by specifying the recipient filter to use with the
RecipientRestrictionFilter parameter on the New-ManagementScope cmdlet. By default, the
New-ManagementScope cmdlet creates regular scopes. If you want to create an exclusive
scope, include the Exclusive switch along with the RecipientRestrictionFilter parameter.
When you create a recipient restriction filter, Exchange evaluates the filter you provided against
every recipient object in the organization by default. If you want to limit which recipients the
scope evaluates, you can use the RecipientRoot parameter along with the
RecipientRestrictionFilter parameter. The RecipientRoot parameter accepts an OU. When you
use the RecipientRoot parameter, Exchange evaluates only the recipients included in the
specified OU against the filter you provided.
When you add a recipient filter scope to a role assignment, specify the name of the recipient
scope in the CustomRecipientWriteScope parameter on the New-
ManagementRoleAssignment if you're creating a new role assignment, or the Set-
ManagementRoleAssignment cmdlet if you're updating an existing role assignment. Each
role assignment can have one recipient scope, including predefined relative scopes. You can
add one configuration scope to the same role assignment you added a recipient scope to.
For more information about filter syntax and for a full list of filterable recipient properties on
recipients, see Understanding management role scope filters.

Configuration scopes
The following are the two types of configuration scopes offered in Exchange 2013:
Server scopes: There are two types of server scopes, server filter scopes and server list
scopes. Server configuration, including Receive connectors, transport queues, server
certificates, virtual directories, and so on, can be managed if a server object is included
in a server scope.
Server filter scopes: Server filter scopes enable you to control which server
objects role assignees can manage by evaluating one or more properties on a
server object against a value that you specify in a filter statement. To create a
server filter scope, use the ServerRestrictionFilter parameter on the New-
ManagementScope cmdlet.
Server list scopes: Server list scopes enable you to control which server objects
role assignees can manage by defining a list of servers that a role assignee can
 access. To create a server list scope, use the ServerList parameter on the New-
ManagementScope cmdlet.
Database scopes: There are two types of database scopes, database filter scopes and
database list scopes. Database configuration that can be managed if a database object is
included in a database scope include database quota limits, database maintenance,
public folder replication, whether a database is mounted, and so on. In addition to
database configuration, database scopes can also be used to control which databases
recipients can be created in. If you have pre-Exchange 2010 SP1 servers in your
organization, see the Database scopes and previous versions of Exchange section later
in this topic.
Database filter scopes: Database filter scopes enable you to control which
database objects role assignees can manage by evaluating one or more
properties on a database object against a value that you specify in a filter
statement. To create a database filter scope, use the DatabaseRestrictionFilter
parameter on the New-ManagementScope cmdlet.
Database list scopes: Database list scopes enable you to control which database
objects role assignees can manage by defining a list of databases that a role
assignee can access. To create a database list scope, use the DatabaseList
parameter on the New-ManagementScope cmdlet.
For more information about filter syntax and for a full list of filterable server and database
properties, see Understanding management role scope filters.
Server and database lists can be defined by specifying each server and database you want to
include in their respective scopes. Multiple servers or databases can be specified in their
respective scopes by separating the server and database names with commas.
When you add a server or database configuration scope to a role assignment, specify the name
of the server or database configuration scope in the CustomConfigWriteScope parameter on
the New-ManagementRoleAssignment cmdlet if you're creating a new role assignment, or
the Set-ManagementRoleAssignment cmdlet if you're updating an existing role assignment.
Each role assignment can only have one configuration scope.
In addition to controlling which databases role assignees can manage, database scopes also
enable you to control which databases role assignees can create mailboxes on. This is separate
from controlling which recipients a role assignee can manage. If a role assignee has
permissions to create a new mailbox, mail-enable an existing user, or move mailboxes, you can
further refine their permissions by using database scopes to control the database on which the
mailbox is created, or which database a mailbox is moved to. Controlling which recipients a
role assignee can manage is done using a recipient scope specified in the
CustomRecipientWriteScope parameter on the New-ManagementRoleAssignment or Set-
ManagementRoleAssignment cmdlet. Controlling which databases a mailbox can be created
on or moved to is controlled using a database scope specified in the
CustomConfigurationWriteScope parameter on the same cmdlets.

NOTE
Automatic mailbox distribution can be controlled using database scopes.

Exchange features may require either server scopes, database scopes, or both, to be managed.
If a feature requires both server and database scopes to be managed, two role assignments
must be created and assigned to the role assignee that should have access to manage the
feature. One role assignment should be associated with the server scope, and one role
assignment should be associated with the database scope.
Some cmdlets may use configuration scopes that aren't immediately obvious. The following
table includes a list of cmdlets and the configuration scopes that you can use to control their
usage. For cmdlets included in the recipients feature area, configuration scopes enable you to
control on which databases recipients can be created. They don't control which recipients can
be managed. The Required scopes column can contain the following:
Database: To run the cmdlet, the role assignee must be assigned a role assignment with
a database scope that includes the database to be managed or the role's implicit
configuration write scope must include the database to be managed.
Server: To run the cmdlet, the role assignee must be assigned a role assignment with a
server scope that includes the server to be managed or the role's implicit configuration
write scope must include the server to be managed.
Server or database: To run the cmdlet, the role assignee must be assigned a role
assignment where either a database scope includes the database being managed, or
where a server scope includes the server where the database is located. Or, the role's
implicit configuration write scope must contain the database to be managed, or contain
the server where the database is located, and the role assignment can't have a custom
write scope.
Server and database: To run this cmdlet, the role assignee must be assigned two role
assignments. The first role assignment must include a database scope that includes the
database to be managed. The second role assignment must include a server scope that
includes the server where the database is located. The role assignments can have
custom configuration scopes defined, or the role assignments can inherit the implicit
configuration write scope from the role. To inherit the implicit write scope from the role,
the role assignment can't have a custom write scope.
Feature areas and applicable database and server scopes
FEATURE AREA CMDLET REQUIRED SCOPES

Databases Dismount-Database Database

Databases Mount-Database Database

Databases Move-DatabasePath Server and database

Databases Remove- Server or database

MailboxDatabase

Databases Set-MailboxDatabase Database

High availability Add- Server

DatabaseAvailabilityGrou
pServer
 FEATURE AREA CMDLET REQUIRED SCOPES

High availability Add- Server

MailboxDatabaseCopy

High availability Move- Server

ActiveMailboxDatabase

High availability Remove- Server

DatabaseAvailabilityGrou
pServer

High availability Remove- Server or database

MailboxDatabaseCopy

High availability Resume- Server or database

MailboxDatabaseCopy

High availability Set- Server or database

MailboxDatabaseCopy

High availability Suspend- Server or database

MailboxDatabaseCopy

High availability Update- Server or database

MailboxDatabaseCopy

Recipients Connect-Mailbox Database

Recipients Enable-Mailbox Database

Recipients New-Mailbox Database

Recipients New-MoveRequest Database

Troubleshooting Test-MapiConnectivity Database

Database scopes and previous versions of Exchange

Database scopes were first introduced in Microsoft Exchange 2010 Service Pack 1 (SP1) and
continue to be supported in Exchange 2013. Versions of Exchange prior to Exchange 2010 SP1
support only recipient scopes and server configuration scopes. When you create a new
database scope on an Exchange 2010 SP1 or later server, you'll receive the following warning:
 WARNING: Database management scopes will only be applied when a user connects to a server
running Exchange 2010 SP1 or later. Servers running a version of Exchange prior to Exchange
2010 SP1 won't apply any roles from a role assignment linked to a database scope. Database
management scopes also won't be visible to the Get-ManagementScope cmdlet when it's run
from a pre-Exchange 2010 SP1 server.

When you create a database scope, it's only applied to users who connect to servers running
Exchange 2010 SP1 or later. Users who connect to pre-Exchange 2010 SP1 servers won't have
any role assignments associated with database scopes applied to them. This means that any
permissions provided by these role assignments won't be granted to users when they connect
to pre-Exchange 2010 SP1 servers. Database scopes can't be created, removed, modified, or
viewed from pre-Exchange 2010 SP1 servers.
A database scope can include any database in your Exchange organization. This includes
Exchange Server 2007, Exchange 2010, and Exchange 2013 servers. This enables you to
control which databases, regardless of Exchange version, that users can manage. As with other
database scopes, role assignments associated with database scopes that contain Exchange
2007 and Exchange 2010 databases are only applied to users when they connect to an
Exchange 2010 SP1 or later server.
Users who connect to a pre-Exchange 2010 SP1 server can view and modify role assignments
associated with database scopes. This includes changing the configuration scope on an existing
role assignment to a server scope if it's currently associated with a database scope. However, if
the configuration scope on a role assignment is changed to a server scope and a user later
wants to change it back to a database scope, or if the user wants to change the configuration
scope to another database scope, the user must make the change while connected to an
Exchange 2010 SP1 or later server. Users can only specify server scopes when they change the
configuration scope on a role assignment if they're connected to a pre-Exchange 2010 SP1
server.
 Understanding management role scope filters
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role scope filters can be used to define management scopes that are highly customizable. Using
scope filters, you can create a scope that matches how you segment your recipients, databases, and servers so
that administrators can manage only those objects they should have access to. Scope filters can use nearly any
recipient, database, or server object property.
To use management role scope filters, you must be familiar with management role scopes. For more information
about management role scopes, see Understanding management role scopes.
Filtered custom scopes in Microsoft Exchange Server 2013 are created by using the New-ManagementScope
cmdlet. The two types of filtered scopes, recipient and configuration (which consists of server and database
scopes), are divided into regular scopes and exclusive scopes. The following list shows which parameter on the
New-ManagementScope cmdlet to use to create each type of filtered scope:
Recipient regular filtered scope: To create this type of filtered scope, use the RecipientRestrictionFilter
parameter.
Recipient exclusive filtered scope: To create this type of filtered scope, use the RecipientRestrictionFilter
parameter along with the Exclusive switch.
Server-based configuration regular filtered scope: To create this type of filtered scope, use the
ServerRestrictionFilter parameter.
Server-based configuration exclusive filtered scope: To create this type of filtered scope, use the
ServerRestrictionFilter parameter along with the Exclusive switch.
Database-based configuration regular filtered scope: To create this type of filtered scope, use the
DatabaseRestrictionFilter parameter.
Database-based configuration exclusive filtered scope: To create this type of filtered scope, use the
DatabaseRestrictionFilter parameter along with the Exclusive switch.
When you create a filtered custom scope, the scope attempts to match the filter with any objects accessible within
the implicit read scope of the management role. If an object is found, it's included in the results returned by the
filter, and the object is made available to the management role by the custom scope. A filter can't return results
that are outside of the implicit read scope of the management role.
If you specify a recipient filter using the RecipientRestrictionFilter parameter, you can use the RecipientRoot
parameter to specify an organizational unit (OU ) to restrict the filter to. When you specify an OU in the
RecipientRoot parameter, the recipient filter attempts to match recipients that reside in that OU only, rather than
within the entire implicit read scope.
To create a management scope using the filterable properties included in this topic, see Create a regular or
exclusive scope.

Filter syntax
Both recipient and configuration filters use the same syntax to create a filter query. All filter queries must have, at
minimum, the following components:
 Opening bracket: The opening brace ({) indicates the start of the filter query.
Property to examine: The property is the value on an object that you want to test. For example, this can
be the city or department on a recipient object, an Active Directory site name or server name on a server
configuration object, or a database name on a database configuration object.
Comparison operator: The comparison operator directs how the query should evaluate the value that
you specify against the value that's stored in the property. For example, comparison operators can be Eq,
which means equal to; Ne, which means not equal to; Like, which means similar to, and so on. For a full
list of operators that you can use in the Exchange Management Shell, see Comparison operators.
Value to compare: The value you specify in the filter query will be compared to the value that's stored in
the property you specified. The value you specify must be enclosed in quotation marks ("). If you want to
specify a partial string, you can enclose the string you provide in wildcard characters (*) and use a
comparison operator that supports wildcard characters, such as Like. Any string that contains the partial
string will match the filter query.
Closing bracket: The closing brace (}) indicates the end of the filter query.
The following components are optional and enable you to create more complex filter queries:
Parentheses: As in mathematics, parentheses, ( ), in a filter query enable you to force the order in which
an operation occurs. Innermost parentheses are evaluated first and the filter query works outward to the
outermost parentheses.
Logical operators: Logical operators tie together one or more comparison operations and require the
filter query to evaluate the entire statement. For example, logical operators include And, Or, and Not.
When put together, a simple query looks like { City -Eq "Vancouver" } . This filter matches any recipient where
the value in the property City equals the string "Vancouver".
Another, more complex, query is
{ ((City -Eq "Vancouver") -And (Department -Eq "Sales")) -Or (Title -Like "*Manager*") } . The filter query is
evaluated in the following order:
1. The properties City and Department are evaluated. Each is set to either True or False , depending on
the values stored in each property.
2. The results of the City and Department statements are then evaluated. If both are True , the entire And
statement becomes True . If one or both are False , the entire And statement becomes False . The
following applies:
If the And statement evaluates as True , the entire filter query becomes True because the Or
operator indicates that one side of the query, or the other, must be True . The object is exposed to
the role assignment.
If the And statement is False , the filter query continues on to evaluate the Title property.
3. The Title property is then evaluated. It's set to True or False , depending on the value that's stored in the
Title property. The following applies:
If the Title property evaluates as True , the entire filter query becomes True because the Or
operator indicates that one side of the query, or the other, must be True . The object is exposed to
the role assignment.
If the Title property evaluates as False , the entire filter query evaluates as False , and the object
isn't exposed to the role assignment.
The following table shows an example with values, which indicates when the complex query would evaluate as
True , and when it would evaluate as False .
Complex query
CITY DEPARTMENT TITLE RESULT

Vancouver (True) Sales (True) CEO (False) True because both City
and Department
evaluated as True. Title
isn't evaluated because
the filter query
conditions are already
satisfied.

Seattle (False) Sales (True) IT Manager (True) True because Title

evaluated as True. The
results of the City and
Department
comparison are
discarded because Title
evaluated as True, which
satisfied the filter query
conditions.

NOTE
IT Manager matches
the filter query
because the Like
comparison
operator was used,
which matches
partial strings when
wildcard characters
(*) are used in the
filter query.

Vancouver (True) Marketing (False) Writer (False) False because City and
Department didn't
both evaluate as True,
and Title also didn't
evaluate as True.

Filterable recipient properties

You can use almost any property on a recipient object when you create a recipient filter. For a list of filterable
recipient properties, see Filterable properties for the -RecipientFilter parameter. Although this topic discusses the
properties that can be used with the RecipientFilter parameter on other cmdlets, most of these properties also
work with the RecipientRestrictionFilter parameter on the New-ManagementScope cmdlet.

Filterable server properties

You can use the following server properties when you create a management scope with the
ServerRestrictionFilter parameter:
CurrentServerRole
 CustomerFeedbackEnabled
DataPath
DistinguishedName
ExchangeLegacyDN
ExchangeLegacyServerRole
ExchangeVersion
Fqdn
Guid
InternetWebProxy
Name
NetworkAddress
ObjectCategory
ObjectClass
ProductID
ServerRole
ServerSite
WhenChanged
WhenChangedUTC
WhenCreated
WhenCreatedUTC

Filterable database properties

You can use the following database properties when you create a management scope with the
DatabaseRestrictionFilter parameter:
AdminDisplayName
AllowFileRestore
BackgroundDatabaseMaintenance
CircularLoggingEnabled
DatabaseCreated
DeletedItemRetention
Description
DistinguishedName
EdbFilePath
EventHistoryRetentionPeriod
ExchangeLegacyDN
ExchangeVersion
Guid
IssueWarningQuota
LogFilePrefix
LogFileSize
LogFolderPath
MasterServerOrAvailabilityGroup
MountAtStartup
Name
ObjectCategory
ObjectClass
RetainDeletedItemsUntilBackup
Server
WhenChanged
WhenChangedUTC
WhenCreated
WhenCreatedUTC
 Understanding exclusive scopes
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Exclusive scopes are a special type of explicit management scope that can be associated with management role
assignments. Exclusive scopes are designed to enable situations where you have a group of highly valuable
objects, such as a CEO mailbox, and you want to tightly control who has access to manage those objects.
A role assignment that has an exclusive scope is called an exclusive role assignment.
When you create an exclusive scope, only those who are assigned that exclusive scope, or an equivalent exclusive
scope, can modify the objects that match the scope. Role assignees who aren't assigned that exclusive scope, or an
equivalent, can't modify the objects that match the scope, even if their own roles have scopes that would otherwise
include the objects. Exclusive scopes override any other regular scope that isn't exclusive. This behavior is similar
to how a deny access control entry (ACE ) on an Active Directory access control list (ACL ) functions.
An equivalent exclusive scope refers to another exclusive scope that matches some of the same objects as another
exclusive scope. The scopes don't have to match the same complete set of objects. Both scopes may be able to
modify some, or all, of the objects that match them.

Creating exclusive scopes

Exclusive scopes can be created like any other explicit scope. You can specify a prebuilt relative scope; a recipient,
database, or server filter; or a database or server list. Unlike regular scopes, which don't take effect until you
associate a scope to a management role assignment, the deny aspect of an exclusive scope takes effect
immediately. This means that as soon as an exclusive scope is created, the objects contained within that scope are
immediately no longer accessible by any user until the role assignment has been created.
After the assignment has been created, the exclusive scope provides access to those assigned the management
role and scope. If another equivalent exclusive scope matches the same objects, the role assignment associated
with that exclusive scope is still able to access the objects.
For more information about management scope filters, see Understanding management role scope filters.

IMPORTANT
Active Directory replication times should be taken into account when making changes to any management role components,
including exclusive scopes.

If you have objects contained within more than one exclusive scope, being assigned to any one of the exclusive
scopes provides access to the objects. For more information, see Exclusive and regular scope interaction later in
this topic.
Exclusive scopes control only the explicit recipient or configuration write scope of a role assignment. The implicit
recipient or configuration read scope of the role assigned to a user or group still applies. This means that the
following applies:
Those assigned a role continue to see objects that match the role's implicit read scope.
Those assigned other roles may be able to see objects contained within an exclusive scope, if the read
scopes of the other roles include the objects. However, the objects can only be modified by those who are
 assigned a role associated with the exclusive scope.
Exclusive scopes can only be used with administrative or specialist roles and can't be used with end-user roles. For
more information about roles, see Understanding management roles.

Exclusive and regular scope interaction

The figure at the end of this section illustrates how exclusive scopes interact with each other, and with regular
scopes. The users in the figure all have the following attributes associated with them.

USER CITY TITLE DEPARTMENT

Terry Vancouver Accountant Accounting

David Vancouver Writer Marketing

Walter Vancouver Manager Marketing

Bob Vancouver CEO Board

Christine Vancouver President Board

Fred Vancouver CFO Executives

Martin Vancouver CIO Executives

Kim Vancouver Vice President, Executives

Operations

Jennifer Vancouver Vice President, Executives

Technology

The following three management role assignments in the figure manage the users in the preceding table. Each has
an associated scope, some of which are exclusive scopes.

ROLE ASSIGNMENT SCOPE FILTER EXCLUSIVE OR REGULAR

Recipient Administrators City = Vancouver Regular

VIP Administrators Title = CEO or CFO or CIO or Exclusive

President

Executive Administrators Department = Executives Exclusive

The Recipient Administrators role assignment has a scope that matches all of the users because every user is
located in Vancouver. Without any exclusive scopes, this would mean that the Recipient Administrators role
assignment could manage any of the users. However, this organization has created two exclusive scopes: VIP
Administrators and Executive Administrators. These exclusive scopes restrict who can manage the users that
match their respective scope filters. The VIP Administrators role assignment has a scope filter that matches any
user who has a title of CEO, CFO, CIO, or President. The Executive Administrators role assignment has a scope
filter that matches any user who is in the Executives department.
When the regular and exclusive scopes are evaluated, the following is the result:
The Recipient Administrators role assignment can manage the users Terry, David, and Walter. This role
assignment can't manage any of the other users because they match the exclusive scope filters of the VIP
Administrators and Executive Administrators role assignments.
The VIP Administrators role assignment can manage the users Bob, Christine, Fred, and Martin. This is
because the exclusive scope filter associated with this role assignment matches the attributes on these
objects. This role assignment can't manage the users Kim and Jennifer because their attributes don't match
this exclusive scope.
The Executive Administrators role assignment can manage the users Kim, Jennifer, Fred, and Martin. This is
because the exclusive scope filter associated with this role assignment matches the attributes on these
objects. This role assignment can't manage the users Bob and Christine because their attributes don't match
this exclusive scope.
Notice that Fred and Martin are accessible by both exclusive scopes. This is because the attributes on these users
match the filters of both exclusive scopes.
Interaction between exclusive scopes and regular scopes

For more information about management scopes, see Understanding management role scopes.
 Understanding management role
assignments
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

A management role assignment, which is part of the Role Based Access Control
(RBAC ) permissions model in Microsoft Exchange Server 2013, is the link between
a management role and a role assignee. A role assignee is a role group, role
assignment policy, user, or universal security group (USG ). A role must be assigned
to a role assignee for it to take effect. For more information about RBAC, see
Understanding Role Based Access Control.

NOTE
This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange
2013 permissions, such as using the Exchange admin center (EAC) to add and remove
members to and from role groups, create and modify role groups, or create and modify
role assignment policies, see Permissions.

This topic discusses the assignment of roles to role groups and role assignment
policies and direct role assignment to users and USGs. It doesn't talk about
assignment of role groups or role assignment policies to users. For more
information about role groups and role assignment policies, which are the
recommended way to assign permissions to users, see the following topics:
Understanding management role groups
Understanding management role assignment policies
You can create the following types of role assignments, which are explained in detail
later in this topic:
Regular and delegating role assignments
Exclusive role assignments

Managing role assignments

When you change role assignments, the changes you make will probably be
between role groups and role assignment policies. By adding, removing, or
modifying role assignments to or from these role assignees, you can control what
permissions are given to your administrators and users, in effect turning on and off
management of related features.
You might also want to assign roles directly to users or USGs. This is a more
advanced task that enables you to define at a granular level what permissions your
users are given. Although this provides you with flexibility, it also increases the
complexity of your permissions model. For example, if the user changes jobs, you
might need to manually reassign the roles assigned to that user to another user.
This is why we recommend that you use role groups and role assignment policies
to give permissions to your users. You can assign the roles to a role group or role
assignment policy, and then just add or remove members of the role group, or
change role assignment policies as needed.
You can add, remove, and enable role assignments, modify the management scope
on an existing role assignment, and move role assignments to other role assignees.
The process of assigning roles to role groups, role assignment policies, users, and
USGs is largely the same for each role assignee. The following are the only
exceptions:
Role assignment policies can only be assigned end-user management roles.
Role assignment policies can't be assigned delegating role assignments.
You can't specify a management scope when creating a role assignment to
role assignment policies.
For more information about managing role assignments, see the following topics:
Role groups:
Manage role groups
Role assignment policies:
Manage role assignment policies
Change a role assignment
Users and USGs:
Add a role to a user or USG
Remove a role from a user or USG
Change a role assignment
Change a role scope
Delegate role assignments

Regular and delegating role assignments

Regular role assignments enable the role assignee to access the management role
entries made available by the associated management role. If multiple management
roles are assigned to a role assignee, the management role entries from each
management role are aggregated and applied. This means that if a role assignee is
assigned the Transport Rules and Journaling roles, the roles are combined, and all
the associated management role entries are given to the role assignee. If the role
assignee is a role group or role assignment policy, the permissions provided by the
roles are then given to the users assigned to the role group or role assignment
policy. For more information about management roles and role entries, see
Understanding management roles.
Delegating role assignments doesn't give access to manage features. Delegating
role assignments gives a role assignee the ability to assign the specified role to
other role assignees. If the role assignee is a role group, any member of the role
group can assign the role to another role assignee. By default, only the
Organization Management role group has the ability to assign roles to other role
assignees. Only the user that installed Exchange 2013 is a member of the
Organization Management role group by default. You can, however, add other users
to this role group as needed, or create other role groups and assign delegating role
assignments to those groups.

NOTE
Delegating role assignments enables role assignees to delegate management roles to
other role assignees. This doesn't enable users to delegate role groups. For more
information about role group delegation, see Understanding management role groups.

If you want a user to be able to manage a feature and assign the role that gives
permissions to use the feature to other users, assign the following:
1. A regular role assignment for each management role that grants access to
the features that need to be managed.
2. A delegating role assignment for each management role that you allow to be
assigned to other role assignees.
The regular and delegating role assignments for a role assignee don't need to be
identical. For example, a user is a member of a role group assigned the Transport
Rules role using a regular role assignment. This enables the user to manage the
Transport Rules feature. However the user isn't assigned a delegating role
assignment for the Transport Rules role so the user can't assign this role to other
users. However, the user is a member of a role group assigned the Journaling
management role using a delegating role assignment. The role group the user is a
member of doesn't have a regular role assignment for the Journaling role but
because it has a delegating role assignment, the user can assign the role to other
role assignees.

Management scopes
When you create either a regular or delegating management role assignment, you
have the option of creating the assignment with a management scope to limit the
objects that the user can manipulate. You can create recipient scopes or
configuration scopes. Recipient scopes enable you to control who can manipulate
mailboxes, mail users, distribution groups, and so on. Configuration scopes enable
you to control who can manipulate servers and databases.
Recipient and configuration scopes enable you to segment the management of
server, database or recipient objects in your organization. For example, a recipient
scope can be added to a role assignment so that administrators in Vancouver can
only manage recipients in the same office. A server configuration scope could be
added to a different role assignment so that administrators in Sydney can only
manage servers in their Active Directory site.
Scopes enable permissions to be assigned to groups of users and enable you to
direct where those administrators can perform their administration. This enables
you to create a permissions model that maps to your geographic or organizational
boundaries.
You can create an assignment with a predefined scope, or you can add a custom
scope to the assignment. Predefined scopes, such as limiting a user to only his or
her mailbox or distribution groups, can be applied using options available on the
assignment itself. Alternatively, you can create a custom recipient or configuration
scope, and then add that scope to the role assignment. Custom scopes give you
more granularity over which objects are included in the scope.
You can't specify predefined and custom scopes on the same assignment. You also
can't mix exclusive and regular scopes on the same assignment.
Each role assignment can only have one recipient scope and one configuration
scope. If you want to apply more than one recipient scope, or one configuration
scope, to a role assignee for the same management role, you must create multiple
role assignments.
With neither a custom or predefined scope, role assignments are limited to the
recipient and configuration scopes that are defined on the role itself. These scopes
are called implicit scopes. Any role assignment that doesn't have a predefined or
custom scope inherits the implicit scopes from the role it's associated with.
For more information about scopes, see Understanding management role scopes.

Exclusive role assignments

Exclusive role assignments are created when you associate an exclusive scope with
a role assignment. Exclusive scopes work like regular scopes and enable role
assignees to manage recipients that match the exclusive scope. However, unlike
regular scopes, all other role assignees are denied the ability to manage the
recipient, even if the recipient matches scopes applied to their role assignments.
This can be useful when you want to limit who can manage a recipient to a few
administrators. Only those specific administrators can manage the recipient, and all
other administrators are denied access.
For example, consider the following:
John is an executive at Contoso. His mailbox matches an exclusive scope
called VIP Users, which is associated with the VIP Restricted exclusive
assignment.
John's mailbox is also included in a regular scope called Redmond Users,
which is associated with the Redmond Administration regular assignment.
Bill is an administrator who is associated with the VIP Restricted exclusive
assignment.
Chris is an administrator who is associated with the Redmond
Administration regular assignment.
Because John's mailbox matches the VIP Users exclusive scope, only Bill can
manage his mailbox. Even though John's mailbox also matches the Redmond Users
regular scope, Chris isn't associated with the VIP Restricted exclusive assignment.
Therefore, Exchange denies Chris the ability to manage John's mailbox. For Chris to
manage John's mailbox, Chris needs to be assigned an exclusive assignment that
has an exclusive scope that matches John's mailbox.
For more information, see Understanding exclusive scopes.
 Built-in role groups
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 includes several management role groups by default. The following built-in role
groups provide you with a preconfigured set of roles that you can assign to various administrator and specialist
users in your organization.

NOTE
Role groups don't control access to end-user mailbox features. To control access to end-user mailbox features, see
Understanding management role assignment policies.

Organization Management
View -only Organization Management
Recipient Management
UM Management
Help Desk
Hygiene Management
Compliance Management
Records Management
Discovery Management
Public Folder Management
Server Management
Delegated Setup
For more information about role groups, see Understanding management role groups.
 Organization Management
5/28/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Organization Management management role group is one of several built-in
role groups that make up the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Role groups are assigned one or more
management roles that contain the permissions required to perform a given set of
tasks. The members of a role group are granted access to the management roles
assigned to the role group. For more information about role groups, see
Understanding management role groups.
Administrators that are members of the Organization Management role group
have administrative access to the entire Exchange 2013 organization and can
perform almost any task against any Exchange 2013 object, with some exceptions.
By default, members of this role group can't perform mailbox searches and
management of unscoped top-level management roles. For more information, see
the "Delegating Only Role Assignments" section later in this topic.

IMPORTANT
The Organization Management role group is a very powerful role and as such, only
users or universal security groups (USGs) that perform organizational-level
administrative tasks that can potentially impact the entire Exchange organization should
be members of this role group.

This role group is equivalent to the Exchange Organization Administrators role in

Exchange Server 2007.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

By default, the account that's used to install Exchange 2013 in the organization is
added as a member of the Organization Management role group. This account
can then add other members to the role group as needed.
If you want to add or remove members to or from this role group, see Manage
role group members.
By default, only members of the Organization Management role group can add or
remove members from this role group. For more information about how to add
additional role group delegates, see the "Add or remove a role group delegate"
section in Manage role groups.
You can use the following command to view a list of users or USGs that are
members of this role group.

Get-RoleGroupMember "Organization Management"

For more information about the members of a role group, see Manage role
groups.
Role group customization
This role group is assigned management roles by default. The roles that are
included are listed in the "Management Roles Assigned to this Role Group"
section. You can add or remove role assignments to or from this role group to
match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more
granular tasks. By assigning roles to a role group, you enable the members of that
role group to perform the tasks associated with the role. For example, the
Journaling role enables the management of the Journaling agent and journaling
rules. For more information about how roles are assigned to role groups, see
Understanding management role assignments.
The roles assigned to this role group are given default management scopes.
Management scopes determine what Exchange objects can be viewed or modified
by the members of a role group. You can change the scopes associated with
assignments between roles and role groups. For example, you might want to do
this if you only want members of a role group to be able to change recipients that
are under a specific organizational unit or in a specific location. For more
information about management scopes, see Understanding management role
scopes.
For more information about how to customize this role group, see the following
topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned
to this role group to the new role group, see the "Create a role group" section in
Manage role groups.
The following are some ways you might want to customize this role:
Permissions owner: If the permissions in your organization are controlled
by a specific group other than the Exchange administrators, you can create
a role group and move the regular and delegating role assignments for the
Role Management role to the new role group. Doing so prevents members
of the Organization Management role group from managing any RBAC
permissions.
Active Directory split permissions: If the creation of security principals
in your organization, such as user accounts, is controlled by a specific group
other than the Exchange administrators, you can create a role group and
move the regular and delegating role assignments for the Mail Recipient
Creation role and the Security Group Creation and Membership role to the
new role group. Doing so prevents members of the Organization
Management role group from creating Active Directory objects. They can,
however, continue to mail-enable the new Active Directory objects. For
more information about split permissions, see Understanding split
permissions.

Customization limitations
Any role can be added to or removed from this role group, with the following
limitations:
 Every role must have at least one delegating role assignment to a role
group or USG before the delegating role assignment can be removed from
this role group.
The Role Management role must have at least one regular role assignment
to a role group or USG before the regular role assignment can be removed
from this role group.
These limitations are intended to help prevent you from inadvertently locking
yourself out of the system. By requiring that at least one delegating role
assignment exists between every role and one or more role groups or USGs, you
will always be able to assign roles to role assignees. By requiring that at least one
regular role assignment exists between the Role Management role and one or
more role groups or USGs, you will always be able to configure role groups and
role assignments.

IMPORTANT
These limitations require that role groups or USGs be the targets of the delegating and
regular role assignments. You can't remove a delegating role assignment or the regular
assignment for the Role Management role if the last assignment is to a user.

Delegating only role assignments

Some role assignments between the Organization Management role group and
management roles, such as Mailbox Search and Unscoped Role Management, are
delegating only role assignments. These roles allow access to sensitive or personal
information, such as the contents of mailboxes, or enable the creation of powerful
unscoped management roles.
Delegating only role assignments enable members of the Organization
Management role group only to assign the associated roles to other role groups,
management role assignment policies, users, or USGs. Members of the
Organization Management role group aren't given, by default, any permissions
that the roles provide. This helps avoid accidental exposure to personal
information or accidental elevation of privileges.
Members of the Organization Management role group can, however, assign
themselves any role, in effect enabling them to perform any task. For example, a
member of the Organization Management role group can assign the Mailbox
Search role to the Organization Management role group. After this role
assignment is made, members of the Organization Management role group can
perform tasks enabled by the Mailbox Search role.
For more information about delegating role assignments, see Understanding
management role assignments.

Additional permissions
The permissions granted to members of the Organization Management role
group are primarily determined by the management roles assigned to the role
group. However, not all tasks that you need to perform are covered by
management roles. Some tasks occur outside of the Exchange management tools,
and therefore the RBAC permissions model doesn't apply. For these tasks,
permissions are provided by adding the Organization Management role group to
the access control lists (ACLs) of certain Active Directory objects.
The following tasks are granted permissions by way of ACLs on Active Directory
objects and not by management roles assigned to the Organization Management
role group:
Running DomainPrep and ForestPrep using Setup.exe
Deploying additional servers in the organization

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role
group and the following attributes of each role assignment:
Regular assignment: Enables members of the role group to access the
management role entries made available by the associated management
role.
Delegating assignment: Gives members of the role group the ability to
assign the specified role to other role groups, role assignment policies,
users, or USGs.
Recipient read scope: Determines what recipient objects members of the
role group are allowed to read from Active Directory.
Recipient write scope: Determines what recipient objects members of the
role group are allowed to modify in Active Directory.
Configuration read scope: Determines what configuration and server
objects members of the role group are allowed to read from Active
Directory.
Configuration write scope: Determines what organizational and server
objects members of the role group are allowed to modify in Active
Directory.
For more information about role assignments and management scopes, see the
following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Activ X X Organization Organization OrganizationConfig

OrganizationConfig
e
Direc
tory
Perm
issio
ns
role

Addr X X Organization Organization OrganizationConfig

OrganizationConfig
ess
Lists
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Appli X Organization Organization None None

catio
nImp
erso
natio
n
role

Archi X X Organization Organization OrganizationConfig

OrganizationConfig
veAp
plicat
ion
role

Audit X X Organization Organization OrganizationConfig

OrganizationConfig
Logs
role

Cmdl X X Organization Organization OrganizationConfig

OrganizationConfig
et
Exten
sion
Agen
ts
role

Data X X Organization Organization OrganizationConfig

OrganizationConfig
Loss
Prev
entio
n
role

Data X X Organization Organization OrganizationConfig

OrganizationConfig
base
Avail
abilit
y
Grou
ps
role

Data X X Organization Organization OrganizationConfig

OrganizationConfig
base
Copi
es
role

Data X X Organization Organization OrganizationConfig

OrganizationConfig
base
s role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Disas X X Organization Organization OrganizationConfig

OrganizationConfig
ter
Reco
very
role

Distri X X Organization Organization OrganizationConfig

OrganizationConfig
butio
n
Grou
ps
role

Edge X X Organization Organization OrganizationConfig

OrganizationConfig
Subs
cripti
ons
role

E- X X Organization Organization OrganizationConfig

OrganizationConfig
Mail
Addr
ess
Polici
es
role

Exch X X Organization Organization OrganizationConfig

OrganizationConfig
ange
Conn
ector
s role

Exch X X Organization Organization OrganizationConfig

OrganizationConfig
ange
Serve
r
Certif
icate
s role

Exch X X Organization Organization OrganizationConfig

OrganizationConfig
ange
Serve
rs
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Exch X X Organization Organization OrganizationConfig

OrganizationConfig
ange
Virtu
al
Direc
torie
s role

Fede X X Organization Organization OrganizationConfig

OrganizationConfig
rated
Shari
ng
role

Infor X X Organization Organization OrganizationConfig

OrganizationConfig
mati
on
Right
s
Man
age
ment
role

Jour X X Organization Organization OrganizationConfig

OrganizationConfig
nalin
g
role

Legal X X Organization Organization OrganizationConfig

None
Hold
role

Legal X Organization Organization OrganizationConfig

OrganizationConfig
Hold
Appli
catio
n
role

Mail X X Organization Organization OrganizationConfig

OrganizationConfig
Enabl
ed
Publi
c
Folde
rs
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Mail X X Organization Organization OrganizationConfig

OrganizationConfig
Recip
ient
Creat
ion
role

Mail X X Organization Organization OrganizationConfig

OrganizationConfig
Recip
ients
role

Mail X X Organization Organization OrganizationConfig

OrganizationConfig
Tips
role

Mail X Organization Organization OrganizationConfig

OrganizationConfig
box
Impo
rt
Expo
rt
role

Mail X Organization Organization None None

box
Searc
h
role

Mail X Organization Organization OrganizationConfig

OrganizationConfig
boxS
earch
Appli
catio
n
role

Mess X X Organization Organization OrganizationConfig

OrganizationConfig
age
Track
ing
role

Migr X X Organization Organization OrganizationConfig

OrganizationConfig
ation
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Moni X X Organization Organization OrganizationConfig

OrganizationConfig
torin
g
role

Mov X X Organization Organization OrganizationConfig

OrganizationConfig
e
Mail
boxe
s role

Offic X Self Self OrganizationConfig

OrganizationConfig
eExte
nsion
Appli
catio
n
role

Orga X X Organization Organization OrganizationConfig

OrganizationConfig
nizati
on
Clien
t
Acce
ss
role

Orga X X Organization Organization OrganizationConfig

OrganizationConfig
nizati
on
Confi
gurat
ion
role

Orga X X Organization Organization OrganizationConfig

OrganizationConfig
nizati
on
Trans
port
Setti
ngs
role

POP X X Organization Organization OrganizationConfig

OrganizationConfig
3
and
IMA
P4
Prot
ocols
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Publi X X Organization Organization OrganizationConfig

OrganizationConfig
c
Folde
rs
role

Recei X X Organization Organization OrganizationConfig

OrganizationConfig
ve
Conn
ector
s role

Recip X X Organization Organization OrganizationConfig

OrganizationConfig
ient
Polici
es
role

Rem X X Organization Organization OrganizationConfig

OrganizationConfig
ote
and
Acce
pted
Dom
ains
role

Reset X Organization Organization OrganizationConfig

OrganizationConfig
Pass
word
role

Rete X X Organization Organization OrganizationConfig

OrganizationConfig
ntion
Man
age
ment
role

Role X X Organization Organization OrganizationConfig

OrganizationConfig
Man
age
ment
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Secur X X Organization Organization OrganizationConfig

OrganizationConfig
ity
Grou
p
Creat
ion
and
Mem
bers
hip
role

Send X X Organization Organization OrganizationConfig

OrganizationConfig
Conn
ector
s role

Supp X Organization Organization OrganizationConfig

OrganizationConfig
ort
Diag
nosti
cs
role

Team X Self Self OrganizationConfig

OrganizationConfig
Mail
boxLi
fecycl
eApp
licati
on
role

Trans X X Organization Organization OrganizationConfig

OrganizationConfig
port
Agen
ts
role

Trans X X Organization Organization OrganizationConfig

OrganizationConfig
port
Hygi
ene
role

Trans X X Organization Organization OrganizationConfig

OrganizationConfig
port
Que
ues
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

Trans X X Organization Organization OrganizationConfig

OrganizationConfig
port
Rules
role

UM X X Organization Organization OrganizationConfig

OrganizationConfig
Mail
boxe
s role

UM X X Organization Organization OrganizationConfig

OrganizationConfig
Prom
pts
role

Unsc X Organization Organization OrganizationConfig

OrganizationConfig
oped
Role
Man
age
ment
role

Unifi X X Organization Organization OrganizationConfig

OrganizationConfig
ed
Mess
agin
g
role

User X Organization Organization OrganizationConfig

OrganizationConfig
Appli
catio
n
role

User X X Organization Organization OrganizationConfig

OrganizationConfig
Opti
ons
role

View X X Organization None OrganizationConfig

None
-
Only
Audit
Logs
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

View X X Organization None OrganizationConfig

None
-
Only
Confi
gurat
ion
role

View X X Organization None OrganizationConfig

None
-
Only
Recip
ients
role

Work X X Organization Organization OrganizationConfig

OrganizationConfig
load
Man
age
ment
role

My X Self Self OrganizationConfig

OrganizationConfig
Cust
om
Apps
role

My X Self Self OrganizationConfig

OrganizationConfig
Mark
etpla
ce
Apps
role

MyB X Self Self OrganizationConfig

OrganizationConfig
aseO
ption
s role

MyC X Self Self OrganizationConfig

OrganizationConfig
onta
ctInf
orma
tion
role

MyDi X Self Self OrganizationConfig

OrganizationConfig
agno
stics
role
 DELEGATI CONFIGU CONFIGU
MANAGE REGULAR NG RECIPIEN RECIPIEN RATION RATION
MENT ASSIGNM ASSIGNM T READ T WRITE READ WRITE
ROLE ENT ENT SCOPE SCOPE SCOPE SCOPE

MyDi X MyGAL MyGAL None None

strib
ution
Grou
pMe
mber
ship
role

MyDi X MyGAL MyDistributionGroups

OrganizationConfig
None
strib
ution
Grou
ps
role

MyPr X Self Self OrganizationConfig

OrganizationConfig
ofileI
nfor
mati
on
role

MyR X Self Self OrganizationConfig

OrganizationConfig
etent
ionP
olicie
s role

MyTe X Organization Organization OrganizationConfig

OrganizationConfig
amM
ailbo
xes
role

MyTe X Self Self OrganizationConfig

OrganizationConfig
xtMe
ssagi
ng
role

MyV X Self Self OrganizationConfig

OrganizationConfig
oice
Mail
role
 View-only Organization Management
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The View -Only Organization Management management role group is one of several built-in role groups
that make up the Role Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013.
Role groups are assigned one or more management roles that contain the permissions required to perform
a given set of tasks. The members of a role group are granted access to the management roles assigned to
the role group. For more information about role groups, see Understanding management role groups.
Administrators who are members of the View -Only Organization Management role group can view the
properties of any object in the Exchange organization.
This role is equivalent to the Exchange View -Only Administrators role in Microsoft Exchange Server 2007.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from
this role group. For more information about how to add additional role group delegates, see the "Add or
remove a role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are
members of this role group.

Get-RoleGroupMember "View-Only Organization Management"

For more information about the members of a role group, see View the members of a role group in Manage
role group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or
from this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning
roles to a role group, you enable the members of that role group to perform the tasks associated with the
role. For example, the Journaling role enables the management of the Journaling agent and journaling rules.
For more information about how roles are assigned to role groups, see Understanding management role
assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine
what Exchange objects can be viewed or modified by the members of a role group. You can change the
scopes associated with assignments between roles and role groups. For example, you might want to do this
if you only want members of a role group to be able to change recipients that are under a specific
organizational unit or in a specific location. For more information about management scopes, see
Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the
new role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries
made available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to
other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to
read from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the
role group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMEN REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
T ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Monitori X Organization Organization OrganizationConfig

OrganizationConfig
ng role

View- X Organization None OrganizationConfig

None
Only
Configur
ation role

View- X Organization None OrganizationConfig

None
Only
Recipient
s role
 Recipient Management
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Recipient Management management role group is one of several built-in role groups that make up
the Role Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role
groups are assigned one or more management roles that contain the permissions required to perform a
given set of tasks. The members of a role group are granted access to the management roles assigned to
the role group. For more information about role groups, see Understanding management role groups.
Administrators who are members of the Recipient Management role group have administrative access to
create or modify Exchange 2013 recipients within the Exchange 2013 organization.
This role group is equivalent to the Exchange Recipient Administrators role in Exchange Server 2007.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from
this role group. For more information about how to add additional role group delegates, see the "Add or
remove a role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are
members of this role group.

Get-RoleGroupMember "Recipient Management"

For more information about the members of a role group, see View the members of a role group in
Manage role group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or
from this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning
roles to a role group, you enable the members of that role group to perform the tasks associated with the
role. For example, the Journaling role enables the management of the Journaling agent and journaling
rules. For more information about how roles are assigned to role groups, see Understanding management
role assignments.
The roles assigned to this role group are given default management scopes. Management scopes
determine what Exchange objects can be viewed or modified by the members of a role group. You can
change the scopes associated with assignments between roles and role groups. For example, you might
want to do this if you only want members of a role group to be able to change recipients that are under a
specific organizational unit or in a specific location. For more information about management scopes, see
Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the
new role group, see the "Create a role group" section in Manage role groups.
If the creation of security principals in your organization, such as user accounts, is controlled by a specific
group other than the Exchange administrators, you can create a role group and move the Mail Recipient
Creation role and the Security Group Creation and Membership role to the new role group. Doing so
prevents members of the Recipient Management role group from creating Active Directory objects. They
can, however, continue to mail-enable the new Active Directory objects. For more information about split
permissions, see Understanding split permissions.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries
made available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role
to other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed
to read from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed
to modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the
role group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the
role group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMEN REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
T ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Distributi X Organization Organization OrganizationConfig

OrganizationConfig
on
Groups
role
 CONFIGURATI CONFIGURATI
MANAGEMEN REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
T ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Mail X Organization Organization OrganizationConfig

OrganizationConfig
Recipient
Creation
role

Mail X Organization Organization OrganizationConfig

OrganizationConfig
Recipient
s role

Message X Organization Organization OrganizationConfig

OrganizationConfig
Tracking
role

Migratio X Organization Organization OrganizationConfig

OrganizationConfig
n role

Move X Organization Organization OrganizationConfig

OrganizationConfig
Mailboxe
s role

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Policies
role

Team X Organization Organization OrganizationConfig

OrganizationConfig
Mailboxe
s role
 UM Management
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The UM Management management role group is one of several built-in role groups that make up the Role
Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are assigned
one or more management roles that contain the permissions required to perform a given set of tasks. The
members of a role group are granted access to the management roles assigned to the role group. For more
information about role groups, see Understanding management role groups.
Administrators who are members of the UM Management role group can manage features in the Exchange
organization such as Unified Messaging (UM ) service configuration, UM properties on mailboxes, UM prompts,
and UM auto attendant configuration.
For more information about Unified Messaging, see Unified Messaging.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are
members of this role group.

Get-RoleGroupMember "UM Management"

For more information about the members of a role group, see the "View the members of a role group" section in
Manage role group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to
a role group, you enable the members of that role group to perform the tasks associated with the role. For
example, the Journaling role enables the management of the Journaling agent and journaling rules. For more
information about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine
what Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in a
specific location. For more information about management scopes, see Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to
other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

UM X Organization Organization OrganizationConfig

OrganizationConfig
Mailboxes
role

UM X Organization Organization OrganizationConfig

OrganizationConfig
Prompts
role

Unified X Organization Organization OrganizationConfig

OrganizationConfig
Messagin
g role
 Help Desk
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Help Desk management role group is one of several built-in role groups that make up the Role Based
Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are assigned one or
more management roles that contain the permissions required to perform a given set of tasks. The members of
a role group are granted access to the management roles assigned to the role group. For more information
about role groups, see Understanding management role groups.
Users who are members of the Help Desk role group can perform limited recipient management of Exchange
2013 recipients.
The Help Desk role group, by default, enables members to view and modify the Outlook Web App options of
any user in the organization. These options might include modifying the user's display name, address, phone
number, and so on. They don't include options that aren't available in Outlook Web App options, such as
modifying the size of a mailbox or configuring the mailbox database on which a mailbox is located.
The members of this role group can only modify the Outlook Web App options that the user can modify. This
means that if a user can modify his or her display name, a member of the Help Desk role group can also modify
that user's display name. However, if another user isn't allowed to modify his or her display name, a member of
the Help Desk role group can't modify that user's display name.

WARNING
The limitations on which Outlook Web App options a member of the Help Desk role group can modify are enforced by the
Exchange admin center (EAC). If a member of the Help Desk role group has access to the Exchange Management Shell, he
or she can modify any Outlook Web App option for any user. You should carefully consider who you make a member of
the Help Desk role group and whether they should also be given access to the Shell.

The Help Desk role group doesn't enable any other tasks because there are so many different types of
organizations. Instead, you can add management roles to this role group to create a Help Desk role group that
matches the needs of your organization. For example, if you want members of the Help Desk role group to be
able to manage mailboxes, mail contacts, and mail-enabled users, assign the Mail Recipients management role
to this role group. For more information about how to add management roles to this role group, see the "Role
Group Customization" section later in this topic.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are members
of this role group.
 Get-RoleGroupMember "Help Desk"

For more information about the members of a role group, see View the members of a role group in Manage role
group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to
a role group, you enable the members of that role group to perform the tasks associated with the role. For
example, the Journaling role enables the management of the Journaling agent and journaling rules. For more
information about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine
what Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in a
specific location. For more information about management scopes, see Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to
other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
 Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

User X Organization Organization OrganizationConfig

OrganizationConfig
Options
role

View- X Organization None OrganizationConfig

None
Only
Recipients
role
 Hygiene Management
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Hygiene Management management role group is one of several built-in role groups that make up the Role
Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are assigned
one or more management roles that contain the permissions required to perform a given set of tasks. The
members of a role group are granted access to the management roles assigned to the role group. For more
information about role groups, see Understanding management role groups.
Users who are members of the Hygiene Management role group can configure the anti-spam and anti-malware
features of Exchange 2013. Third-party programs that integrate with Exchange 2013 can add service accounts
to this role group to grant those programs access to the cmdlets required to retrieve and configure the
Exchange configuration.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are
members of this role group.

Get-RoleGroupMember "Hygiene Management"

For more information about the members of a role group, see the "View the members of a role group" section
in Manage role group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to
a role group, you enable the members of that role group to perform the tasks associated with the role. For
example, the Journaling role enables the management of the Journaling agent and journaling rules. For more
information about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine
what Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in
a specific location. For more information about management scopes, see Understanding management role
scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to
other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Applicatio X Organization Organization None None

nImperso
nation
role

Receive X Organization Organization OrganizationConfig

OrganizationConfig
Connecto
rs role

Transport X Organization Organization OrganizationConfig

OrganizationConfig
Agents
role
 CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Transport X Organization Organization OrganizationConfig

OrganizationConfig
Hygiene
role

View- X Organization None OrganizationConfig

None
Only
Configura
tion role

View- X Organization None OrganizationConfig

None
Only
Recipients
role
 Compliance Management
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Compliance Management management role group is one of several built-in role groups that make up the
Role Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are
assigned one or more management roles that contain the permissions required to perform a given set of tasks.
The members of a role group are granted access to the management roles assigned to the role group. For more
information about role groups, see Understanding management role groups.
Users who are members of the Compliance Management role group can configure and manage Exchange
compliance configuration in accordance with their policies.
For more information about compliance features, see Messaging policy and compliance. For more information
about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are members
of this role group.

Get-RoleGroupMember "Compliance Management"

For more information about the members of a role group, see View the members of a role group in Manage role
group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to
a role group, you enable the members of that role group to perform the tasks associated with the role. For
example, the Journaling role enables the management of the Journaling agent and journaling rules. For more
information about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine
what Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in a
specific location. For more information about management scopes, see Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
 Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to other
role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Data Loss X Organization Organization OrganizationConfig

OrganizationConfig
Preventio
n role

Informati X Organization Organization OrganizationConfig

OrganizationConfig
on Rights
Managem
ent role

Retention X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent role
 CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

View- X Organization None OrganizationConfig

None
Only
Audit
Logs role

View- X Organization None OrganizationConfig

None
Only
Configura
tion role

View- X Organization None OrganizationConfig

None
Only
Recipients
role
 Records Management
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Records Management management role group is one of several built-in role groups that make up the Role
Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are assigned
one or more management roles that contain the permissions required to perform a given set of tasks. The
members of a role group are granted access to the management roles assigned to the role group. For more
information about role groups, see Understanding management role groups.
Users who are members of the Records Management role group can configure compliance features, such as
retention policy tags, message classifications, and transport rules.
For more information about compliance features, see Messaging policy and compliance. For more information
about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are
members of this role group.

Get-RoleGroupMember "Records Management"

For more information about the members of a role group, see View the members of a role group in Manage
role group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to
a role group, you enable the members of that role group to perform the tasks associated with the role. For
example, the Journaling role enables the management of the Journaling agent and journaling rules. For more
information about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine
what Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in
a specific location. For more information about management scopes, see Understanding management role
scopes.
For more information about how to customize this role group, see the following topics:
 Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to
other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to
read from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Audit X Organization Organization OrganizationConfig

OrganizationConfig
Logs role

Journalin X Organization Organization OrganizationConfig

OrganizationConfig
g role

Message X Organization Organization OrganizationConfig

OrganizationConfig
Tracking
role

Retention X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent role
 CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Transport X Organization Organization OrganizationConfig

OrganizationConfig
Rules role
 Discovery Management
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Discovery Management management role group is one of several built-in role groups that make up the Role
Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are assigned
one or more management roles that contain the permissions required to perform a given set of tasks. The
members of a role group are granted access to the management roles assigned to the role group. For more
information about role groups, see Understanding management role groups.
Administrators or users who are members of the Discovery Management role group can perform searches of
mailboxes in the Exchange organization for data that meets specific criteria and can also configure litigation holds
on mailboxes. For more information, see In-Place eDiscovery.

IMPORTANT
The Organization Management role group doesn't, by default, enable the discovery search feature for users or universal
security groups (USGs) that are members of that role group. Members of the Organization Management role group must
either be made members of this role group, or the Mailbox Search role listed later in this topic must be manually assigned
to the Organization Management role group. For information about how to assign a role to a role group, see Manage role
groups.

For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or USGs that are members of this role group.

Get-RoleGroupMember "Discovery Management"

For more information about the members of a role group, see View the members of a role group in Manage role
group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to a
role group, you enable the members of that role group to perform the tasks associated with the role. For example,
the Journaling role enables the management of the Journaling agent and journaling rules. For more information
about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine what
Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in a
specific location. For more information about management scopes, see Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following attributes
of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to other
role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Legal X Organization Organization OrganizationConfig

None
Hold role

Mailbox X Organization Organization None None

Search
role
 Public Folder Management
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Public Folder Management management role group is one of several built-in role groups that make up the
Role Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are
assigned one or more management roles that contain the permissions required to perform a given set of tasks.
The members of a role group are granted access to the management roles assigned to the role group. For more
information about role groups, see Understanding management role groups.
Administrators who are members of the Public Folder Management role group can manage public folders on
servers running Exchange 2013.
For more information about public folders, see Public folders. For more information about RBAC, see
Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are members
of this role group.

Get-RoleGroupMember "Public Folder Management"

For more information about the members of a role group, see View the members of a role group in Manage role
group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to a
role group, you enable the members of that role group to perform the tasks associated with the role. For example,
the Journaling role enables the management of the Journaling agent and journaling rules. For more information
about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine what
Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in a
specific location. For more information about management scopes, see Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
 Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new role
group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following attributes
of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to other
role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role group
are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Mail X Organization Organization OrganizationConfig

OrganizationConfig
Enabled
Public
Folders
role

Public X Organization Organization OrganizationConfig

OrganizationConfig
Folders
role
 Server Management
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Server Management management role group is one of several built-in role groups that make up the
Role Based Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups
are assigned one or more management roles that contain the permissions required to perform a given set
of tasks. The members of a role group are granted access to the management roles assigned to the role
group. For more information about role groups, see Understanding management role groups.
Administrators who are members of this role group can configure server-specific configuration of
transport client access, and mailbox features such as database copies, certificates, transport queues and
Send connectors, virtual directories, and client access protocols.
This role group is similar to the Exchange Server Administrators role in Microsoft Exchange Server 2007. It
grants access to manage the configuration of physical servers. However, unlike the Exchange Server
Administrators role in Exchange 2007, which provided access only to a local server running Exchange
2007, the Server Management role group enables access to view and configure all Exchange Server 2010
servers in the organization.
If you want to allow administrators to manage only specific servers in your organization, you can change
the management scopes that are applied to this role group. Alternatively, you can create a role group,
based on the Server Management role group, and customize the management scopes on the new role
group. For more information, see the "Role Group Customization" section later in this topic.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from
this role group. For more information about how to add additional role group delegates, see the "Add or
remove a role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are
members of this role group.

Get-RoleGroupMember "Server Management"

For more information about the members of a role group, see View the members of a role group in
Manage role group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or
from this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning
roles to a role group, you enable the members of that role group to perform the tasks associated with the
role. For example, the Journaling role enables the management of the Journaling agent and journaling
rules. For more information about how roles are assigned to role groups, see Understanding management
role assignments.
The roles assigned to this role group are given default management scopes. Management scopes
determine what Exchange objects can be viewed or modified by the members of a role group. You can
change the scopes associated with assignments between roles and role groups. For example, you might
want to do this if you only want members of a role group to be able to change recipients that are under a
specific organizational unit or in a specific location. For more information about management scopes, see
Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the
new role group, see the "Create a role group" section in Manage role groups.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following
attributes of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries
made available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to
other role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed
to read from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed
to modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role
group are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the
role group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
CONFIGURATI CONFIGURATI
MANAGEMEN REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
T ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Database X Organization Organization OrganizationConfig

OrganizationConfig
Copies
role
 CONFIGURATI CONFIGURATI
MANAGEMEN REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
T ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Database X Organization Organization OrganizationConfig

OrganizationConfig
s role

Exchange X Organization Organization OrganizationConfig

OrganizationConfig
Connect
ors role

Exchange X Organization Organization OrganizationConfig

OrganizationConfig
Server
Certificat
es role

Exchange X Organization Organization OrganizationConfig

OrganizationConfig
Servers
role

Exchange X Organization Organization OrganizationConfig

OrganizationConfig
Virtual
Directori
es role

Monitori X Organization Organization OrganizationConfig

OrganizationConfig
ng role

POP3 X Organization Organization OrganizationConfig

OrganizationConfig
and
IMAP4
Protocols
role

Receive X Organization Organization OrganizationConfig

OrganizationConfig
Connect
ors role

Transpor X Organization Organization OrganizationConfig

OrganizationConfig
t Queues
role
 Delegated Setup
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Delegated Setup management role group is one of several built-in role groups that make up the Role Based
Access Control (RBAC ) permissions model in Microsoft Exchange Server 2013. Role groups are assigned one or
more management roles that contain the permissions required to perform a given set of tasks. The members of a
role group are granted access to the management roles assigned to the role group. For more information about
role groups, see Understanding management role groups.
Administrators who are members of the Delegated Setup role group can deploy servers running Exchange 2013
that have been previously provisioned by a member of the Organization Management role group.
Members of the Delegated Setup role group can only deploy Exchange 2013 servers. They can't manage the
server after it's been deployed. To manage a server after it's been deployed, a user must be a member of the
Server Management role group.
For more information about RBAC, see Understanding Role Based Access Control.

Role group membership

If you want to add or remove members to or from this role group, see Manage role group members.
By default, only members of the Organization Management role group can add or remove members from this
role group. For more information about how to add additional role group delegates, see the "Add or remove a
role group delegate" section in Manage role groups.
You can use the following command to view a list of users or universal security groups (USGs) that are members
of this role group.

Get-RoleGroupMember "Delegated Setup"

For more information about the members of a role group, see View the members of a role group in Manage role
group members.

Role group customization

This role group is assigned management roles by default. The roles that are included are listed in the
"Management Roles Assigned to this Role Group" section. You can add or remove role assignments to or from
this role group to match the needs of your organization.
The role groups provided with Exchange 2013 are designed to match more granular tasks. By assigning roles to a
role group, you enable the members of that role group to perform the tasks associated with the role. For example,
the Journaling role enables the management of the Journaling agent and journaling rules. For more information
about how roles are assigned to role groups, see Understanding management role assignments.
The roles assigned to this role group are given default management scopes. Management scopes determine what
Exchange objects can be viewed or modified by the members of a role group. You can change the scopes
associated with assignments between roles and role groups. For example, you might want to do this if you only
want members of a role group to be able to change recipients that are under a specific organizational unit or in a
specific location. For more information about management scopes, see Understanding management role scopes.
For more information about how to customize this role group, see the following topics:
Manage role groups
Manage role group members
If you want to create a role group and assign some of the roles that are assigned to this role group to the new
role group, see the "Create a role group" section in Manage role groups.

Additional permissions
The permissions granted to members of the Delegated Setup role group are primarily determined by the
management roles assigned to the role group. However, not all tasks that you need to perform are covered by
management roles. This is because some tasks occur outside of the Exchange management tools and therefore
the RBAC permissions model doesn't apply. For these tasks, permissions are provided by adding the Delegated
Setup role group to the access control lists (ACLs) of certain Active Directory objects.
The following task is granted permissions by way of ACLs on Active Directory objects and not by management
roles assigned to the Delegated Setup role group:
Deployment of servers that have been previously provisioned by a member of the Organization Management
role group.

Management roles assigned to this role group

The following table lists all the management roles that are assigned to this role group and the following attributes
of each role assignment:
Regular assignment: Enables members of the role group to access the management role entries made
available by the associated management role.
Delegating assignment: Gives members of the role group the ability to assign the specified role to other
role groups, role assignment policies, users, or USGs.
Recipient read scope: Determines what recipient objects members of the role group are allowed to read
from Active Directory.
Recipient write scope: Determines what recipient objects members of the role group are allowed to
modify in Active Directory.
Configuration read scope: Determines what configuration and server objects members of the role group
are allowed to read from Active Directory.
Configuration write scope: Determines what organizational and server objects members of the role
group are allowed to modify in Active Directory.
For more information about role assignments and management scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
Management roles assigned to this role group
 CONFIGURATI CONFIGURATI
MANAGEMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

View- X Organization None OrganizationConfig

None
Only
Configura
tion role
 Built-in management roles
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 includes many management roles by default. The following roles are
assigned to management role groups or management role assignment policies in various
combinations that grant permissions to manage and use the features provided by Exchange 2013. For
more information about roles, see Understanding management roles.
Active Directory Permissions role
Address Lists role
ApplicationImpersonation role
ArchiveApplication role
Audit Logs role
Cmdlet Extension Agents role
Data Loss Prevention role
Database Availability Groups role
Database Copies role
Databases role
Disaster Recovery role
Distribution Groups role
Edge Subscriptions role
E -Mail Address Policies role
Exchange Connectors role
Exchange Server Certificates role
Exchange Servers role
Exchange Virtual Directories role
Federated Sharing role
Information Rights Management role
Journaling role
Legal Hold role
LegalHoldApplication role
Mail Enabled Public Folders role
Mail Recipient Creation role
Mail Recipients role
Mail Tips role
Mailbox Import Export role
Mailbox Search role
MailboxSearchApplication role
Message Tracking role
Migration role
Monitoring role
Move Mailboxes role
My Custom Apps role
My Marketplace Apps role
MyAddressInformation role
MyBaseOptions role
MyContactInformation role
MyDiagnostics role
MyDisplayName role
MyDistributionGroupMembership role
MyDistributionGroups role
MyMobileInformation role
MyName role
MyPersonalInformation role
MyProfileInformation role
MyRetentionPolicies role
MyTeamMailboxes role
MyTextMessaging role
MyVoiceMail role
OfficeExtensionApplication role
Org Custom Apps role
Org Marketplace Apps role
Organization Client Access role
Organization Configuration role
Organization Transport Settings role
POP3 and IMAP4 Protocols role
Public Folders role
Receive Connectors role
Recipient Policies role
Remote and Accepted Domains role
Reset Password role
Retention Management rolet
Role Management role
Security Group Creation and Membership role
Send Connectors role
Support Diagnostics role
Team Mailboxes role
TeamMailboxLifecycleApplication role
Transport Agents role
Transport Hygiene role
Transport Queues role
Transport Rules role
UM Mailboxes role
UM Prompts role
Unified Messaging role
Unscoped Role Management role
User Options role
UserApplication role
View -Only Audit Logs role
View -Only Configuration role
View -Only Recipients role
 Active Directory Permissions role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Active Directory Permissions management role enables administrators to configure Active Directory
permissions in an organization. Some features that use Active Directory permissions or an access control list
(ACL ) include transport Receive and Send connectors, and Send As and Send on behalf of permissions for
mailboxes.

NOTE
Permissions set directly on Active Directory objects may not be enforced through Role Based Access Control (RBAC).

This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
 more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized role,
be sure to add a delegating role assignment to at least one role assignee. For more information, see Delegate role
assignments.
 Address Lists role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Address Lists management role enables administrators to create, modify, view, and remove address lists,
global address lists (GALs), address book policies, and offline address lists (OABs) in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 ApplicationImpersonation role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The ApplicationImpersonation management role enables applications to impersonate users in an organization to
perform tasks on behalf of the user.
For example, you might see these roles in the Exchange admin center:
ISVMailboxUsers_<xxxxx>
RIM -MailboxAdmins<xxxxxxxxxx>

IMPORTANT
A process or application that's a member of the ApplicationImpersonation role can access the contents of a user's
mailbox and act on behalf of that user, even if the user's account is disabled. This might let users access their mailboxes if
you have applications, like Blackberry Enterprise Server, that use the ApplicationImpersonation role. Third-party products
that don't use the ApplicationImpersonation role and instead use Exchange ActiveSync can't access a mailbox after its
user account has been disabled.
To prevent an application that uses the ApplicationImpersonation role from accessing a mailbox or performing tasks on
its behalf after its user account has been disabled, do one or more of the following:
Disable or remove the user in the third-party application.
Delete the mailbox.

This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Hygiene X Organization Organization None None

Managem
ent

Organizati X Organization Organization None None

on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 ArchiveApplication role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The ArchiveApplication management role enables partner applications to archive items in user mailboxes.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Audit Logs role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Audit Logs management role enables administrators to configure the administrator audit log in an
organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Records X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Cmdlet Extension Agents role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Cmdlet Extension Agents management role enables administrators to enable, disable, and set the priority of
cmdlet extension agents in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Data Loss Prevention role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Data Loss Prevention management role enables administrators to create and manage data loss prevention
(DLP ) policies and the rules within them, which can affect mail delivery for an entire organization. Furthermore,
this role provides administrators with the ability to configure Policy Tips that appear in email clients and manage
DLP policy violation reports. This DLP role also enables access to Microsoft Exchange transport rules. For more
information about transport rules in Exchange, see the following topics:
Transport Rules role
What's new for transport rules
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments
This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
 Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Complianc X Organization Organization OrganizationConfig

OrganizationConfig
e
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Database Availability Groups role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Database Availability Groups management role enables administrators to manage database availability
groups in an organization. Administrators assigned this role either directly or indirectly are the highest level
administrators responsible for the high availability configuration in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Database Copies role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Database Copies management role enables administrators to add, remove, suspend, resume, view, and
update database copies on individual servers.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Additional scope considerations

The Set-MailboxDatabaseCopy and Remove-MailboxDatabaseCopy cmdlets, which are included with this
role, require that the database you want to configure or remove must be within the database scope and the
database must reside on a server that's within the server scope. For more information about scopes, see
Understanding management role scopes.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Databases role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Databases management role enables administrators to create, manage, mount, and dismount mailbox
databases on individual servers.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Additional scope considerations

The Move-DatabasePath cmdlet, which is included with this role, requires that the database you want to
configure must be within the database scope and the database must reside on a server that's within the server
scope.
Also, the Remove-MailboxDatabase cmdlet, which is also included with this role, requires that the database you
want to remove must either be within the database scope or the database must reside on a server that's within the
server scope. This means you control who can remove mailbox databases using either database or server scopes.
For more information, see Understanding management role scopes.

Default Management Role Assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent
Management role customization
This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Disaster Recovery role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Disaster Recovery management role enables administrators to restore mailboxes and mailbox databases,
create mailbox databases, and perform datacenter switchovers and switchbacks for database availability groups in
an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Distribution Groups role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Distribution Groups management role enables administrators to create, modify, view, and remove
distribution groups, and add or remove distribution group members in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Edge Subscriptions role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Edge Subscriptions management role enables administrators to manage edge synchronization and
subscription configuration between Microsoft Exchange Server 2010 Edge Transport servers and Microsoft
Exchange Server 2013 Mailbox servers in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 E-Mail Address Policies role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The E-Mail Address Policies management role enables administrators to manage email address policies in an
organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Exchange Connectors role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Exchange Connectors management role enables administrators to create, modify, view, and remove delivery
agent connectors.
This role can't be used to manage Send and Receive connectors. To manage Send and Receive connectors, use the
Send Connectors and Receive Connectors roles. For more information, see:
Send Connectors role
Receive Connectors role
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments
This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
 Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Exchange Server Certificates role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Exchange Server Certificates management role enables administrators to create, import, export, and
manage Exchange server certificates on individual servers.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Exchange Servers role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Exchange Servers management role enables administrators to do the following on individual servers:
Add and remove database availability groups and configure database copies
Enable, disable and configure Unified Messaging services
Modify transport configuration on Mailbox and Client Access servers
Enable and disable Microsoft Outlook Anywhere on Client Access servers
Modify Mailbox and Client Access server configuration
Modify Outlook Anywhere configuration on Client Access servers
Modify content filtering configuration on Mailbox servers
Modify general Exchange server configuration
Modify server monitoring configuration
View the configuration for each server role
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
 Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
 the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent
 CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Exchange Virtual Directories role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Exchange Virtual Directories management role enables administrators to manage Microsoft Office Outlook
Web App, Microsoft ActiveSync, offline address books (OABs), Autodiscover, Windows PowerShell, and Web
administration interface virtual directories on individual servers.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Federated Sharing role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Federated Sharing management role enables administrators to manage cross-forest and cross-organization
sharing in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Information Rights Management role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Information Rights Management management role enables administrators to manage the Information Rights
Management (IRM ) features of Exchange in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Complianc X Organization Organization OrganizationConfig

OrganizationConfig
e
Managem
ent

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Journaling role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Journaling management role enables administrators to create, modify, enable, disable, view, and remove
journal rules in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Records X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Legal Hold role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Legal Hold management role enables administrators to configure whether data within a mailbox should be
retained for litigation purposes in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Additional scope considerations

In addition to recipient scopes, the Enable-Mailbox cmdlet, which is included with this role, is also scoped using
database configuration scopes. Database configuration scopes control which databases the cmdlet can create new
mailboxes on. The database where you want to create a mailbox must be within the database scope. This applies
both when you specify a database using the Database parameter on the Enable-Mailbox cmdlet, or if you allow
automatic mailbox distribution to select the database for you. For more information, see Understanding
management role scopes.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Discovery X Organization Organization OrganizationConfig

None
Managem
ent

Organizati X X Organization Organization OrganizationConfig

None
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 LegalHoldApplication role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The LegalHoldApplication management role enables partner applications to set and view the legal hold status of a
mailbox.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT CONFIGURATIO ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE N READ SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Mail Enabled Public Folders role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Mail Enabled Public Folders management role enables administrators to configure whether individual public
folders are mail-enabled or mail-disabled in an organization.
This role enables you to manage only the e-mail properties of public folders. It doesn't enable you to manage
public folder properties that aren't related to e-mail. To manage public folder properties that aren't related to e-
mail, use the Public Folders role. For more information, see Public Folders role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
 the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Public X Organization Organization OrganizationConfig

OrganizationConfig
Folder
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Mail Recipient Creation role
5/28/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Mail Recipient Creation management role enables administrators to create mailboxes, mail users, mail
contacts, distribution groups, and dynamic distribution groups in an organization. This role can be combined with
the Mail Recipients role to enable the creation and management of recipients. For more information, see Mail
Recipients role.
This role doesn't enable you to mail-enable public folders. To mail-enable public folders, the
Mail Enabled Public Folders role must be used. For more information, see Mail Enabled Public Folders role.

If your organization maintains a Role Based Access Control (RBAC ) split permissions model where recipient
creation is performed by a different group than those who perform recipient management, assign the
Mail Recipient Creation role to the management role group that performs recipient creation, and the
Mail Recipients role to the role group that performs recipient management.

If your organization has enabled Active Directory split permissions, all non-delegating management role
assignments to this management role were removed. When Active Directory split permissions is enabled, only
Active Directory administrators using Active Directory management tools can create new security principals such
as users and security groups.
For more information about RBAC and Active Directory split permissions, see Understanding split permissions.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
 Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
 Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Additional scope considerations

In addition to recipient scopes, the New-Mailbox cmdlet, which is included with this role, is also scoped using
database configuration scopes. Database configuration scopes control which databases the cmdlet can create new
mailboxes on. The database where you want to create a mailbox must be within the database scope. This
condition applies when you specify a database using the Database parameter on the New-Mailbox cmdlet or if
you allow automatic mailbox distribution to select the database for you. For more information, see Understanding
management role scopes.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Mail Recipients role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Mail Recipients management role enables administrators to manage existing mailboxes, mail users, and
mail contacts in an organization. This role can't create these recipients. Use the Mail Recipient Creation role to
create them.
This role type doesn't enable you to manage mail-enabled public folders or distribution groups. Use the following
roles to manage these objects:
Mail Enabled Public Folders role
Distribution Groups role
If your organization has a split permissions model where recipient creation and management are performed by
different groups, assign the Mail Recipient Creation role to the group that performs recipient creation and the
Mail Recipients role to the group that performs recipient management. For more information, see the following
topics:
Mail Recipient Creation role
Mail Recipients role
Understanding split permissions
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
 Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
 Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Additional scope considerations

In addition to recipient scopes, the Connect-Mailbox and Enable-Mailbox cmdlets, which are included with
this role, are also scoped using database configuration scopes. Database configuration scopes control which
databases the cmdlets can create new mailboxes on. The database where you want to create a mailbox must be
within the database scope. This condition applies when you specify a database using the Database parameter on
either cmdlet or if you allow automatic mailbox distribution to select the database for you. For more information,
see Understanding management role scopes.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Mail Tips role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Mail Tips management role enables administrators to manage mail tips in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Mailbox Import Export role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Mailbox Import Export management role enables administrators to import and export mailbox content and to
purge unwanted content from a mailbox.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Mailbox Search role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Mailbox Search management role enables administrators to search the content of one or more mailboxes in
an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Discovery X Organization Organization None None

Managem
ent

Organizati X Organization Organization None None

on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 MailboxSearchApplication role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MailboxSearchApplication management role enables partner applications to search mailboxes.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Message Tracking role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Message Tracking management role enables administrators to track messages in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Records X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Migration role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Migration management role enables administrators to migrate mailboxes and mailbox content into or out of
a server.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Monitoring role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Monitoring management role enables administrators to monitor Exchange services and component
availability in an organization. This role can also be used with service accounts used by monitoring applications to
collect information about the state of servers running Exchange.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

View-only X Organization Organization OrganizationConfig

OrganizationConfig
Organizati
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Move Mailboxes role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Move Mailboxes management role enables administrators to move mailboxes between servers in an
organization and between servers in the local organization and another organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Additional scope considerations

In addition to recipient scopes, the New-MoveRequest cmdlet, which is included with this role, is also scoped
using database configuration scopes. Database configuration scopes control which databases the cmdlet can
move mailboxes to. The database where you want to move a mailbox must be within the database scope. This
condition applies when you specify a database using the TargetDatabase parameter on the New-MoveRequest
cmdlet or if you allow automatic mailbox distribution to select the database for you. For more information, see
Understanding management role scopes.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 My Custom Apps role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The My Custom Apps role enables individual users to add apps from a file or a URL.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 My Marketplace Apps role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The My Marketplace Apps management role enables individual users to add apps from the Microsoft Office Store.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X Self Self OrganizationConfig

OrganizationConfig
role
assignme
nt policy.
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
 "Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyAddressInformation role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyAddressInformation management role enables individual users to view and modify their street address and
work telephone and fax numbers. This is a custom role created from the MyContactInformation role parent role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role.
This role is a specific type of role called a custom role. A custom role is one that's created, or derived, from a parent
role. It contains a subset of management role entries that exist on the parent role. This role is provided to enable
you to control, with a greater level of granularity, the information you allow end users to modify on their own
mailboxes. Unlike other built-in roles, custom roles, including this one, can be deleted. If you won't use this role, it
can be deleted.
For more information about built-in and custom management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, its parent role must be assigned to a role group you're a member of, directly to
you, or to a USG you're a member of, using a delegating role assignment. For more information about delegating
role assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role doesn't have any default role assignments. It's provided in case you want control, at a more granular
level, of what end-user information you allow your users to modify. For more information about assigning this role
to a role assignment policy, see the "Adding or Removing Role Assignments" section.

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyBaseOptions role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyBaseOptions management role enables individual users to view and modify the basic configuration of their
own mailbox and associated settings.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X Self Self OrganizationConfig

OrganizationConfig
role
assignme
nt policy.
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
 associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyContactInformation role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyContactInformation management role enables individual users to modify their contact information,
including address and phone numbers.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X Self Self OrganizationConfig

OrganizationConfig
role
assignme
nt policy.
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
 associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 MyDiagnostics role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyDiagnostics management role enables individual users to perform basic diagnostics on their mailbox such
as retrieving calendar diagnostic information.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyDisplayName role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyDisplayName management role enables individual users to view and modify their display name. This is a
custom role created from the MyProfileInformation role parent role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role.
This role is a specific type of role called a custom role. A custom role is one that's created, or derived, from a parent
role. It contains a subset of management role entries that exist on the parent role. This role is provided to enable
you to control, with a greater level of granularity, the information you allow end users to modify on their own
mailboxes. Unlike other built-in roles, custom roles, including this one, can be deleted. If you won't use this role, it
can be deleted.
For more information about built-in and custom management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, its parent role must be assigned to a role group you're a member of, directly to
you, or to a USG you're a member of, using a delegating role assignment. For more information about delegating
role assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role doesn't have any default role assignments. It's provided in case you want control, at a more granular
level, of what end-user information you allow your users to modify. For more information about assigning this role
to a role assignment policy, see the "Adding or Removing Role Assignments" section.

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyDistributionGroupMembership role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyDistributionGroupMembership management role enables individual users to view and modify their
membership in distribution groups in an organization, provided that those distribution groups allow manipulation
of group membership.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X MyGAL MyGAL None None

role
assignme
nt policy.
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X MyGAL MyGAL None None

on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
 associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyDistributionGroups role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyDistributionGroups management role enables individual users to create, modify, and view distribution
groups, and to modify, view, remove, and add members to distribution groups they own.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X MyGAL MyDistributionGroups

OrganizationConfig
None
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyMobileInformation role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyMobileInformation management role enables individual users to view and modify their mobile telephone
and pager numbers. This is a custom role created from the MyContactInformation role parent role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role.
This role is a specific type of role called a custom role. A custom role is one that's created, or derived, from a parent
role. It contains a subset of management role entries that exist on the parent role. This role is provided to enable
you to control, with a greater level of granularity, the information you allow end users to modify on their own
mailboxes. Unlike other built-in roles, custom roles, including this one, can be deleted. If you won't use this role, it
can be deleted.
For more information about built-in and custom management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, its parent role must be assigned to a role group you're a member of, directly to
you, or to a USG you're a member of, using a delegating role assignment. For more information about delegating
role assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role doesn't have any default role assignments. It's provided in case you want control, at a more granular
level, of what end-user information you allow your users to modify. For more information about assigning this role
to a role assignment policy, see the "Adding or Removing Role Assignments" section.

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyName role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyName management role enables individual users to view and modify their full name and their notes field.
This is a custom role created from the MyProfileInformation role parent role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role.
This role is a specific type of role called a custom role. A custom role is one that's created, or derived, from a parent
role. It contains a subset of management role entries that exist on the parent role. This role is provided to enable
you to control, with a greater level of granularity, the information you allow end users to modify on their own
mailboxes. Unlike other built-in roles, custom roles, including this one, can be deleted. If you won't use this role, it
can be deleted.
For more information about built-in and custom management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, its parent role must be assigned to a role group you're a member of, directly to
you, or to a USG you're a member of, using a delegating role assignment. For more information about delegating
role assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role doesn't have any default role assignments. It's provided in case you want control, at a more granular
level, of what end-user information you allow your users to modify. For more information about assigning this role
to a role assignment policy, see the "Adding or Removing Role Assignments" section.

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyPersonalInformation role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyPersonalInformation management role enables individual users to view and modify their website, address,
and home telephone number. This is a custom role created from the MyContactInformation role parent role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role.
This role is a specific type of role called a custom role. A custom role is one that's created, or derived, from a parent
role. It contains a subset of management role entries that exist on the parent role. This role is provided to enable
you to control, with a greater level of granularity, the information you allow end users to modify on their own
mailboxes. Unlike other built-in roles, custom roles, including this one, can be deleted. If you won't use this role, it
can be deleted.
For more information about built-in and custom management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, its parent role must be assigned to a role group you're a member of, directly to
you, or to a USG you're a member of, using a delegating role assignment. For more information about delegating
role assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role doesn't have any default role assignments. It's provided in case you want control, at a more granular
level, of what end-user information you allow your users to modify. For more information about assigning this role
to a role assignment policy, see the "Adding or Removing Role Assignments" section.

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyProfileInformation role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyProfileInformation management role enables individual users to modify their name.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 My ReadWriteMailbox Apps role
5/28/2019 • 6 minutes to read • Edit Online

The My ReadWriteMailbox Apps role enables individual users to add add-ins that request the ReadWriteMailbox
permission in their manifest.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be run
by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant the
role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups you
create, users, and USGs. However, there must always be at least one delegating role assignment between this role
and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 ROLE GROUP
OR
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT CONFIGURATIO CONFIGURATIO
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE N READ SCOPE N WRITE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyRetentionPolicies role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyRetentionPolicies management role enables individual users to view their retention tags, and to view and
modify their retention tag settings and defaults.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyTeamMailboxes role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyTeamMailboxes management role enables individual users to create site mailboxes and connect them to
Microsoft SharePoint sites.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X Organization Organization OrganizationConfig

OrganizationConfig
role
assignme
nt policy.
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
 associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyTextMessaging role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyTextMessaging management role enables individual users to create, view, and modify their text messaging
settings.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X Self Self OrganizationConfig

OrganizationConfig
Role
Assignme
nt Policy
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
 associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 MyVoiceMail role
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The MyVoiceMail management role enables individual users to view and modify their voice mail settings.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, such as a role assignment policy. This
assignment is done using management role assignments. Role assignments link role assignees and roles together.
If more than one role is assigned to a role assignee, the role assignee is granted the combination of all the
permissions granted by all the assigned roles.

NOTE
You can also assign this management role to a role group, USG, or directly to a user. However user-focused roles are most
effective when used with role assignment policies.

This user-focused role has implicit scopes that can't be modified. Therefore, you shouldn't add custom scopes to
role assignments that assign this role to role assignment policies, role groups, USGs, or users.
For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role may be assigned to one or more role assignment policies by default. For more information, see the
"Default Management Role Assignments" section.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role assignment policies, or
you can create role assignment policies and assign this role to them.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from the default role assignment policy, role assignment policies and role groups
you create, users, and USGs. However, there must always be at least one delegating role assignment between this
role and a role group or USG. You can't delete the last delegating role assignment.
For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
 ROLE GROUP
OR CONFIGURATI CONFIGURATI
ASSIGNMENT REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
POLICY ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Default X Self Self OrganizationConfig

OrganizationConfig
role
assignme
nt policy.
For more
informatio
n, see
Understan
ding
managem
ent role
assignme
nt policies.

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
 "Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 OfficeExtensionApplication role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The OfficeExtensionApplication management role enables Microsoft Office extension applications to access user
mailboxes.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Org Custom Apps role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Org Custom Apps management role enables administrators to view and modify their organization's apps, and
to add custom apps from a file or URL.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT CONFIGURATIO ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE N READ SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Org Marketplace Apps role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Org Marketplace Apps management role enables administrators to view and modify their organization's apps,
and to add apps from the Microsoft Office Store.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT CONFIGURATIO ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE N READ SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Organization Client Access role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Organization Client Access management role enables administrators to manage Client Access server
settings in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Organization Configuration role
6/14/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Organization Configuration management role enables administrators to manage organization-wide settings.
Organization configuration that can be controlled with this role includes the following and more:
Whether MailTips are enabled or disabled for the organization
URL for the managed folder home page
Microsoft Exchange recipient SMTP address and alternate email addresses
Resource mailbox property schema configuration
Help URLs for the Exchange admin center and Outlook Web App
This role type doesn't include the permissions included in the Organization Client Access or
Organization Transport Settings roles.

This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
 Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Organization Transport Settings role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Organization Transport Settings management role enables administrators to manage organization-wide
transport settings, such as system messages, Active Directory site configuration, and transport configuration
settings for the whole Exchange organization.
This role doesn't enable you to create or manage Send or Receive connectors, queues, hygiene, agents, remote
and accepted domains, or rules. To create or manage each of the transport features, you must be assigned one or
more of the following roles:
Receive Connectors role
Send Connectors role
Transport Queues role
Transport Hygiene role
Transport Agents role
Remote and Accepted Domains role
Transport Rules role
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
 Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
 Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent
Management role customization
This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 POP3 and IMAP4 Protocols role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The POP3 and IMAP4 Protocols management role enables administrators to manage POP3 and IMAP4
configuration, such as authentication and connection settings, on individual servers.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Public Folders role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Public Folders management role enables administrators to manage public folders in an organization.
This role doesn't enable you to manage whether public folders are mail-enabled. To mail-enable or disable a
public folder, you must be assigned a role associated with the Mail Enabled Public Folders role. For more
information, see Mail Enabled Public Folders role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Public X Organization Organization OrganizationConfig

OrganizationConfig
Folder
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Receive Connectors role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Receive Connectors management role enables administrators to manage transport Receive connector
configuration, such as size limits on an individual server.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can
create role groups and assign this role to them. You can also assign this role to users or USGs. However, we
recommend that you limit assignment of roles to users and USGs because such assignments can greatly increase
the complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the
last delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Hygiene X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list
of roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Recipient Policies role
6/14/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Recipient Policies management role enables administrators to manage recipient policies, such as throttling
policies, Outlook Web App mailbox policies, and mobile device policies, in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Remote and Accepted Domains role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Remote and Accepted Domains management role enables administrators to manage remote and accepted
domains in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Reset Password role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Reset Password management role enables individual users to reset their own passwords and administrators
to reset users' passwords in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Retention Management role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Retention Management management role enables administrators to manage retention policies in an
organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Complianc X Organization Organization OrganizationConfig

OrganizationConfig
e
Managem
ent

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Records X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Role Management role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Role Management management role enables administrators to manage management role groups; role
assignment policies and management roles; and role entries, assignments, and scopes in an organization.
Users assigned this role can override the role group managed by property, configure any role group, and add or
remove members to or from any role group.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Security Group Creation and Membership role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Security Group Creation and Membership management role enables administrators to create and manage
universal security groups (USGs) and their memberships in an organization.
If your organization maintains a Role Based Access Control (RBAC ) split permissions model where USG creation
and management is performed by a different group other than those who manage servers running Exchange,
assign this role to that group.
If your organization has enabled Active Directory split permissions, all non-delegating management role
assignments to this management role were removed. When Active Directory split permissions is enabled, only
Active Directory administrators using Active Directory management tools can create new security principals such
as users and security groups.
For more information, see Understanding split permissions.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
 Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Send Connectors role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Send Connectors management role enables administrators to manage transport Send connectors in an
organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Support Diagnostics role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Support Diagnostics management role enables administrators to perform advanced diagnostics under the
direction of Microsoft Customer Service and Support in an organization.

WARNING
This role grants permissions to cmdlets and scripts that should only be used under the direction of Customer Service and
Support.

This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments
This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
 Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Team Mailboxes role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Team Mailboxes management role enables administrators to define one or more site mailbox provisioning
policies and manage site mailboxes in the organization. Administrators assigned this role can manage site
mailboxes they don't own.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Recipient X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 TeamMailboxLifecycleApplication role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The TeamMailboxLifecycleApplication management role enables partner applications to update site mailbox
lifecycle states.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Self Self OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Transport Agents role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Transport Agents management role enables administrators to manage transport agents in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Hygiene X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Transport Hygiene role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Transport Hygiene management role enables administrators to manage anti-spam and anti-malware features
in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Hygiene X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Transport Queues role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Transport Queues management role enables administrators to manage message queues on an individual
transport server.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Server X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Transport Rules role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Transport Rules management role enables administrators to manage transport rules in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Records X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 UM Mailboxes role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The UM Mailboxes management role enables administrators to manage the Unified Messaging configuration of
mailboxes and other recipients in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

UM X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 UM Prompts role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The UM Prompts management role enables administrators to create and manage custom Unified Messaging voice
prompts in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

UM X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Unified Messaging role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Unified Messaging role enables administrators to manage Unified Messaging (UM ) services in an
organization.
This role doesn't enable you to manage UM -specific mailbox configuration or UM prompts. To manage UM -
specific mailbox configuration, use roles associated with the UM Mailboxes role. To manage UM prompts, use the
roles associated with the UM Prompts role. For more information, see:
UM Mailboxes role
UM Prompts role
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.
 Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
 more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

UM X Organization Organization OrganizationConfig

OrganizationConfig
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
Cau t i on

The following information enables you to perform advanced management of permissions. Customizing
management roles can significantly increase the complexity of your permissions model. You could cause certain
features to stop functioning if you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 Unscoped Role Management role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Unscoped Role Management management role enables administrators to create and manage unscoped top-level
management roles in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 User Options role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The User Options management role enables administrators to view the Outlook Web App options of a user in an
organization. This role can be used to help diagnose configuration problems.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Help Desk X Organization Organization OrganizationConfig

OrganizationConfig

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 UserApplication role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The UserApplication management role enables partner applications to act on behalf of end users.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.
Adding or removing role assignments
You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Organizati X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.
The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 View-Only Audit Logs role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The View-Only Audit Logs management role enables administrators and specialist users to search the
administrator audit logs in an organization.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Complianc X Organization None OrganizationConfig

None
e
Managem
ent

Organizati X X Organization None OrganizationConfig

None
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 View-Only Configuration role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The View-Only Configuration management role enables administrators to view all the non-recipient Exchange
configuration settings in an organization. Examples of configuration that are viewable are server configuration,
transport configuration, database configuration, and organization-wide configuration.
This role can be combined with roles associated with the View-Only Recipients role to create a role group that
can view every object in an organization. For more information, see View -Only Recipients role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can
create role groups and assign this role to them. You can also assign this role to users or USGs. However, we
recommend that you limit assignment of roles to users and USGs because such assignments can greatly increase
the complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the
last delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment
 using the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Complian X Organization None OrganizationConfig

None
ce
Managem
ent

Delegated X Organization None OrganizationConfig

None
Setup

Hygiene X Organization None OrganizationConfig

None
Managem
ent

Organizati X X Organization None OrganizationConfig

None
on
Managem
ent
 CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

View-only X Organization None OrganizationConfig

None
Organizati
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list
of roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 View-Only Recipients role
5/28/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

The View-Only Recipients management role enables administrators to view the configuration of recipients, such
as mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups.
This role can be combined with roles associated with the View-Only Configuration role to create a role group that
can view every object in the organization. For more information, see View -Only Configuration role.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions
model in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management
role groups, management role assignment policies, users, or universal security groups (USG ), act as a logical
grouping of cmdlets or scripts that are combined to provide access to view or modify the configuration of
Exchange 2013 components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and
its parameters, together called a management role entry, are included on a role, that cmdlet or script and its
parameters can be run by those assigned the role. For more information about management roles and
management role entries, see Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can
create role groups and assign this role to them. You can also assign this role to users or USGs. However, we
recommend that you limit assignment of roles to users and USGs because such assignments can greatly increase
the complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to
you, or to a USG you're a member of, using a delegating role assignment. For more information about delegating
role assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the
last delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information,
see the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment
using the Set-ManagementScope cmdlet. For more information, see Change a role scope.
Enabling or disabling role assignments
By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

Complian X Organization None OrganizationConfig

None
ce
Managem
ent

Help Desk X Organization None OrganizationConfig

None

Hygiene X Organization None OrganizationConfig

None
Managem
ent

Organizati X X Organization None OrganizationConfig

None
on
Managem
ent
 CONFIGURATI CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT ON READ ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE SCOPE SCOPE

View-only X Organization None OrganizationConfig

None
Organizati
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage
the features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list
of roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this
role, and customize the new role.

WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following
topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG
IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new
customized role, be sure to add a delegating role assignment to at least one role assignee. For more
information, see Delegate role assignments.
 WorkloadManagement role
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The WorkloadManagement management role enables administrators to manage workload management policies.
Administrators can configure resource health definitions, workload classifications, and enable or disable workload
management. Changes should only be made under the direction of Microsoft Customer Service and Support.
This management role is one of several built-in roles in the Role Based Access Control (RBAC ) permissions model
in Microsoft Exchange Server 2013. Management roles, which are assigned to one or more management role
groups, management role assignment policies, users, or universal security groups (USG ), act as a logical grouping
of cmdlets or scripts that are combined to provide access to view or modify the configuration of Exchange 2013
components, such as mailbox databases, transport rules, and recipients. If a cmdlet or script and its parameters,
together called a management role entry, are included on a role, that cmdlet or script and its parameters can be
run by those assigned the role. For more information about management roles and management role entries, see
Understanding management roles.
For more information about management roles, management role groups, and other RBAC components, see
Understanding Role Based Access Control.

Management role assignments

For this role to grant permissions, it must be assigned to a role assignee, which can be a role group, user, or
universal security group (USG ). This assignment is done using management role assignments. Role assignments
link role assignees and roles together. If more than one role is assigned to a role assignee, the role assignee is
granted the combination of all the permissions granted by all the assigned roles.
In addition to linking role assignees to roles, role assignments can also apply custom or built-in management
scopes. Management scopes control which recipient, server and database objects can be modified by role
assignees. If this role is assigned to a role assignee, but a management scope allows the role assignee only to
manage certain objects based on a defined scope, the role assignee can only use the permissions granted by this
role on those specific objects. The permissions provided by this role can't be applied to objects outside the scope
defined on the role assignment. For more information about role assignments and scopes, see the following topics:
Understanding management role assignments
Understanding management role scopes
This role is assigned to one or more role groups by default. For more information, see the "Default Management
Role Assignments" section later in this topic.
If you want to view a list of role groups, users, or USGs assigned to this role, use the following command.

Get-ManagementRoleAssignment -Role "<role name>"

Regular and delegating role assignments

This role can be assigned to role assignees using either regular or delegating role assignments. Regular role
assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant
the role assignee the ability to assign the role to other role assignees. For more information about regular and
delegating role assignments, see Understanding management role assignments.

Adding or removing role assignments

You can change which role assignees are assigned this role. By changing which role assignee is assigned this role,
you change who is granted its permissions. You can assign this role to other built-in role groups, or you can create
role groups and assign this role to them. You can also assign this role to users or USGs. However, we recommend
that you limit assignment of roles to users and USGs because such assignments can greatly increase the
complexity of your permissions model.
To assign this role to role assignees, the role must be assigned to a role group you're a member of, directly to you,
or to a USG you're a member of, using a delegating role assignment. For more information about delegating role
assignments, see the "Regular and Delegating Role Assignments" section.
You can also remove this role from built-in role groups, role groups you create, users, and USGs. However, there
must always be at least one delegating role assignment between this role and a role group or USG. You can't
delete the last delegating role assignment. This limitation helps prevent you from locking yourself out of the
system.

IMPORTANT
There must be at least one delegating role assignment between this role and a role group or USG. You can't remove the last
delegating role assignment associated with this role if the last assignment is to a user.

For more information about how to add or remove assignments between this role and role groups, users, and
USGs, see the following topics:
Manage role groups
Add a role to a user or USG
Remove a role from a user or USG

Changing the management scopes on role assignments

You can also change the management scopes on existing role assignments between this role and role assignees.
By changing the scopes on role assignments, you control what objects can be managed using the permissions
provided by this role. You have several choices when changing the scope on a role assignment. You can do one of
the following:
Add a new custom scope using the Set-ManagementRoleAssignment cmdlet. For more information, see
the following topics:
Create a regular or exclusive scope
Change a role assignment
Add or change an organizational unit scope using the Set-ManagementRoleAssignment cmdlet. For
more information, see Change a role assignment.
Add or change a predefined scope using the Set-ManagementRoleAssignment cmdlet. For more
information, see Change a role assignment.
Change the recipient, server, or database scope on a custom scope associated with a role assignment using
the Set-ManagementScope cmdlet. For more information, see Change a role scope.

Enabling or disabling role assignments

By enabling or disabling a role assignment, you control whether that role assignment should be in effect. If a role
assignment is disabled, the permissions granted by the associated role aren't applied to the role assignee. This is
convenient if you want to temporarily remove permissions without deleting a role assignment. For more
information, see Change a role assignment.

Default management role assignments

This role has role assignments to one or more role assignees. The following table indicates whether the role
assignment is regular or delegating, and also indicates the management scopes applied to each assignment. The
following list describes each column:
Regular assignment: Regular role assignments enable the role assignee to access the permissions
provided by the management role entries on this role.
Delegating assignment: Delegating role assignments give the role assignee the ability to assign this role
to role groups, users, or USGs.
Recipient read scope: The recipient read scope determines what recipient objects the role assignee is
allowed to read from Active Directory.
Recipient write scope: The recipient write scope determines what recipient objects the role assignee is
allowed to modify in Active Directory.
Configuration read scope: The configuration read scope determines what configuration and server
objects the role assignee is allowed to read from Active Directory.
Configuration write scope: The configuration write scope determines what organizational and server
objects the role assignee is allowed to modify in Active Directory.
Default management role assignments for this role
CONFIGURATI
REGULAR DELEGATING RECIPIENT RECIPIENT CONFIGURATIO ON WRITE
ROLE GROUP ASSIGNMENT ASSIGNMENT READ SCOPE WRITE SCOPE N READ SCOPE SCOPE

Organizati X X Organization Organization OrganizationConfig

OrganizationConfig
on
Managem
ent

Management role customization

This role has been configured to provide a role assignee with all necessary cmdlets and parameters to manage the
features and components listed in the beginning of this topic. Other roles have also been provided to enable
management of other features. By adding and removing roles to and from role groups, you can create a
customized permissions model without the need to customize individual management roles. For a complete list of
roles, see Built-in management roles. For more information about customizing role groups, see Manage role
groups.
If you decide that you need to create a customized version of this role, you must create a role as a child of this role,
and customize the new role.
 WARNING
The following information enables you to perform advanced management of permissions. Customizing management roles
can significantly increase the complexity of your permissions model. You could cause certain features to stop functioning if
you replace a built-in management role with an incorrectly configured custom role.

The following are the most common steps to create a customized role and assign it to a role assignee:
1. Create a copy of this role. For more information, see Create a role.
2. Change or remove the role entries on the new role using the Set-ManagementRoleEntry and Remove-
ManagementRoleEntry cmdlets. You can't add additional role entries to the new role because it can only
contain the role entries on the parent built-in role. For more information, see the following topics:
Change a role entry
Remove a role entry from a role
3. If you want to replace the built-in role with this new customized role, remove any role assignments
associated with the built-in role. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Remove a role from a user or USG
4. Add the new customized role to the required role assignees. For more information, see the following topics:
"Add or remove a role to or from a role group" section in Manage role groups
Add a role to a user or USG

IMPORTANT
If you want other users, in addition to the user that created the role, to be able to assign the new customized
role, be sure to add a delegating role assignment to at least one role assignee. For more information, see
Delegate role assignments.
 Understanding multiple-forest permissions
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

Many organizations deploy multiple forests to create security boundaries within their organizations. Using
multiple forests helps administrators to define these security boundaries to better match their requirements,
whether that's ensuring the fewest number of people have access to resources, or segmenting divisions within an
organization.
Microsoft Exchange Server 2013 supports two types of multiple forest topologies:
Cross-forest: Cross-forest topologies can have multiple forests, each with their own installation of
Exchange.
Resource forest: Resource forest topologies have an Exchange forest and one or more accounts forests.
For the purposes of this topic, the forest that contains the universal security groups (USGs) and users outside of
the forest where Exchange 2013 is installed, whether it's an accounts forest or other resource forest, is called a
foreign forest.
Configuration of permissions in a multiple forest topology relies on the correct configuration of forest trusts and
global address list (GAL ) synchronization for the creation of linked mailboxes. The Exchange 2013 forest must
trust the foreign forest that contains the USGs associated with linked role groups and users associated with linked
mailboxes.
Exchange 2013 uses a Role Based Access Control (RBAC ) permissions model. The management role groups that
administrators are members of, and the management role assignment policies that end users are assigned,
determine what each administrator and end user can do. To understand multiple-forest permissions, you need to
be familiar with RBAC. For more information about RBAC, role groups, and role assignment policies, see the
following topics:
Understanding Role Based Access Control
Understanding management role groups
Understanding management role assignment policies

Permissions in a multiple forest topology

RBAC applies permissions to all Exchange objects within a single forest and the RBAC configuration in each forest
is configured independently of all other forests. When you create a role group in one forest, that role group
doesn't exist in any other forest and the permissions granted by that role group apply only to the forest in which it
was created. For example, a member of a role group that grants permissions to create a mailbox can create a
mailbox only in the forest that contains that role group.
If you have multiple Exchange forests and want to configure permissions identically within each forest, you must
apply the same configuration explicitly in each forest. For example, if you have two Exchange 2013 forests and
want to create a Compliance Management role group to manage permissions for your legal department, you
must do the following:
In each forest, create a role group named Compliance Management. If your administrators are in a separate
foreign forest from either Exchange forest, create both role groups as linked role groups. For more
information about role groups, see the Cross-Boundary Permissions section.
 In each forest, create role assignments between the new role groups and the roles that you want to use.
As part of the new role assignments, optionally add management scopes that encompass the server and
recipient objects within each forest.
If you created the role groups as linked role groups, add members to the associated USG in the foreign
forest.
The following figure shows how the role groups configured within Exchange 2013 forests are bound to their
respective forests. The Organization Management role group in Exchange 2013 forest A grants permissions only
to manage the mailboxes and servers that are within that forest. Likewise, the role groups in Exchange 2013
forest B grant permissions only to the mailboxes and servers within that forest.
The figure also shows that the Custom role group A is created in each forest. Even though they were created with
the same name, each is its own separate entity. In fact, as the figure shows, each can be assigned different
management roles in their respective forests. Custom role group A in Exchange 2013 forest A is assigned the
Mailbox Search and Message Tracking roles while Custom role group A in Exchange 2013 forest B is assigned the
Mailbox Search and Retention Management roles.
Finally, management scopes created in each forest are also bound by the forest. Server scopes created in each
forest can only contain the servers that are members of that forest. Server scope A can contain only servers within
Exchange 2013 forest A while Server scope B can contain only servers that are within Exchange 2013 forest B.
Similarly, the recipient scope in Exchange 2013 forest B can only contain mailboxes that are within Exchange 2013
forest B.
RBAC and forest scope boundary relationship

Cross-boundary permissions
The permissions granted by RBAC only allow users to view or modify Exchange objects within a specific forest.
However, you can grant permissions to view and modify Exchange objects in a forest to users outside of that
forest. By using cross-boundary permissions, you can centralize Exchange management accounts in a single forest
rather than having to authenticate against each individual forest to perform tasks.

NOTE
The permissions that are granted to a user outside of an Exchange forest still apply only to that specific Exchange forest. For
example, if a user in a foreign forest is a member of the Organization Management linked role group that's located in
ForestA, the user can manage only the Exchange objects contained within ForestA. A user must be made a member of linked
role groups in each Exchange forest to be granted permissions to manage each forest.

Cross-boundary permissions also enable you to apply role assignment policies to the mailboxes of users who
have mailboxes in an Exchange forest, but have user accounts that reside in an accounts forest. Exchange 2013
supports cross-boundary permission using linked role groups and linked mailboxes, which are discussed in the
following sections.

Administrative permissions
Administrative permissions are granted cross forest boundaries by the use of linked role groups and linked
mailboxes.
A linked role group is created in the Exchange 2013 organization and is linked to a USG across the forest
boundary in the foreign forest. The USG the linked role group is linked to can be any of the following:
A dedicated USG for the specific use of the linked role group
A USG that's linked to by linked role groups in multiple Exchange 2013 forests
A role group USG in another Exchange 2013 forest
A USG associated with an Exchange Server 2007 administrative role or Exchange 2010 role group
The USG that a linked role group is linked to must be in another forest. You can't link a linked role group to a USG
in the same forest.
The following figure shows that USGs in an accounts forest can be associated with role groups in one or more
Exchange 2013 resource forests. The members of the USGs in the accounts forest effectively become members of
the role groups through the USGs.
Linked role groups associated with USGs in a separate forest

When you create a linked role group, you assign roles to the linked role group in the Exchange 2013 forest. The
assignments that associate the roles to the linked role group can include management scopes, if necessary. These
scopes are confined to the forest in which the linked role group is created.
Membership of the linked role group is managed by adding and removing members to and from the USG in the
foreign forest. When you add members to this USG, they are granted the permissions assigned to the linked role
group in the Exchange 2013 forest. If you've linked multiple linked role groups with the same USG, the members
of that USG are granted the permissions assigned to each linked role group in each Exchange 2013 forest.
You can't manage the membership of a linked role group from the Exchange 2013 forest.
A second method to assign administrative permissions across forest boundaries is through the use of linked
mailboxes. For users in an accounts forest to use an Exchange 2013 deployment in a separate Exchange 2013
resource forest, you must configure linked mailboxes for each user. Linked mailboxes can be added as members to
role groups within the Exchange 2013 forest. When a linked mailbox becomes a member of a role group, that
linked mailbox, and in turn the user in the accounts forest associated with the linked mailbox, is granted the
permissions provided by the role group.
The following figure shows the relationship between users in an accounts forest, the linked mailboxes associated
with them, and the role groups in which they're members.
Users in an accounts forest associated with linked mailboxes that are members of role groups

Linked role groups and linked mailboxes both have advantages and disadvantages when used to assign
administrative permission across forest boundaries. The following table describes some of them.
Linked role group and linked mailbox advantages and disadvantages
LINKED ROLE GROUPS OR LINKED
MAILBOXES ADVANTAGE DISADVANTAGE

Linked role groups You can associate multiple linked A regular role group can't be
role groups from multiple Exchange converted to a linked role group.
2013 forests to a single USG in an You must manually create linked
accounts forest or other Exchange role groups to replace each regular
resource forest. This enables you to role group that has the permissions
administer complex Exchange forest you want to grant across a forest
topologies through a small set of boundary. For more information,
USGs in a single forest. see Configure cross-boundary
permissions.
 LINKED ROLE GROUPS OR LINKED
MAILBOXES ADVANTAGE DISADVANTAGE

Linked mailboxes Linked mailboxes allow you to use If you grant permissions in multiple
the existing role groups within the Exchange 2013 forests using linked
Exchange forest. Linked mailboxes mailboxes linked to a single user in
are added as members to the an accounts forest, you must
existing role groups just like regular modify the role group membership
mailboxes, USGs, and users in the in each Exchange 2013 forest if you
same Exchange forest. want to modify the permissions
granted to the user.

We recommend that you use linked role groups to grant permission across forest boundaries if you plan on
having multiple Exchange resource forests.

End-user permissions
End-user permissions are assigned to individual mailboxes using role assignment policies. When Exchange 2013
is installed in a resource forest, linked mailboxes are created in the resource forest and are associated with user
accounts in the accounts forest.
When a linked mailbox is created, it's assigned to a default role assignment policy just like a regular mailbox. The
role assignment policy determines which end-user permissions are granted to the mailbox. These permissions
enable users to view and modify settings related to the following, and other, features:
End-user profile information
End-user voicemail
End-user distribution membership and ownership
When a role assignment policy is assigned to a linked mailbox, the user in the accounts forest associated with the
linked mailbox is granted permissions to manage the features available to that user. The permissions apply to only
the resources in the Exchange forest where the linked mailbox is located. The following figure shows the
relationship between the end user in the accounts forest, its associated linked mailbox, and the role assignment
policy assigned to the linked mailbox. Additionally, a linked mailbox associated with an administrative user in the
accounts forest can be associated with multiple role groups in addition to a role assignment policy.
Users in an accounts forest associated with linked mailboxes that are each assigned a role assignment
policy

Configure cross-boundary permissions

To configure cross-boundary permissions in a multiple-forest topology, you must create linked role groups for
each of the role groups you want to link to USGs in a foreign forest. This means that you must create a linked role
group for each built-in role group. You need to:
1. Create a USG in the foreign forest for each linked role group to be created. Add members to this USG that
you want to grant permissions to.
2. Create a linked role group for each built-in role group. The following happens when the linked role group is
created:
The same roles that are assigned to the built-in role group are assigned to the new linked role group.
The linked role group is associated with the USG in the foreign forest.
3. Create linked role groups for any custom role groups you created.
4. Optionally assign custom scopes to the new linked role groups.
For detailed information about how to perform these steps, see the following topics:
Create linked role groups that mirror built-in role groups
Manage linked role groups
Manage role groups
If you need to change the USG that a linked role group is associated with, see Manage linked role groups.
When a linked mailbox is created, it's automatically assigned to a role assignment policy. You can change the role
assignment policy that's assigned to the linked mailbox or change the role assignment policy that's assigned to
mailboxes by default when they're created. For more information, see the following topics:
Change the assignment policy on a mailbox
Manage role assignment policies
 Understanding split permissions
6/14/2019 • 19 minutes to read • Edit Online

Applies to: Exchange Server 2013

Organizations that separate the management of Microsoft Exchange Server 2013 objects and Active Directory
objects use what's called a split permissions model. Split permissions enable organizations to assign specific
permissions and related tasks to specific groups within the organization. This separation of work helps to
maintain standards and workflows, and helps to control change in the organization.
The highest level of split permissions is the separation of Exchange management and Active Directory
management. Many organizations have two groups: administrators that manage the organization's Exchange
infrastructure, including servers and recipients, and administrators that manage the Active Directory
infrastructure. This is an important separation for many organizations because the Active Directory
infrastructure often spans many locations, domains, services, applications, and even Active Directory forests.
Active Directory administrators must ensure that changes made to Active Directory don't negatively impact any
other services. As a result, typically only a small group of administrators is allowed to manage that
infrastructure.
At the same time, the infrastructure for Exchange, including servers and recipients, can also be complex and
require specialized knowledge. Additionally, Exchange stores extremely confidential information about the
business of the organization. Exchange administrators can potentially access this information. By limiting the
number of Exchange administrators, the organization limits who can make changes to Exchange configuration
and who can access sensitive information.
Split permissions typically make a distinction between the creation of security principals in Active Directory,
such as users and security groups, and the subsequent configuration of those objects. This helps to reduce the
chance of unauthorized access to the network by controlling who can create objects that grant access to it. Most
often only Active Directory administrators can create security principals while other administrators, such as
Exchange administrators, can manage specific attributes on existing Active Directory objects.
To support the varying needs to separate the management of Exchange and Active Directory, Exchange 2013
lets you choose whether you want a shared permissions model or a split permissions model. Exchange 2013
offers two types of split permissions models: RBAC and Active Directory. Exchange 2013 defaults to a shared
permissions model.

Explanation of Role Based Access Control and Active Directory

To understand split permissions, you need to understand how the Role Based Access Control (RBAC )
permissions model in Exchange 2013 works with Active Directory. The RBAC model controls who can perform
what actions, and on which objects those actions can be performed. For more information about the various
components of RBAC that are discussed in this topic, see Understanding Role Based Access Control.
In Exchange 2013, all tasks that are performed on Exchange objects must be done through the Exchange
Management Shell or the Exchange admin center (EAC ) interface. Both of these management tools use RBAC
to authorize all tasks that are performed.
RBAC is a component that exists on every server running Exchange 2013. RBAC checks whether the user
performing an action is authorized to do so:
If the user isn't authorized to perform the action, RBAC doesn't allow the action to proceed.
If the user is authorized to perform the action, RBAC checks whether the user is authorized to perform
 the action against the specific object being requested:
If the user is authorized, RBAC allows the action to proceed.
If the user isn't authorized, RBAC doesn't allow the action to proceed.
If RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted Subsystem
and not the user's context. The Exchange Trusted Subsystem is a highly privileged universal security group
(USG ) that has read/write access to every Exchange-related object in the Exchange organization. It's also a
member of the Administrators local security group and the Exchange Windows Permissions USG, which
enables Exchange to create and manage Active Directory objects.

WARNING
Don't make any manual changes to the membership of the Exchange Trusted Subsystem security group. Also, don't add
it to or remove it from object access control lists (ACLs). By making changes to the Exchange Trusted Subsystem USG
yourself, you could cause irreparable damage to your Exchange organization.

It's important to understand that it doesn't matter what Active Directory permissions a user has when using the
Exchange management tools. If the user is authorized, via RBAC, to perform an action in the Exchange
management tools, the user can perform the action regardless of his or her Active Directory permissions.
Conversely, if a user is an Enterprise Admin in Active Directory but isn't authorized to perform an action, such
as creating a mailbox, in the Exchange management tools, the action won't succeed because the user doesn't
have the required permissions according to RBAC.

IMPORTANT
Although the RBAC permissions model doesn't apply to the Active Directory Users and Computers management tool,
Active Directory Users and Computers can't manage the Exchange configuration. So although a user may have access to
modify some attributes on Active Directory objects, such as the display name of a user, the user must use the Exchange
management tools, and therefore must be authorized by RBAC, to manage Exchange attributes.

Shared permissions
The shared permissions model is the default model for Exchange 2013. You don't need to change anything if
this is the permissions model you want to use. This model doesn't separate the management of Exchange and
Active Directory objects from within the Exchange management tools. It allows administrators using the
Exchange management tools to create security principals in Active Directory.
The following table shows the roles that enable the creation of security principals in Exchange and the
management role groups they're assigned to by default.
Security principal management roles
MANAGEMENT ROLE ROLE GROUP

Mail Recipient Creation role Organization Management

Recipient Management

Security Group Creation and Membership role Organization Management

Only role groups, users, or USGs that are assigned the Mail Recipient Creation role can create security
principals such as Active Directory users. By default, the Organization Management and Recipient Management
role groups are assigned this role. Therefore members of these role groups can create security principals.
Only role groups, users, or USGs that are assigned the Security Group Creation and Membership role can
create security groups or manage their memberships. By default, only the Organization Management role
group is assigned this role. Therefore only members of the Organization Management role group can create or
manage the membership of security groups.
You can assign the Mail Recipient Creation role and the Security Group Creation and Membership role to other
role groups, users, or USGs if you want other users to be able to create security principals.
To enable the management of existing security principals in Exchange 2013, the Mail Recipients role is assigned
to the Organization Management and Recipient Management role groups by default. Only role groups, users,
or USGs that are assigned the Mail Recipients role can manage existing security principals. If you want other
role groups, users, or USGs to be able to manage existing security principals, you must assign the Mail
Recipients role to them.
For more information about how to add roles to role groups, users, or USGs, see the following topics:
Manage role groups
Add a role to a user or USG
If you switched to a split permissions model and want to change back to a shared permissions model, see
Configure Exchange 2013 for shared permissions.

Split permissions
If your organization separates Exchange management and Active Directory management, you need to
configure Exchange to support the split permissions model. When configured correctly, only the administrators
who you want to create security principals, such as Active Directory administrators, will be able to do so and
only Exchange administrators will be able to modify the Exchange attributes on existing security principals. This
splitting of permissions also falls roughly along the lines of the domain and configuration partitions in Active
Directory. Partitions are also called naming contexts. The domain partition stores the users, groups, and other
objects for a specific domain. The configuration partition stores the forest-wide configuration information for
the services that used Active Directory, such as Exchange. Data that's stored in the domain partition is typically
managed by Active Directory administrators, although objects may contain Exchange-specific attributes that
can be managed by Exchange administrators. Data that's stored in the configuration partition is managed by
the administrators for each respective service that stores data in this partition. For Exchange, this is typically
Exchange administrators.
Exchange 2013 supports the two following types of split permissions:
RBAC split permissions: Permissions to create security principals in the Active Directory domain
partition are controlled by RBAC. Only Exchange servers, services, and those who are members of the
appropriate role groups can create security principals.
Active Directory split permissions: Permissions to create security principals in the Active Directory
domain partition are completely removed from any Exchange user, service, or server. No option is
provided in RBAC to create security principals. Creation of security principals in Active Directory must be
performed using Active Directory management tools.

IMPORTANT
Although Active Directory split permissions can be enabled or disabled by running Setup on a computer that has
Exchange 2013 installed, Active Directory split permissions configuration applies to both Exchange 2013 and
Exchange 2010 servers. It doesn't, however, have any impact on Microsoft Exchange Server 2007 servers.
If your organization chooses to use a split permissions model instead of shared permissions, we recommend
that you use the RBAC split permissions model. The RBAC split permissions model provides significantly more
flexibility while providing the nearly same administration separation as Active Directory split permissions, with
the exception that Exchange servers and services can create security principals in the RBAC split permissions
model.
You're asked whether you want to enable Active Directory split permissions during Setup. If you choose to
enable Active Directory split permissions, you can only change to shared permissions or RBAC split
permissions by rerunning Setup and disabling Active Directory split permissions. This choice applies to all
Exchange 2010 and Exchange 2013 servers in the organization.
The following sections describe RBAC and Active Directory split permissions in more detail.

RBAC split permissions

The RBAC security model modifies the default management role assignments to separate who can create
security principals in the Active Directory domain partition from those who administer the Exchange
organization data in the Active Directory configuration partition. Security principals, such as users with
mailboxes and distribution groups, can be created by administrators who are members of the Mail Recipient
Creation and Security Group Creation and Membership roles. These permissions remain separate from the
permissions required to create security principals outside of the Exchange management tools. Exchange
administrators who aren't assigned the Mail Recipient Creation or Security Group Creation and Membership
roles can still modify Exchange-related attributes on security principals. Active Directory administrators also
have the option of using the Exchange management tools to create Active Directory security principals.
Exchange servers and the Exchange Trusted Subsystem also have permissions to create security principals in
Active Directory on behalf of users and third-party programs that integrate with RBAC.
RBAC split permissions is a good choice for your organization if the following are true:
Your organization doesn't require that security principal creation be performed using only Active
Directory management tools and only by users who are assigned specific Active Directory permissions.
Your organization allows services, such as Exchange servers, to create security principals.
You want to simplify the process required to create mailboxes, mail-enabled users, distribution groups,
and role groups by allowing their creation from within the Exchange management tools.
You want to manage the membership of distribution groups and role groups within the Exchange
management tools.
You have third-party programs that require that Exchange servers be able to create security principals on
their behalf.
If your organization requires a complete separation of Exchange and Active Directory administration where no
Active Directory administration can be performed using Exchange management tools or by Exchange services,
see the Active Directory Split Permissions section later in this topic.
Switching from shared permissions to RBAC split permissions is a manual process where you remove the
permissions required to create security principals from the role groups that are granted them by default. The
following table shows the roles that enable the creation of security principals in Exchange and the management
role groups they're assigned to by default.
Security principal management roles
 MANAGEMENT ROLE ROLE GROUP

Mail Recipient Creation role Organization Management

Recipient Management

Security Group Creation and Membership role Organization Management

By default, members of the Organization Management and Recipient Management role groups can create
security principals. You must transfer the ability to create security principals from the built-in role groups to a
new role group that you create.
To configure RBAC split permissions, you must do the following:
1. Disable Active Directory split permissions if it's enabled.
2. Create a role group, which will contain the Active Directory administrators that will be able to create
security principals.
3. Create regular and delegating role assignments between the Mail Recipient Creation role and the new
role group.
4. Create regular and delegating role assignments between the Security Group Creation and Membership
role and the new role group.
5. Remove the regular and delegating management role assignments between the Mail Recipient Creation
role and the Organization Management and Recipient Management role groups.
6. Remove the regular and delegating role assignments between the Security Group Creation and
Membership role and the Organization Management role group.
After doing this, only members of the new role group that you create will be able to create security principals,
such as mailboxes. The new group will only be able to create the objects. It won't be able to configure the
Exchange attributes on the new object. An Active Directory administrator, who is a member of the new group,
will need to create the object, and then an Exchange administrator will need to configure the Exchange
attributes on the object. Exchange administrators won't be able to use the following cmdlets:
New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
Exchange administrators will, however, be able to create and manage Exchange-specific objects, such as
transport rules, distribution groups, and so on and manage Exchange-related attributes on any object.
Additionally, the associated features in the EAC and Outlook Web App, such as the New Mailbox Wizard, will
also no longer be available or will generate an error if you try to use them.
If you want the new role group to also be able to manage the Exchange attributes on the new object, the Mail
Recipients role also needs to be assigned to the new role group.
For more information about configuring a split permissions model, see Configure Exchange 2013 for split
permissions.

Active Directory split permissions

With Active Directory split permissions, the creation of security principals in the Active Directory domain
partition, such as mailboxes and distribution groups, must be performed using Active Directory management
tools. Several changes are made to the permissions granted to the Exchange Trusted Subsystem and Exchange
servers to limit what Exchange administrators and servers can do. The following changes in functionality occur
when you enable Active Directory split permissions:
Creation of mailboxes, mail-enabled users, distribution groups, and other security principals is removed
from the Exchange management tools.
Adding and removing distribution group members can't be done from the Exchange management tools.
All permissions granted to the Exchange Trusted Subsystem and Exchange servers to create security
principals are removed.
Exchange servers and the Exchange management tools can only modify the Exchange attributes of
existing security principals in Active Directory.
For example, to create a mailbox with Active Directory split permissions enabled, a user must first be created
using Active Directory tools by a user with the required Active Directory permissions. Then, the user can be
mailbox-enabled using the Exchange management tools. Only the Exchange-related attributes of the mailbox
can be modified by Exchange administrators using the Exchange management tools.
Active Directory split permissions is a good choice for your organization if the following are true:
Your organization requires that security principals be created using only the Active Directory
management tools or only by users who are granted specific permissions in Active Directory.
You want to completely separate the ability to create security principals from those who manage the
Exchange organization.
You want to perform all distribution group management, including creation of distribution groups and
adding and removing members of those groups, using Active Directory management tools.
You don't want Exchange servers, or third-party programs that use Exchange on their behalf, to create
security principals.

IMPORTANT
Switching to Active Directory split permissions is a choice that you can make when you install Exchange 2013 either by
using the Setup wizard or by using the ActiveDirectorySplitPermissions parameter while running setup.exe from the
command line. You can also enable or disable Active Directory split permissions after you've installed Exchange 2013 by
rerunning setup.exe from the command line. To enable Active Directory split permissions, set the
ActiveDirectorySplitPermissions parameter to true . To disable it, set it to false . You must always specify the
PrepareAD switch along with the ActiveDirectorySplitPermissions parameter.
If you have multiple domains within the same forest, you must also either specify the PrepareAllDomains switch when
you apply Active Directory split permissions or run setup with the PrepareDomain switch in each domain. If you choose
to run setup with the PrepareDomain switch in each domain rather than use the PrepareAllDomains switch, you must
prepare every domain that contains Exchange servers, mail-enabled objects, or global catalog servers that could be
accessed by an Exchange server.
 IMPORTANT
You can't enable Active Directory split permissions if you've installed Exchange 2010 or Exchange 2013 on a domain
controller.
After you enable or disable Active Directory split permissions, we recommend that you restart the Exchange 2010 and
Exchange 2013 servers in your organization to force them to pick up the new Active Directory access token with the
updated permissions.

Exchange 2013 achieves Active Directory split permissions by removing permissions and membership from the
Exchange Windows Permissions security group. This security group, in shared permissions and RBAC split
permissions, is given permissions to many non-Exchange objects and attributes throughout Active Directory.
By removing the permissions and membership to this security group, Exchange administrators and services are
prevented from creating or modifying those non-Exchange Active Directory objects.
For a list of changes that occur to the Exchange Windows Permissions security group and other Exchange
components when you enable or disable Active Directory split permissions, see the following table.

NOTE
Role assignments to role groups that enable Exchange administrators to create security principals are removed when
Active Directory split permissions is enabled. This is done to remove access to cmdlets that would otherwise generate an
error when they're run because they don't have permissions to create the associated Active Directory object.

Active Directory split permissions changes

ACTION CHANGES MADE BY EXCHANGE
ACTION CHANGES MADE BY EXCHANGE

Enable Active Directory split permissions during first The following happens when you enable Active
Exchange 2013 server installation Directory split permissions either through the Setup
wizard or by running setup.exe with the
/PrepareAD and
/ActiveDirectorySplitPermissions:true
parameters:
An organizational unit (OU) called Microsoft
Exchange Protected Groups is created.
The Exchange Windows Permissions security
group is created in the Microsoft Exchange
Protected Groups OU.
The Exchange Trusted Subsystem security
group isn't added to the Exchange Windows
Permissions security group.
Creation of non-delegating management role
assignments to management roles with the
following management role types is skipped:
MailRecipientCreation

SecurityGroupCreationandMembership

Access control entries (ACEs) that would have

been assigned to the Exchange Windows
Permissions security group aren't added to the
Active Directory domain object.
If you run setup with the PrepareAllDomains or
PrepareDomain switch, the following happens in each
child domain that's prepared:
All ACEs assigned to the Exchange Windows
Permissions security group are removed from
the domain object.
ACEs are set in each domain with the exception
of any ACEs assigned to the Exchange
Windows Permissions security group.
ACTION CHANGES MADE BY EXCHANGE

Switch from shared permissions or RBAC split The following happens when you run the setup.exe
permissions to Active Directory split permissions command with the /PrepareAD and
/ActiveDirectorySplitPermissions:true
parameters:
An OU called Microsoft Exchange Protected
Groups is created.
The Exchange Windows Permissions security
group is moved to the Microsoft Exchange
Protected Groups OU.
The Exchange Trusted Subsystem security
group is removed from the Exchange Windows
Permissions security group.
Any non-delegating role assignments to
management roles with the following role types
are removed:
MailRecipientCreation

SecurityGroupCreationandMembership

All ACEs assigned to the Exchange Windows

Permissions security group are removed from
the domain object.
If you run setup with either the PrepareAllDomains or
PrepareDomain switch, the following happens in each
child domain that's prepared:
All ACEs assigned to the Exchange Windows
Permissions security group are removed from
the domain object.
ACEs are set in each domain with the exception
of any ACEs assigned to the Exchange
Windows Permissions security group.
 ACTION CHANGES MADE BY EXCHANGE

Switch from Active Directory split permissions to shared The following happens when you run the setup.exe
permissions or RBAC split permissions command with the /PrepareAD and
/ActiveDirectorySplitPermissions:false
parameters:
The Exchange Windows Permissions security
group is moved to the Microsoft Exchange
Security Groups OU.
The Microsoft Exchange Protected Groups
OU is removed.
The Exchange Trusted Subsystems security
group is added to the Exchange Windows
Permissions security group.
ACEs are added to the domain object for the
Exchange Windows Permissions security
group.
If you run setup with either the PrepareAllDomains or
PrepareDomain switch, the following happens in each
child domain that's prepared:
ACEs are added to the domain object for the
Exchange Windows Permissions security
group.
ACEs are set in each domain including ACEs
assigned to the Exchange Windows
Permissions security group.
Role assignments to the Mail Recipient Creation and
Security Group Creation and Membership roles aren't
automatically created when switching from Active
Directory split to shared permissions. If delegating role
assignments were customized prior to Active Directory
split permissions being enabled, those customizations
are left intact. To create role assignments between these
roles and the Organization Management role group, see
Configure Exchange 2013 for shared permissions.

After you enable Active Directory split permissions, the following cmdlets are no longer available:
New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
After you enable Active Directory split permissions, the following cmdlets are accessible but you cannot use
them to create distribution groups or modify distribution group membership:
Add-DistributionGroupMember
 New-DistributionGroup
Remove-DistributionGroup
Remove-DistributionGroupMember
Update-DistributionGroupMember
Some cmdlets, although still available, may offer only limited functionality when used with Active Directory
split permissions. This is because they may allow you to configure recipient objects that are in the domain
Active Directory partition and Exchange configuration objects that are in the configuration Active Directory
partition. They may also allow you to configure Exchange-related attributes on objects stored in the domain
partition. Attempts to use the cmdlets to create objects, or modify non-Exchange-related attributes on objects,
in the domain partition will result in an error. For example, the Add-ADPermission cmdlet will return an error
if you attempt to add permissions to a mailbox. However, the Add-ADPermission cmdlet will succeed if you
configure permissions on a Receive connector. This is because a mailbox is stored in the domain partition while
Receive connectors are stored in the configuration partition.
Additionally, the associated features in the Exchange admin center and Outlook Web App, such as the New
Mailbox wizard, will also no longer be available or will generate an error if you try to use them.
Exchange administrators will, however, be able to create and manage Exchange-specific objects, such as
transport rules, and so on.
For more information about configuring an Active Directory split permissions model, see Configure Exchange
2013 for split permissions.
 Understanding permissions coexistence with
Exchange 2007 and Exchange 2010
5/28/2019 • 17 minutes to read • Edit Online

Applies to: Exchange Server 2013

When you install Microsoft Exchange Server 2013 into an existing Microsoft Exchange Server 2010 or Microsoft
Exchange Server 2007 organization, you need to understand how permissions will work in the new organization.
Read the section below that applies to your organization.
Installing Exchange 2013 into an existing Exchange 2010 organization
Installing Exchange 2013 into an existing Exchange 2007 organization

Installing Exchange 2013 into an existing Exchange 2010 organization

Exchange 2013 uses the same Role Based Access Control (RBAC ) permissions model that's used in Exchange
2010. When you install Exchange 2013 into an existing Exchange 2010 organization, the same management role
groups, management roles, and management scopes apply to both Exchange 2013 and Exchange 2010 servers
and recipients. Members of role groups, or users assigned to roles, can administer any Exchange 2013 or Exchange
2013 server or recipient that's included in the scope of the role group or role. If you don't use scopes in your
organization and you want the members of your existing role groups to manage Exchange 2010 and Exchange
2013 servers and recipients, you don't have to do anything else. Those administrators will be able to manage
Exchange 2013 servers and recipients that are added to the organization. If you need a reminder on how
permissions work in Exchange 2010 and Exchange 2013, see Permissions.
In the new organization, you might want to separate the administration of Exchange 2010 and Exchange 2013
servers and recipients. The group of administrators responsible for administering Exchange 2010 servers and
recipients may not be allowed to administer Exchange 2013 servers and recipients, and vice versa. In this case, you
can use management scopes to define the servers and recipients each group of administrators should be allowed
to manage. After you create the scopes you want, you can then copy existing role groups, add the administrators
who should be a member of each, and then add the scopes to those role groups. When you're done, the members
of each role group will only be able to administer the servers and recipients that match their respective scopes.
For more information about role groups, scopes, copying role groups, and adding scopes to role groups, see the
following topics:
Manage role groups
Create a regular or exclusive scope
Understanding management role groups
Understanding management role scopes

Installing Exchange 2013 into an existing Exchange 2007 organization

Exchange 2013 includes Role Based Access Control (RBAC ) permissions that replace the Active Directory access
control entry (ACE )-based authorization model used in Microsoft Exchange Server 2007. RBAC is the
authorization mechanism used for most of the management of Exchange 2013. This mechanism includes the
following management areas:
 Exchange Management Shell
Exchange admin center (EAC )
Exchange Web Services
For more information about how to plan coexistence between Exchange 2013 and Exchange 2007, see Upgrade
from Exchange 2007 to Exchange 2013.
Looking for management tasks related to permissions? Check out Permissions.

Exchange 2013 permissions

The Exchange 2013 RBAC permissions model consists of management role groups assigned one of several
management roles. Management roles contain permissions that enable administrators to perform tasks in the
Exchange organization. Administrators are added as members of the role groups and are granted all the
permissions that the roles provide. The following table provides an example of the role groups, some of the roles
assigned to role groups, and a description of the kind of user who might be a member of the role group.
Examples of role groups and roles in Exchange 2013
MANAGEMENT ROLE GROUP MANAGEMENT ROLES MEMBERS OF THIS ROLE GROUP

Organization Management The following roles are some of the Users who manage the entire
roles assigned to this role group: Exchange 2013 organization should
be members of this role group.
Address Lists With some exceptions, members of
Exchange Servers this role group can manage nearly
any aspect of the Exchange 2013
Journaling organization.
Mail Recipients By default, the user account used to
Public Folders prepare Active Directory for
Exchange 2013 is a member of this
role group.
For more information about this
role group and for a complete list of
roles assigned to this role group,
see Organization Management.

View Only Organization The following roles are assigned to Users who view the configuration of
Management this role group: the entire Exchange 2013
organization should be members of
Monitoring this role group. These users must
View-Only Configuration be able to view server configuration
and recipient information, and
View-Only Recipients perform monitoring functions
without the ability to change
organization or recipient
configuration.
For more information about this
role group, see View-only
Organization Management.
 MANAGEMENT ROLE GROUP MANAGEMENT ROLES MEMBERS OF THIS ROLE GROUP

Recipient Management The following roles are assigned to Users who manage recipients such
this role group: as mailboxes, contacts, and
distribution groups in the Exchange
Distribution Groups 2013 organization should be
Mail Enabled Public Folders members of this role group. These
users can create recipients, modify
Mail Recipient Creation or delete existing recipients, or
Mail Recipients move mailboxes.

Message Tracking For more information about this

role group and for a complete list of
Migration roles assigned to this role group,
see Recipient Management.
Move Mailboxes
Recipient Policies

Server Management The following roles are some of the Users who manage Exchange server
roles assigned to this role group: configuration such as Receive
connectors, certificates, databases,
Databases and virtual directories should be
Exchange Connectors members of this role group. These
users can modify Exchange server
Exchange Servers configuration, create databases, and
Receive Connectors restart and manipulate transport
queues.
Transport Queues
For more information about this
role group and for a complete list of
roles assigned to this role group,
see Server Management.

Discovery Management The following roles are assigned to Users who perform searches of
this role group: mailboxes to support legal
proceedings or to configure legal
Legal Hold holds should be members of this
Mailbox Search role group.
This is an example of a role group
that might contain non-Exchange
administrators, such as personnel in
the legal department. Legal
personnel can perform their tasks
without intervention from Exchange
administrators.
For more information about this
role group and for a complete list of
roles assigned to this role group,
see Discovery Management.

This table shows that Exchange 2013 provides a granular level of control over the permissions that you grant to
your administrators. You can choose among 12 role groups in Exchange 2013. For a complete list of role groups
and the permissions that they provide, see Built-in role groups.
Because Exchange 2013 provides many role groups and because further customization is possible by creating role
groups that have different role combinations, the manipulation of access control lists (ACLs) on Active Directory
objects is no longer necessary and has no effect. ACLs are no longer used to apply permissions to individual
administrators or groups in Exchange 2013. All tasks, such as an administrator creating a mailbox or a user
accessing a mailbox, are managed by RBAC. RBAC authorizes the task, and then Exchange performs the task on
behalf of the user if allowed. Exchange performs the task in the Exchange Trusted Subsystem universal security
group (USG ). With some exceptions, all the ACLs on objects in Active Directory that Exchange 2010 has to access
are granted to the Exchange Trusted Subsystem USG. This is a fundamental change from how permissions are
handled in Exchange 2007.
The permissions granted to a user in Active Directory are separate from the permissions granted to the user by
RBAC when that user is using the Exchange 2013 management tools.
For more information about RBAC, see Understanding Role Based Access Control.

Exchange 2007 permissions

The Exchange 2007 administrative model leverages Active Directory forests to define security boundaries. There is
no isolation of security permissions within a specific forest. Forest owners and enterprise administrators can
always gain access to all resources in any domain. In Exchange 2007, you may have to grant enterprise
administrator rights and top-level domain administrator rights on a temporary basis only.
Exchange 2007 provides the following predefined administrator roles:
Exchange Organization Administrator role: This role grants permissions to control all aspects of the
Exchange 2007 organization. Additionally, an administrator who has this role can grant permissions to other
Exchange administrators. This role is granted to the account that you use to install Exchange 2007.
Exchange View-Only Administrator role: This role grants permissions to view Exchange configuration.
However, an administrator who has this role can't modify objects in the Exchange 2007 organization.
Exchange Recipient Administrator role: This role grants permissions to manage e-mail recipients. An
administrator who has this role can modify Exchange-related items for users, groups, contacts, and
distribution groups.
Exchange Server Administrator role: This role grants permissions to manage a specific server. However,
this role doesn't grant permissions to perform actions that have a global impact on the Exchange 2007
organization.
Exchange Public Folder Administrator role: This role was added in Exchange 2007 Service Pack 1**.**
This role grants permissions to manage public folders in the Exchange 2007 organization.
This permissions model uses USGs for all roles except for the Exchange Server Administrator role. When you run
the Exchange 2007 Setup /PrepareAD command, the Setup program creates the USGs in the root domain and
gives a forest-wide scope to the USGs. The USGs are assigned ACLs to manage Exchange objects throughout
Active Directory.
In Exchange 2007, you can separate administrators by assigning them various roles. The permissions are assigned
directly either to the user or to the USG of which the user is a member. Any actions performed by the user are
performed in the context of that user's Active Directory account. The following table lists the Exchange 2007
administrator roles together with their Exchange-related permissions.
Exchange 2007 administrator roles
ADMINISTRATOR ROLE MEMBERS MEMBER OF EXCHANGE PERMISSIONS
 ADMINISTRATOR ROLE MEMBERS MEMBER OF EXCHANGE PERMISSIONS

Exchange Organization The Administrator Exchange Recipient Full control of the

Administrator account or the account Administrator Microsoft Exchange
used to install the first container in Active
Exchange 2007 server Administrators local Directory
group of <server
name>

Exchange View-Only Exchange Recipient Exchange Recipient Read access to the

Administrator Administrators Administrators Microsoft Exchange
container in Active
Exchange Server Exchange Server Directory
Administrators (<server Administrators
name>) Read access to all the
Windows domains that
have Exchange recipients

Exchange Recipient Exchange Organization Exchange View-Only Full control of Exchange

Administrator Administrators Administrators properties on Active
Directory user objects

Exchange Server Exchange Organization Exchange View-Only Full control of Exchange

Administrator Administrators Administrators <server name>
Administrators local
group of <server
name>

Exchange Server Each Exchange 2007 Exchange View-Only Special

computer account Administrators

Exchange Public Folder Exchange Organization Exchange View-Only Full control to manage
Administrator Administrators Administrators all public folders
(granted the Create top
level public folder
extended right)

If you need to make more granular permission assignments, you can modify the ACLs on individual Exchange
2007 objects, such as address lists or databases. You must add the user or security group of which the user is a
member directly to the ACL. Then, the actions are performed in the context of the particular user.
For more information about how to manage permissions in Exchange 2007, see Configuring Permissions in
Exchange Server 2007.

Exchange 2013 and Exchange 2007 coexistence permissions

Because the permissions models for Exchange 2013 and for Exchange 2007 differ, Exchange 2013 permission
assignments are separate from Exchange 2007 permission assignments. This is true even if both versions of
Exchange are installed in the same forest. Without additional configuration, Exchange 2013 administrators don't
have the required permissions to manage Exchange 2007-based servers, and Exchange 2007 administrators don't
have the required permissions to manage Exchange 2013-based servers. You should consider the following
questions:
Do you want to grant Exchange 2013 administrators access to manage Exchange 2007 servers?
 Do you want to grant Exchange 2007 administrators access to manage Exchange 2013 servers?
Do you want to customize Exchange 2013 permissions so that they match any customizations that have
been made to Exchange 2007 ACLs?

Granting Exchange 2013 permissions to Exchange 2007 administrators

If you want Exchange 2007 administrators to administer Exchange 2013 servers, the Exchange 2007
administrators must be added as members of one or more Exchange 2013 role groups. You can add either users or
USGs to role groups. The permissions granted to the role groups are then applied to the users or the USGs that
you add as members.

IMPORTANT
If you use domain local or global Active Directory security groups, you must change them to USGs if you want to add them
as members of an Exchange 2013 role group. Exchange 2013 supports only USGs.

The following table describes the mapping between Exchange 2007 administrator roles and Exchange 2013 role
groups.
Exchange 2007 administrator roles and Exchange 2010 role groups
EXCHANGE 2007 ADMINISTRATOR ROLE EXCHANGE 2013 ROLE GROUP

Exchange Organization Administrator Organization Management

Exchange Recipient Administrator Recipient Management

Exchange Server Administrator Server Management

Exchange View-Only Administrator View Only Organization Management

Exchange Server No equivalent role group in Exchange 2013

(For more information about how to create custom role
groups, see Manage role groups.)

Exchange Public Folder Administrator Public Folder Management

If all your Exchange 2007 administrators are members of one of the Exchange 2007 administrative roles, you can
add the members of each of the administrative groups to their equivalent Exchange 2013 role group. For example,
if you want to give all Exchange 2007 organization administrators full access to Exchange 2013 objects, add the
Exchange Organization Administrators USG to the Organization Management role group.
For more information about how to add users and USGs to role groups, see Manage role group members.
If you modify ACLs on Exchange 2007 objects to grant more granular permissions to Exchange 2007
administrators, and if you want to assign similar permissions to Exchange 2013 servers to those administrators,
follow these steps:
1. Review the ACL customizations that have been made to the Exchange 2007 objects, and locate the
administrators who have been granted permissions to each object.
2. Categorize each Exchange 2007 object. For example, determine whether the object is a database, server, or
recipient object.
3. Map the objects to the corresponding Exchange 2013 role group. For a list of built-in role groups, see Built-
in role groups.
4. Add the USGs or users for each kind of object to the corresponding Exchange 2013 role groups. For more
information about how to add users and USGs to role groups, see Manage role group members.
After you complete these steps, the Exchange 2007 administrators will be members of the specific role group that's
mapped to the appropriate Exchange 2013 objects. The Exchange 2007 administrators can use the Exchange 2013
management tools to manage the Exchange 2013 servers and recipients.

IMPORTANT
In general, Exchange 2007 servers and recipients must be managed by using Exchange 2007 management tools, and
Exchange 2013 servers and recipients must be managed by using Exchange 2013 management tools.

If the built-in role groups don't provide the specific set of permissions that you want to grant to some
administrators, you can create custom role groups. When you create a custom role group, you can select which
roles to add to it. You can define the specific features you want members of the role group to manage. For example,
if you want administrators to manage only distribution groups, you can create a custom role group, and then select
only the Distribution Groups role. After you do this, members of that custom role group can manage only
distribution groups. For more information about how to create custom role groups, see Manage role groups.
If you assign selective permissions to certain Exchange 2007 objects (for example, you allow administrators to
administer only specific databases), and if you want to apply the same configuration to your Exchange 2013
servers, see "Re-Creating Exchange 2007 ACL Customization Using Management Scopes in Exchange 2013" later
in this topic.

Granting Exchange 2007 permissions to Exchange 2013 administrators

If you want Exchange 2013 administrators to administer Exchange 2007 servers, add the Exchange 2013
administrators to the USGs or the security group that corresponds to the particular Exchange 2007 administrator
role. Alternatively, if you have customized ACL settings, add the administrators to the appropriate ACLs. Role
groups are USGs, so role groups can be added directly to Exchange 2007 administrator role USGs.
After you finish, the Exchange 2013 administrators will be members of the appropriate Exchange 2007
administrator role or roles. The Exchange 2013 administrators can use the Exchange 2007 management tools to
manage Exchange 2007 servers and recipients.

Re-Creating Exchange 2007 ACL customization using management

scopes in Exchange 2013
In Exchange 2007, when you want to restrict who can administer a specific mailbox store, administer specific users,
or control which mailbox store mailboxes are created on, you must modify the ACLs on the objects you want to
restrict. Exchange 2013 provides the same capabilities, but without having to modify any ACLs. It does this by
using management scopes, which are a component of RBAC.
Management scopes provide built-in scopes and custom scopes to define the objects that administrators can
manage. By applying management scopes, you can define which recipients can be administered, which mailbox
databases mailboxes can be created on, and which recipients or servers should be administered by a small group
of administrators and by no one else.
You can create the following types of management scopes:
 Predefined relative: Predefined relative scopes are included in Exchange 2013. You can control what a
user sees and what a user modifies. For example, predefined relative scopes can control whether users see
only information about themselves or information about the entire organization.
Recipient: Recipient scopes control which recipients an administrator can create, modify, or delete. These
selections can be based on an organizational unit (OU ), a recipient filter, or both. Recipient filters specify the
criteria that a recipient must match to be included in the scope. For example, you might create a recipient
filter scope that includes all users in a certain location or in a specific department. You can even combine
OUs and recipient filters to match only users who are within a specific OU and who report to a specific
manager.
Server: Server scopes control which servers an administrator can manage. You can specify either server
lists or server filters. For server lists, you define a static list of servers that can be managed. Server filters
work in the same manner as recipient filters in that you can specify the criteria that have to be matched. For
example, you might create a server scope that matches all servers within a particular Active Directory site.
Database: Database scopes control which databases an administrator can manage. They can also control
which databases mailboxes can be created on or which databases mailboxes can be moved to. Like server
scopes, they can be defined as lists or as filters. For example, you might create a list or filter that allows
administrators to create mailboxes on or move mailboxes to specific mailbox databases managed by a
specific subsidiary.
Exclusive: Recipient, server, and database scopes can also be created as exclusive scopes. Exclusive scopes
work in the same manner as deny access ACEs in ACLs. If anything matches an exclusive scope, only the
administrators assigned an exclusive scope can manage that object. This is true even if another scope that
isn't exclusive matches the same object. This is especially useful when you might want only a few, highly
trusted individuals to be able to manage an executive's mailbox. Even if another regular recipient scope is
broader and includes the executive's mailbox in the scope, the administrators assigned the broader, regular
recipient scope won't be able to manage that executive's mailbox unless they are also assigned the exclusive
scope.
Management scopes are used with management roles, management role assignments, and management role
groups to control who can manage what objects and in what manner they can manage those objects. For more
information, see the following topics:
Understanding management role scopes
Understanding exclusive scopes
Understanding management role assignments
Understanding management role groups
Understanding management roles
To create the same permissions model in Exchange 2013 using management scopes that you might have defined
using customized ACLs, you must inventory the ACLs that you've customized, and then create management
scopes that match them. You can use the filterable properties available on recipient, server, and database objects to
create management scopes that include the objects to which you want each management scope to control access.
For more information about the properties that you can use with management scope filters, see Understanding
management role scope filters.
For more information about how to create management scopes, see Create a regular or exclusive scope.
 Manage role groups
6/14/2019 • 23 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic shows you how to add, remove, copy, and view management role
groups in Microsoft Exchange Server 2013. It also shows you how to add,
remove, and list management roles on role groups and how to change
management scopes and delegates on role groups. For more information
about role groups in Exchange 2013, see Understanding management role
groups.
For additional management tasks related to role groups, see Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 to 10 minutes
You need to be assigned permissions before you can perform this
procedure or procedures. To see what permissions you need, see the
"Role groups" entry in the Role management permissions topic.
For information about keyboard shortcuts that may apply to the
procedures in this topic, see Keyboard shortcuts in the Exchange admin
center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange
Server.

Create a role group

If you want to customize the permissions that you can assign to a group of
users, create a new custom management role group.

Use the EAC to create a role group

1. In the Exchange admin center (EAC), navigate to Permissions > Admin
Roles and then click Add .
2. In the New role group window, provide a name for the new role group.
3. You can either select the roles that you want to be assigned to the role
group and the members you want to be added to the role group now, or
you can do this at another time.
4. Select the write scope that you want to apply to the new role group.
5. Click Save to create the role group.

Use the Shell to create a role group

To create a role group, see the Examples section in New-RoleGroup.

How do you know this worked?

To verify that you have successfully created a role group, do the following:
1. In the EAC, navigate to Permissions > Admin Roles.
2. Verify that the new role group appears in the role group list and then
select it.
3. Verify that members, assigned roles, and scope that you specified on the
new role group are listed in the role group details pane.

Copy a role group

Use the EAC to copy a role group
If you have a role group that contains the permissions you want to grant to
users, but you want to apply a different management scope, or remove or add
one or two management roles without having to add all the other roles
manually, you can copy the existing role group.

IMPORTANT
You can't use the EAC to copy a role group if you've used the Exchange Management
Shell to configure multiple management role scopes or exclusive scopes on the role
group. If you've configured multiple scopes or exclusive scopes on the role group,
you must use the Shell procedures later in this topic to copy the role group. For
more information about management role scopes, see Understanding management
role scopes.
1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you want to copy and then click Copy .
3. In the New role group window, provide a name for the new role group.
4. Review the roles that have been copied to the new role group. Add or
remove roles as necessary.
5. Review the write scope, and change it as necessary.
6. Review the members that have been copied to the new role group. Add
or remove members as necessary.
7. Click Save to create the role group.

Use the Shell to copy a role group with no scope

1. Store the role group that you want to copy in a variable using the
following syntax.

$RoleGroup = Get-RoleGroup <name of role group to copy>

2. Create the new role group, and also add members to the role group and
specify who can delegate the new role group to other users, using the
following syntax.

New-RoleGroup <name of new role group> -Roles $RoleGroup.Roles -

Members <member1, member2, member3...> -ManagedBy <user1, user2,
user3...>

For example, the following commands copy the Organization Management

role group, and name the new role group "Limited Organization Management".
It adds the members Isabelle, Carter, and Lukas and can be delegated by Jenny
and Katie.

$RoleGroup = Get-RoleGroup "Organization Management"

New-RoleGroup "Limited Organization Management" -Roles $RoleGroup.Roles -
Members Isabelle, Carter, Lukas -ManagedBy Jenny, Katie

After the new role group is created, you can add or remove roles, change the
scope of role assignments on the role, and more.
For detailed syntax and parameter information, see Get-RoleGroup and New-
RoleGroup.

Use the Shell to copy a role group with a custom

scope
1. Store the role group that you want to copy in a variable using the
following syntax.

$RoleGroup = Get-RoleGroup <name of role group to copy>

2. Create the new role group with a custom scope using the following
syntax.

New-RoleGroup <name of new role group> -Roles $RoleGroup.Roles -

CustomRecipientWriteScope <recipient scope name> -
CustomConfigWriteScope <configuraiton scope name>

For example, the following commands copy the Organization Management

role group and create a new role group called Vancouver Organization
Management with the Vancouver Users recipient scope and Vancouver Servers
configuration scope.

$RoleGroup = Get-RoleGroup "Organization Management"

New-RoleGroup "Vancouver Organization Management" -Roles $RoleGroup.Roles -
CustomRecipientWriteScope "Vancouver Users" -CustomConfigWriteScope
"Vancouver Servers"

You can also add members to the role group when you create it by using the
Members parameter as shown in Use the Shell to copy a role group with no
scope earlier in this topic. For more information about management scopes,
see Understanding management role scopes.
After the new role group is created, you can add or remove roles, change the
scope of role assignments on the role, and perform other tasks.
For detailed syntax and parameter information, see Get-RoleGroup and New-
RoleGroup.

Use the Shell to copy a role group with an OU

scope
1. Store the role group that you want to copy in a variable using the
following syntax.

$RoleGroup = Get-RoleGroup <name of role group to copy>

2. Create the new role group with a custom scope using the following
syntax.

New-RoleGroup <name of new role group> -Roles $RoleGroup.Roles -

RecipientOrganizationalUnitScope <OU name>

For example, the following commands copy the Recipient Management role
group and create a new role group called Toronto Recipient Management that
allows management of only users in the Toronto Users OU.

$RoleGroup = Get-RoleGroup "Recipient Management"

New-RoleGroup "Toronto Recipient Management" -Roles $RoleGroup.Roles -
RecipientOrganizationalUnitScope "contoso.com/Toronto Users"

You can also add members to the role group when you create it by using the
Members parameter as shown in Use the Shell to copy a role group with no
scope earlier in this topic. For more information about management scopes,
see Understanding management role scopes.
After the new role group is created, you can add or remove roles, change the
scope of role assignments on the role, and more.
For detailed syntax and parameter information, see Get-RoleGroup and New-
RoleGroup.

How do you know this worked?

To verify that you have successfully copied a role group, do the following:
1. In the EAC, navigate to Permissions > Admin Roles.
2. Verify that the copied role group appears in the role group list, and then
select it.
3. Verify that members, assigned roles, and scope that you specified on the
copied role group are listed in the role group details pane.

Remove a role group

If you no longer need a role group you created, you can remove it. When you
remove a role group, the management role assignments between the role
group and the management roles are deleted. The management roles aren't
deleted. If a user depended on the role group for access to a feature, the user
will no longer have access to the feature. You can't remove built-in role groups.

Use the EAC to remove a role group

1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you want to remove and then click Delete .
3. Verify that you want to remove the selected role group, and if so,
respond Yes to the warning.

Use the Shell to remove a role group

To remove a role group, see the Examples section in Remove-RoleGroup.

View role groups

You can view either a list of role groups or the detailed information about a
specific role group that exists in your organization.

Use the EAC to view a list of role groups and role

group details
1. In the EAC, navigate to Permissions > Admin Roles. All of the role
groups in your organization are listed here.
2. Select a role group to view the members, assigned roles, and scope that
are configured on the role group.

Use the Shell to view a list of role groups and role

group details
To view a list of role groups, see the Examples section in Get-RoleGroup.

Add a role to a role group

Adding a management role to a role group is the best and simplest way to
grant permissions to a group of administrators or specialist users. If you want
to give users that are members of a role group the ability to manage a feature,
you add the management role that manages the feature to the role group. After
the role is added, the members of the role group are granted the permissions
provided by the role.

Use the EAC to add a management role to a role

group
IMPORTANT
You can't use the EAC to add roles to a role group if you've used the Shell to
configure multiple management role scopes or exclusive scopes on the role group. If
you've configured multiple scopes or exclusive scopes on the role group, you must
use the Shell procedures later in this topic to add roles to the role group. For more
information about management role scopes, see Understanding management role
scopes.

1. In the EAC, navigate to Permissions > Admin Roles.

2. Select the role group you want to add a role to, and then click Edit .
3. In the Roles section, select the roles you want to add to the role group.
4. When you've finished adding roles to the role group, click Save.

Use the Shell to create a role assignment with no

scope
You can create a role assignment with no scope between a role and a role
group. When you do this, the implicit read and implicit write scopes of the role
apply.
Use the following syntax to assign a role without any scope to a role group. A
role assignment name is created automatically if you don't specify one.

New-ManagementRoleAssignment -SecurityGroup <role group name> -Role <role

name>

This example assigns the Transport Rules management role to the Seattle
Compliance role group.

New-ManagementRoleAssignment -SecurityGroup "Seattle Compliance" -Role

"Transport Rules"

For detailed syntax and parameter information, see New-

ManagementRoleAssignment.

Use the Shell to create a role assignment with a

predefined scope
If a predefined scope meets your business requirements, you can apply that
scope to the role assignment rather than create a new one. For a list of
predefined scopes and their descriptions, see Understanding management role
scopes.
For more information about role assignments, see Understanding
management role assignments.
Use the following syntax to assign a role to a role group with a predefined
scope. A role assignment name is created automatically if you don't specify one.

New-ManagementRoleAssignment -SecurityGroup <role group name> -Role <role

name> -RecipientRelativeWriteScope < MyGAL | MyDistributionGroups |
Organization | Self >

This example assigns the Message Tracking role to the Enterprise Support role
group and applies the Organization predefined scope.

New-ManagementRoleAssignment -SecurityGroup "Enterprise Support" -Role

"Message Tracking" -RecipientRelativeWriteScope Organization

For detailed syntax and parameter information, see New-

ManagementRoleAssignment.

Use the Shell to create a role assignment with a

recipient filter-based scope
If you created a recipient filter-based scope, you need to include the scope in
the command used to assign the role to a role group by using the
CustomRecipientWriteScope parameter.
You can also include a configuration write scope when you create a role
assignment that has a recipient write scope.
For more information about role assignments and scopes, see the following
topics:
Understanding management role assignments
Understanding management role scopes
Use the following syntax to assign a role to a role group with a recipient filter-
based scope. A role assignment name is created automatically if you don't
specify one.

New-ManagementRoleAssignment -SecurityGroup <role group name> -Role <role

name> -CustomRecipientWriteScope <role scope name>

This example assigns the Message Tracking role to the Seattle Recipient
Admins role group and applies the Seattle Recipients scope.

New-ManagementRoleAssignment -SecurityGroup "Seattle Recipient Admins" -

Role "Message Tracking" -CustomRecipientWriteScope "Seattle Recipients"

For detailed syntax and parameter information, see New-

ManagementRoleAssignment.

Use the Shell to create a role assignment with a

configuration scope
If you created a server or database configuration filter or list-based scope, you
need to include the scope in the command used to assign the role to a role
group by using the CustomConfigWriteScope parameter.
You can also include a recipient write scope when you create a role assignment
that has a configuration write scope.
For more information about role assignments and management scopes, see the
following topics:
Understanding management role assignments
Understanding management role scopes
Use the following syntax to assign a role to a role group with a configuration
scope. A role assignment name is created automatically if you don't specify one.

New-ManagementRoleAssignment -SecurityGroup <role group name> -Role <role

name> -CustomConfigWriteScope <role scope name>

This example assigns the Databases role to the Seattle Server Admins role
group and applies the Seattle Servers scope.

New-ManagementRoleAssignment -SecurityGroup "Seattle Server Admins" -Role

"Databases" -CustomConfigWriteScope "Seattle Servers"

For detailed syntax and parameter information, see New-

ManagementRoleAssignment.

Use the Shell to create a role assignment with an

OU scope
If you want to scope a role's write scope to an OU, you can specify the OU in
the RecipientOrganizationalUnitScope parameter directly.
For more information about role assignments and management scopes, see the
following topics:
Understanding management role assignments
Understanding management role scopes
Use the following command to assign a role to a role group and restrict the
write scope of a role to a specific OU. A role assignment name is created
automatically if you don't specify one.

New-ManagementRoleAssignment -SecurityGroup <role group name> -Role <role

name> -RecipientOrganizationalUnitScope <OU>

This example assigns the Mail Recipients role to the Seattle Recipient Admins
role group and scopes the assignment to the Sales\Users OU in the
Contoso.com domain.

New-ManagementRoleAssignment -SecurityGroup "Seattle Recipient Admins" -

Role "Mail Recipients" -RecipientOrganizationalUnitScope
contoso.com/sales/users

For detailed syntax and parameter information, see New-

ManagementRoleAssignment.

How do you know this worked?

To verify that you have successfully added roles to a role group, do the
following:
1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you added roles to. In the role group details pane,
verify that the roles that you added are listed.

Remove a role from a role group

Removing a role from a management role group is the best and simplest way
to revoke permissions granted to a group of administrators or specialist users.
If you don't want administrators or specialist users to have permissions to
manage a feature, you remove the management role from the management
role group that manages the permissions. After the role is removed, the
members of the role group will no longer have permissions to manage the
feature.

NOTE
Some role groups, such as the Organization Management role group, restrict what
roles can be removed from a role group. For more information, see Understanding
management role groups.
If an administrator is a member of another role group that contains management
roles that grants permissions to manage the feature, you need to either remove the
administrator from the other role groups, or remove the role that grants permissions
to manage the feature from the other role groups.

Use the EAC to remove a management role from

a role group
IMPORTANT
You can't use the EAC to remove roles from a role group if you've used the Shell to
configure multiple scopes or exclusive scopes on the role group. If you've configured
multiple scopes or exclusive scopes on the role group, you must use the Shell
procedures later in this topic to remove roles from the role group. For more
information about management role scopes, see Understanding management role
scopes.

1. In the EAC, navigate to Permissions > Admin Roles.

2. Select the role group you want to remove a role from, and then click
Edit .
3. In the Roles section, select the roles you want to remove from the role
group.
4. When you've finished removing roles from the role group, click Save.

Use the Shell to remove a role from a role group

You can remove roles from role groups by retrieving the associated
management role assignment using the Get-ManagementRoleAssignment
cmdlet and then piping the role assignment returned to the Remove-
ManagementRoleAssignment cmdlet. Unless you want to remove both
delegating and regular role assignments at the same time, specify the
Delegating parameter to specify whether you want to remove regular or
delegating role assignments.
For more information about regular and delegating role assignments, see
Understanding management role assignments.
This procedure uses pipelining. For more information about pipelining, see
Pipelining.
To remove a role from a role group, use the following syntax.

Get-ManagementRoleAssignment -RoleAssignee <role group name> -Role <role

name> -Delegating <$true | $false> | Remove-ManagementRoleAssignment

This example removes the Distribution Groups role, which enables

administrators to manage distribution groups, from the Seattle Recipient
Administrators role group. Because we want to remove the role assignment
that provides permissions to manage distribution groups, the Delegating
parameter is set to $False , which returns only regular role assignments.

Get-ManagementRoleAssignment -RoleAssignee "Seattle Recipient

Administrators" -Role "Distribution Groups" -Delegating $false | Remove-
ManagementRoleAssignment

For detailed syntax and parameter information, see Remove-

ManagementRoleAssignment.

How do you know this worked?

To verify that you have successfully removed roles from a role group, do the
following:
1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you removed roles from. In the role group details
pane, verify that the roles that you removed are no longer listed.

Change a role group's scope

The management role assignments between a role group and a role contain
management scopes, which determine what objects are made available to
members of that role group. By changing the write scope on a role group, you
can change what objects are made available to role group members to create,
change, or remove. You can't change the read scope on a role group.
Exchange 2013 includes scopes that are applied by default to role assignments
when no custom scopes are created. If you want to use a custom scope with a
role assignment on a role group, you must create one first. For more
information about creating custom scopes, which is an advanced task, see
Create a regular or exclusive scope.
For more information about management role scopes and assignments in
Exchange 2013, see the following topics:
Understanding management role scopes
Understanding management role assignments

Use the EAC to change the scope on a role group

When you use the EAC to change the scope on a role group, you're actually
changing the scope on all the role assignments between the role group and
each of the management roles assigned to the role group. If you want to
change the scope on specific role assignments, you must use the Shell
procedures later in this topic.

IMPORTANT
You can't use the EAC to manage scopes on role assignments between roles and a
role group if you've used the Shell to configure multiple scopes or exclusive scopes
on those role assignments. If you've configured multiple scopes or exclusive scopes
on those role assignments, you must use the Shell procedures later in this topic to
manage scopes. For more information about management role scopes, see
Understanding management role scopes.

1. In the EAC, navigate to Permissions > Admin Roles.

2. Select the role group you want to change the scope on, and then click
Edit .
3. Select one of the two following Write scope options:
A write scope from the drop-down box, where you can select
either the default write scope or a custom write scope.
Organizational unit: Select this option and provide an
organizational unit (OU) if you want to scope this role group to
an OU.
4. Click Save to save the changes to the role group.

Use the Shell to change the scope of all role

assignments on a role group at the same time
Role assignments between the role group and the roles assigned to it can use
the implicit scope obtained from the roles themselves, the same custom scope,
or different custom scopes. For more information about role assignments, see
Understanding management role assignments.
The scopes on the role assignments are managed using the Set-
ManagementRoleAssignment cmdlet. You can't manage scopes using the
Set-RoleGroup cmdlet.
To change the scope of all the role assignments between a role group and a set
of management roles at the same time, you need to first retrieve the role
assignments on the role group, and then set the new scope on each of the
assignments. You can do this by using the Get-
ManagementRoleAssignment cmdlet to retrieve the role assignments, and
then pipe them to the Set-ManagementRoleAssignment cmdlet.
This procedure uses the concepts of pipelining and the WhatIf switch. For more
information, see the following topics:
Pipelining
WhatIf, Confirm, and ValidateOnly switches
To set the scope on all of the role assignments on a role group at the same
time, use the following syntax.
 Get-ManagementRoleAssignment -RoleAssignee <name of role group> | Set-
ManagementRoleAssignment -CustomRecipientWriteScope <recipient scope name>
-CustomConfigWriteScope <configuration scope name> -
RecipientRelativeScopeWriteScope < MyDistributionGroups | Organization |
Self> -ExclusiveRecipientWriteScope <exclusive recipient scope name> -
ExclusiveConfigWriteScope <exclusive configuration scope name> -
RecipientOrganizationalUnitScope <organizational unit>

You use only the parameters you need to configure the scope you want to use.
For example, if you want to change the recipient scope for all role assignments
on the Sales Recipient Management role group to Direct Sales Employees, use
the following command.

Get-ManagementRoleAssignment -RoleAssignee "Sales Recipient Management" |

Set-ManagementRoleAssignment -CustomRecipientWriteScope "Direct Sales
Employees"

NOTE
You can use the WhatIf switch to verify that only the role assignments you want to
change are changed. Run the preceding command with the WhatIf switch to verify
the results, and then remove the WhatIf switch to apply the changes.

For more information about changing management role assignments, see

Change a role assignment.
For detailed syntax and parameter information, see Get-
ManagementRoleAssignment.

Use the Shell to change the scope of individual

role assignments on a role group
Role assignments between the role group and the roles assigned to it can use
the implicit scope obtained from the roles themselves, the same custom scope,
or different custom scopes. For more information about role assignments, see
Understanding management role assignments.
The scopes on the role assignments are managed using the Set-
ManagementRoleAssignment cmdlet. You can't manage scopes using the
Set-RoleGroup cmdlet.
This procedure uses the concepts of pipelining and the Format-List cmdlet. For
more information, see the following topics:
Pipelining
Working with command output
To change the scope on a role assignment between a role group and a
management role, you first find the name of the role assignment, and then set
the scope on the role assignment.
1. To find the names of all the role assignments on a role group, use the
following command. By piping the management role assignments to the
Format-List cmdlet, you can view the full name of the assignment.

Get-ManagementRoleAssignment -RoleAssignee <role group name> |

Format-List Name

2. Find the name of the role assignment you want to change. Use the name
of the role assignment in the next step.
3. To set the scope on an individual assignment, use the following syntax.

Set-ManagementRoleAssignment <role assignment name> -

CustomRecipientWriteScope <recipient scope name> -
CustomConfigWriteScope <configuration scope name> -
RecipientRelativeScopeWriteScope < MyDistributionGroups |
Organization | Self> -ExclusiveRecipientWriteScope <exclusive
recipient scope name> -ExclusiveConfigWriteScope <exclusive
configuration scope name> -RecipientOrganizationalUnitScope
<organizational unit>

You use only the parameters you need to configure the scope you want to use.
For example, if you want to change the recipient scope for the Mail
Recipients_Sales Recipient Management role assignment to All Sales
Employees, use the following command.

Set-ManagementRoleAssignment "Mail Recipients_Sales Recipient Management" -

CustomRecipientWriteScope "All Sales Employees"

For more information about changing management role assignments, see

Change a role assignment.
For detailed syntax and parameter information, see Set-
ManagementRoleAssignment.
How do you know this worked?
To verify that you have successfully changed the scope of a role assignment on
a role group, do the following:
If you used the EAC to configure the scope on the role group, do the
following:
1. In the EAC, navigate to Permissions> Admin Roles. All the role
groups in your organization are listed here.
2. Select a role group to view the scope that's configured on the role
group.
If you used the Shell to configure the scope on the role group, do the
following:
1. Run the following command in the Shell.

Get-ManagementRoleAssignment -RoleAssignee <role group name> |

Format-Table *WriteScope

2. Verify that the write scope on the role assignments has been
changed to the scope you specified.

Add or remove a role group delegate

Role group delegates are users or universal security groups (USGs) that can
add or remove members from a role group or change the properties of a role
group. By adding or removing role group delegates, you can control who is
allowed to manage a role group.

IMPORTANT
After you add a delegate to a role group, the role group can only be managed by the
delegates on the role group, or by users who are assigned, either directly or
indirectly, the Role Management management role.
If a user is assigned, either directly or indirectly, the Role Management role and isn't
added as a delegate of the role group, the user must use the
BypassSecurityGroupManagerCheck switch on the Add-RoleGroupMember,
Remove-RoleGroupMember, Update-RoleGroupMember, and Set-RoleGroup
cmdlets to manage a role group.

NOTE
You can't use the EAC to add a delegate to a role group.

Use the Shell to add a delegate to a role group

To change the list of delegates on a role group, you use the ManagedBy
parameter on the Set-RoleGroup cmdlet. The ManagedBy parameter
overwrites the entire delegate list on the role group. If you want to add
delegates to the role group rather than replace the entire list of delegates, use
the following steps:
1. Store the role group in a variable using the following command.

$RoleGroup = Get-RoleGroup <role group name>

2. Add the delegate to the role group stored in the variable using the
following command.

$RoleGroup.ManagedBy += (Get-User <user to add>).Identity

NOTE
Use the Get-Group cmdlet if you want to add a USG.

3. Repeat Step 2 for each delegate you want to add.

4. Apply the new list of delegates to the actual role group using the
following command.

Set-RoleGroup <role group name> -ManagedBy $RoleGroup.ManagedBy

This example adds the user David Strome as a delegate on the Organization
Management role group.

$RoleGroup = Get-RoleGroup "Organization Management"

$RoleGroup.ManagedBy += (Get-User "David Strome").Identity
Set-RoleGroup "Organization Management" -ManagedBy $RoleGroup.ManagedBy
For detailed syntax and parameter information, see Set-RoleGroup.

Use the Shell to remove a delegate from a role

group
To change the list of delegates on a role group, you use the ManagedBy
parameter on the Set-RoleGroup cmdlet. The ManagedBy parameter
overwrites the entire delegate list on the role group. If you want to remove
delegates from the role group rather than replace the entire list of delegates,
use the following steps:
1. Store the role group in a variable using the following command.

$RoleGroup = Get-RoleGroup <role group name>

2. Remove the delegate from the role group stored in the variable using
the following command.

$RoleGroup.ManagedBy -= (Get-User <user to remove>).Identity

NOTE
Use the Get-Group cmdlet if you want to remove a USG.

3. Repeat Step 2 for each delegate you want to remove.

4. Apply the new list of delegates to the actual role group using the
following command.

Set-RoleGroup <role group name> -ManagedBy $RoleGroup.ManagedBy

This example removes the user David Strome as a delegate on the

Organization Management role group.

$RoleGroup = Get-RoleGroup "Organization Management"

$RoleGroup.ManagedBy -= (Get-User "David Strome").Identity
Set-RoleGroup "Organization Management" -ManagedBy $RoleGroup.ManagedBy

For detailed syntax and parameter information, see Set-RoleGroup.

How do you know this worked?

To verify that you have successfully changed the delegate list on a role group,
do the following:
1. In the Shell, run the following command.

Get-RoleGroup <role group name> | Format-List ManagedBy

2. Verify that the delegates listed on the ManagedBy property include only
the delegates that should be able to manage the role group.
 Manage role group members
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic shows you how to add, remove and view members of a management role group in
Microsoft Exchange Server 2013. For more information about role groups in Exchange 2013, see
Understanding management role groups.
For additional management tasks related to role groups, see Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures.
To see what permissions you need, see the "Role groups" entry in the Role management
permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see
Keyboard shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Add members to a role group

To give a user the permissions that are granted by a role group, you need to add the user, or a
universal security group (USG ), or another role group that the user is a member of, as a member of
the role group.

Use the EAC to add members to a role group

1. In the Exchange admin center (EAC ), navigate to Permissions > Admin Roles.
2. Select the role group you want to add members to, and then click Edit .
3. In the Members section, click Add .
4. Select the users, USGs, or other role groups you want to add to the role group, click Add, and
then click OK.
5. Click Save to save the changes to the role group.

Use the Shell to add members to a role group

To add a role group member, see the Examples section in Add-RoleGroupMember.
To add multiple role group members or to replace the role group membership entirely, see the
Examples section in Update-RoleGroupMember.
How do you know this worked?
To verify that you have successfully added one or more members to a role group, do the following:
1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you added members to.
3. In the role group details pane, verify that the members you added are listed.

Remove members from a role group

To remove the permissions granted by a role group from a user, you need to remove the user, or the
universal security group (USG ) the user is a member of, from the role group's membership.

Use the EAC to remove members from a role group

1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you want to remove members from, and then click Edit .
3. In the Members section, select the members you want to remove, click Remove , and then
click Save.

Use the Shell to remove members from a role group

To remove a role group member, see the Examples section in Remove-RoleGroupMember.
To remove multiple role group members or to replace the role group membership entirely, see the
Examples section in Update-RoleGroupMember.

How do you know this worked?

To verify that you have successfully removed one or more members to a role group, do the
following:
1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you removed members from.
3. In the role group details pane, verify that the members you removed are no longer listed.

View the members of a role group

The members of a role group are granted the permissions provided by the management roles
assigned to the role group. You can view the members of a role group to see which users, universal
security groups (USG ), or other role groups are granted permissions by the role group you specify.

Use the EAC to view the members of a role group

1. In the EAC, navigate to Permissions > Admin Roles.
2. Select the role group you want to view the members of.
3. In the role group details pane, view the members in the role group details pane.

Use the Shell to view the members of a role group

To view the members of a role group, see the "Examples" section in Get-RoleGroupMember.
 Manage linked role groups
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use a linked management role group to enable members of a universal security group (USG ) in a foreign
Active Directory forest to manage a Microsoft Exchange Server 2013 organization in a resource Active Directory
forest. By associating a USG in a foreign forest with a linked role group, the members of that USG are granted
the permissions provided by the management roles assigned to the linked role group. For more information
about linked role groups, see Understanding management role groups.
To create and configure linked role groups, you need to use the New-RoleGroup and Set-RoleGroup cmdlets.
For detailed syntax and parameter information, see the following topics:
New -RoleGroup
Set-RoleGroup
For additional management tasks related to role groups, see Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 to 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role groups" entry in the Role management permissions topic.
You can't use the Exchange admin center (EAC ) to create or configure linked role groups. You must use the
Exchange Management Shell.
At a minimum, configuring a linked role group requires that a one-way trust is established between the
resource Active Directory forest in which the linked role group will reside, and the foreign Active Directory
forest where the users or USGs reside. The resource forest must trust the foreign forest.
You must have the following information about the foreign Active Directory forest:
Credentials: You must have a user name and password that can access the foreign Active Directory
forest. This information is used with the LinkedCredential parameter on the New-RoleGroup and
Set-RoleGroup cmdlets.
Domain controller: You must have the fully qualified domain name (FQDN ) of an Active Directory
domain controller in the foreign Active Directory forest. This information is used with the
LinkedDomainController parameter on the New-RoleGroup and Set-RoleGroup cmdlets.
Foreign USG: You must have the full name of a USG in the foreign Active Directory forest that
contains the members you want to associate with the linked role group. This information is used
with the LinkedForeignGroup parameter on the New-RoleGroup and Set-RoleGroup cmdlet.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Create a linked role group
Use the Shell to create a linked role group with no scope
To create a linked role group and assign management roles to the linked role group, do the following:
1. Store the foreign Active Directory forest credentials in a variable.

$ForeignCredential = Get-Credential

2. Create the linked role group using the following syntax.

New-RoleGroup <role group name> -LinkedForeignGroup <name of foreign USG> -LinkedDomainController

<FQDN of foreign Active Directory domain controller> -LinkedCredential $ForeignCredential -Roles
<role1, role2, role3...>

3. Add or remove members to or from the foreign USG using Active Directory Users and Computers on a
computer in the foreign Active Directory forest.
This example does the following:
Retrieves the credentials for the users.contoso.com foreign Active Directory forest. These credentials are
used to connect to the DC01.users.contoso.com domain controller in the foreign forest.
Creates a linked role group called Compliance Role Group in the resource forest where Exchange 2013 is
installed.
Links the new role group to the Compliance Administrators USG in the users.contoso.com foreign Active
Directory forest.
Assigns the Transport Rules and Journaling management roles to the new linked role group.

$ForeignCredential = Get-Credential

New-RoleGroup "Compliance Role Group" -LinkedForeignGroup "Compliance Administrators" -LinkedDomainController

DC01.users.contoso.com -LinkedCredential $ForeignCredential -Roles "Transport Rules", "Journaling"

Use the Shell to create a linked role group with a custom management
scope
You can create linked role groups with custom recipient management scopes, custom configuration management
scopes, or both. To create a linked role group and assign management roles with custom scopes to it, do the
following:
1. Store the foreign Active Directory forest credentials in a variable.

$ForeignCredential = Get-Credential

2. Create the linked role group using the following syntax.

 New-RoleGroup <role group name> -LinkedForeignGroup <name of foreign USG> -LinkedDomainController
<FQDN of foreign Active Directory domain controller> -CustomConfigWriteScope <name of configuration
scope> -CustomRecipientWriteScope <name of recipient scope> -LinkedCredential $ForeignCredential -
Roles <role1, role2, role3...>

3. Add or remove members to or from the foreign USG using Active Directory Users and Computers on a
computer in the foreign Active Directory forest.
This example does the following:
Retrieves the credentials for the users.contoso.com foreign Active Directory forest. These credentials are
used to connect to the DC01.users.contoso.com domain controller in the foreign forest.
Creates a linked role group called Seattle Compliance Role Group in the resource forest where Exchange
2013 is installed.
Links the new role group to the Seattle Compliance Administrators USG in the users.contoso.com foreign
Active Directory forest.
Assigns the Transport Rules and Journaling management roles to the new linked role group with the
Seattle Recipients custom recipient scope.

$ForeignCredential = Get-Credential

New-RoleGroup "Seattle Compliance Role Group" -LinkedForeignGroup "Seattle Compliance Administrators" -

LinkedDomainController DC01.users.contoso.com -LinkedCredential $ForeignCredential -CustomRecipientWriteScope
"Seattle Recipients" -Roles "Transport Rules", "Journaling"

For more information about management scopes, see Understanding management role scopes.

Use the Shell to create a linked role group with an OU scope

You can create linked role groups that use an OU recipient scope. To create a linked role group and assign
management roles to it with an OU scope, do the following:
1. Store the foreign Active Directory forest credentials in a variable.

$ForeignCredential = Get-Credential

2. Create the linked role group using the following syntax.

New-RoleGroup <role group name> -LinkedForeignGroup <name of foreign USG> -LinkedDomainController

<FQDN of foreign Active Directory domain controller> -LinkedCredential $ForeignCredential -
RecipientOrganizationalUnitScope <OU name> -Roles <role1, role2, role3...>

3. Add or remove members to or from the foreign USG using Active Directory Users and Computers on a
computer in the foreign Active Directory forest.
This example does the following:
Retrieves the credentials for the users.contoso.com foreign Active Directory forest. These credentials are
used to connect to the DC01.users.contoso.com domain controller in the foreign forest.
Creates a linked role group called Executives Compliance Role Group in the resource forest where
Exchange 2013 is installed.
 Links the new role group to the Executives Compliance Administrators USG in the users.contoso.com
foreign Active Directory forest.
Assigns the Transport Rules and Journaling management roles to the new linked role group with the OU
recipient scope Executives OU.

$ForeignCredential = Get-Credential

New-RoleGroup "Executives Compliance Role Group" -LinkedForeignGroup "Executives Compliance Administrators" -

LinkedDomainController DC01.users.contoso.com -LinkedCredential $ForeignCredential -
RecipientOrganizationalUnitScope "Executives OU" -Roles "Transport Rules", "Journaling"

For more information about management scopes, see Understanding management role scopes.

Change the foreign USG on a linked role group

Use the Shell to change the foreign USG on a linked role group
To change the foreign USG associated with a linked role group, do the following:
1. Store the foreign Active Directory forest credentials in a variable.

$ForeignCredential = Get-Credential

2. Change the foreign USG on the existing linked role group using the following syntax.

Set-RoleGroup <role group name> -LinkedForeignGroup <name of foreign USG> -LinkedDomainController

<FQDN of foreign Active Directory domain controller> -LinkedCredential $ForeignCredential

This example does the following:

Retrieves the credentials for the users.contoso.com foreign Active Directory forest. These credentials are
used to connect to the DC01.users.contoso.com domain controller in the foreign forest.
Changes the foreign USG on the Compliance Role Group role group to Regulatory Compliance Officers.

$ForeignCredential = Get-Credential

Set-RoleGroup "Compliance Role Group" -LinkedForeignGroup "Regulatory Compliance Officers" -

LinkedDomainController DC01.users.contoso.com -LinkedCredential $ForeignCredential
 Manage role assignment policies
6/14/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

If you want to customize the permissions that you assign to a group of end users, create a new custom
management role assignment policy. The assignment policy you create can be customized to suit your end
user's specific requirements. For more information about assignment policies in Microsoft Exchange Server
2013, see Understanding management role assignment policies.
Looking for other management tasks related to managing permissions? Check out Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Assignment policies" entry in the Role management permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Add an assignment policy

After you've created the new assignment policy, you assign users to it. For more information, see Change the
assignment policy on a mailbox.

Use the EAC to create a new assignment policy

NOTE
You can only create explicit assignment policies using the Exchange admin center (EAC). If you want to create a new
default assignment policy, you must use the Exchange Management Shell. For more information, see the "Use the Shell to
create a default assignment policy" section later in this topic.

1. In the EAC, navigate to Permissions > User Roles and then click Add .
2. In the role assignment policy window, provide a name for the new assignment policy.
3. Select the check box next to the role or roles you want to add to the assignment policy. You can select
multiple roles, including end-user roles you've added. If you select a role that has child roles, the child
roles are automatically selected.
4. Click Save to save the changes to the assignment policy.

Use the Shell to create an explicit assignment policy

To create an explicit assignment policy that can be manually assigned to mailboxes, use the following syntax.

New-RoleAssignmentPolicy <assignment policy name> -Roles <roles to assign>

This example creates the explicit assignment policy Limited Mailbox Configuration and assigns the
MyBaseOptions , MyAddressInformation , and MyDisplayName roles to it.

New-RoleAssignmentPolicy "Limited Mailbox Configuration" -Roles MyBaseOptions, MyAddressInformation,

MyDisplayName

For detailed syntax and parameter information, see New -RoleAssignmentPolicy.

Use the Shell to create a default assignment policy

To create a default assignment policy assigned to new mailboxes, use the following syntax.

New-RoleAssignmentPolicy <assignment policy name> -Roles <roles to assign> -IsDefault

This example creates the default assignment policy Limited Mailbox Configuration and assigns the
MyBaseOptions , MyAddressInformation , and MyDisplayName roles to it.

New-RoleAssignmentPolicy "Limited Mailbox Configuration" -Roles MyBaseOptions, MyAddressInformation,

MyDisplayName -IsDefault

For detailed syntax and parameter information, see New -RoleAssignmentPolicy.

Remove an assignment policy

If you no longer need a management role assignment policy, you can remove it.

What do you need to know before you begin?

All users assigned the assignment policy must be changed to another assignment policy. For more
information about how to change an assignment policy on a mailbox, see Change the assignment policy
on a mailbox.
All the management role assignments between the assignment policy and the assigned management
roles must be removed. For more information about how to remove a role assignment from an
assignment policy, see the Use the Shell to remove a role from an assignment policy section later in this
topic.
If you want to remove a default assignment policy, it must be the last assignment policy in the Exchange
2013 organization.

Use the EAC to remove an assignment policy

1. In the EAC, navigate to Permissions > User Roles.
2. Select the assignment policy you want to remove, and then click Delete .

Use the Shell to remove an assignment policy

To remove an assignment policy, use the following syntax.
 Remove-RoleAssignmentPolicy <role assignment policy>

This example removes the New York Temporary Users assignment policy.

Remove-RoleAssignmentPolicy "New York Temporary Users"

For detailed syntax and parameter information, see Remove-RoleAssignmentPolicy.

View a list of assignment policies or assignment policy details

You can view management role assignment policies in a variety of ways, depending on the information you
want and whether you're using the EAC or the Shell.
In the EAC, you can view the list of assignment policies and the roles assigned to them. In the Shell, you can
view all the assignment policies in your organization, list the mailboxes assigned a specific policy, and more.

Use the EAC to view a list of assignment policies

1. In the EAC, navigate to Permissions > User Roles. All of the assignment policies in the organization are
listed here.
2. To view the details of a specific assignment policy, select the assignment policy you want to view. The
description and the roles assigned to the assignment policy are displayed in the details pane.

Use the Shell to view a list of assignment policies

You can view a list of all the assignment policies in your organization by not specifying any assignment policies
when you run the Get-RoleAssignmentPolicy cmdlet.
This procedure makes use of pipelining and the Format-Table cmdlet. For more information about these
concepts, see the following topics:
Pipelining
Working with command output
To return a list of all assignment policies in your organization, use the following command.

Get-RoleAssignmentPolicy

To return a list of specific properties for all the assignment policies in your organization, you can pipe the
results to the Format-Table cmdlet and specify the properties you want in the list of results. Use the following
syntax.

Get-RoleAssignmentPolicy | Format-Table <property 1>, <property 2...>

This example returns a list of all the assignment policies in your organization and includes the Name and
IsDefault properties.

Get-RoleAssignmentPolicy | Format-Table Name, IsDefault

For detailed syntax and parameter information, see Get-Mailbox or Get-RoleAssignmentPolicy.

Use the Shell to view the details of a single assignment policy
You can view the details of a specific assignment policy by using the Get-RoleAssignmentPolicy cmdlet and
piping the output to the Format-List cmdlet.
This procedure makes use of pipelining and the Format-List cmdlet. For more information about these
concepts, see the following topics:
Pipelining
Working with command output
To view the details of a specific assignment policy, use the following syntax.

Get-RoleAssignmentPolicy <assignment policy name> | Format-List

This example views the details about the Redmond Users - no Text Messaging assignment policy.

Get-RoleAssignmentPolicy "Redmond Users - no Text Messaging" | Format-List

For detailed syntax and parameter information, see Get-Mailbox or Get-RoleAssignmentPolicy.

Use the Shell to find the default assignment policy

You can find the default assignment policy by piping the output of the Get-RoleAssignmentPolicy cmdlet to
the Where cmdlet. With the Where cmdlet, filter the data returned to display only the assignment policy that
has its IsDefault property set to $True .
This procedure makes use of pipelining and the Where cmdlet. For more information about these concepts, see
the following topics:
Pipelining
Working with command output
This example returns the default assignment policy.

Get-RoleAssignmentPolicy | Where {Get-RoleAssignmentPolicy | Where {$_.IsDefault -eq $True}.IsDefault -eq

$True }

For detailed syntax and parameter information, see Get-Mailbox or Get-RoleAssignmentPolicy.

Use the Shell to view mailboxes that are assigned a specific policy
You can find all the mailboxes assigned a specific assignment policy by piping the output of the Get-Mailbox
cmdlet to the Where cmdlet. With the Where cmdlet, filter the data returned to display only the mailboxes that
have their RoleAssignmentPolicy property set to the assignment policy name you specify.
This procedure makes use of pipelining and the Where cmdlet. For more information about these concepts, see
the following topics:
Pipelining
Working with command output
Use the following syntax.
 Get-Mailbox | Where {Get-Mailbox | Where {$_.RoleAssignmentPolicy -Eq "<role assignment
policy>"}.RoleAssignmentPolicy -Eq "<role assignment policy>" }

This example finds all the mailboxes assigned the policy Vancouver End Users.

Get-Mailbox | Where {Get-Mailbox | Where {$_.RoleAssignmentPolicy -Eq "Vancouver End

Users"}.RoleAssignmentPolicy -Eq "Vancouver End Users" }

For detailed syntax and parameter information, see Get-Mailbox or Get-RoleAssignmentPolicy.

Change the default assignment policy

You can change the management role assignment policy assigned to new mailboxes that are created. Changing
the default role assignment policy doesn't change the assignment policy assigned to existing mailboxes. To
change the assignment policy assigned to existing mailboxes, see Change the assignment policy on a mailbox.

NOTE
You can't use the EAC to change the default assignment policy. You need to use the Shell.

Use the Shell to change the default assignment policy

To change the default assignment policy, use the following syntax.

Set-RoleAssignmentPolicy <assignment policy name> -IsDefault

This example sets the Vancouver End Users assignment policy as the default assignment policy.

Set-RoleAssignmentPolicy "Vancouver End Users" -IsDefault

IMPORTANT
New mailboxes are assigned the default assignment policy even if the policy hasn't been assigned management roles.
Mailboxes assigned assignment policies with no assigned management roles can't access any mailbox configuration
features in Microsoft Outlook Web App.

For detailed syntax and parameter information, see Set-RoleAssignmentPolicy.

Add a role to an assignment policy

Use the EAC to add a role to an assignment policy
1. In the EAC, navigate to Permissions > User Roles.
2. Select the assignment policy you want to add one or more roles to, and then click Edit .
3. Select the check box next to the role or roles you want to add to the assignment policy. You can select
multiple roles, including end-user roles you've added. If you select a role that has child roles, the child
roles are automatically selected.
4. Click Save to save the changes to the assignment policy.
Use the Shell to add a role to an assignment policy
To create a management role assignment between a role and an assignment policy, use the following syntax.

New-ManagementRoleAssignment -Name <role assignment name> -Role <role name> -Policy <assignment policy
name>

This example creates the role assignment Seattle Users - Voicemail between the MyVoicemail role and the
Seattle Users assignment policy.

New-ManagementRoleAssignment -Name "Seattle Users - Voicemail" -Role MyVoicemail -Policy "Seattle Users"

For detailed syntax and parameter information, see New -ManagementRoleAssignment.

Remove a role from an assignment policy

If you don't want end users to have permissions to manage certain features of their mailbox or distribution
group, you can remove the management role that grants the permissions from the management role
assignment policy to which the user is assigned. If other users are assigned the same assignment policy, they
also lose the ability to manage that feature.

Use the EAC to remove a role from an assignment policy

1. In the EAC, navigate to Permissions > User Roles.
2. Select the assignment policy you want to remove one or more roles from, and then click Edit .
3. Clear the check box next to the role or roles you want to remove from the assignment policy. If you clear
the check box for a role that has child roles, the check boxes for the child roles are also cleared.
4. Click Save to save the changes to the assignment policy.

Use the Shell to remove a role from an assignment policy

You can remove roles from assignment policies by retrieving the associated management role assignment
using the Get-ManagementRoleAssignment cmdlet and then piping the role assignment returned to the
Remove-ManagementRoleAssignment cmdlet.
For more information about regular and delegating role assignments, see Understanding management role
assignments.
This procedure uses pipelining. For more information about pipelining, see Pipelining.
To remove a role from an assignment policy, use the following syntax.

Get-ManagementRoleAssignment -RoleAssignee <assignment policy name> -Role <role name> | Remove-

ManagementRoleAssignment

This example removes the MyVoicemail management role, which enables users to manage their voice mail
options, from the Seattle Users assignment policy.

Get-ManagementRoleAssignment -RoleAssignee "Seattle Users" -Role MyVoicemail | Remove-

ManagementRoleAssignment
For detailed syntax and parameter information, see Remove-ManagementRoleAssignment.
 Change the assignment policy on a mailbox
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can change the management role assignment policy assigned to a mailbox. When you change a mailbox's
assignment policy, the change takes effect as soon as the user refreshes the connection, such as the next time
they log into their mailbox or open the mailbox options page. For more information about assignment policies in
Microsoft Exchange Server 2013, see Understanding management role assignment policies.
Looking for other management tasks related to permissions? Check out Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role groups" entry in the Role management permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to change the assignment policy on a mailbox

1. In the Exchange admin center (EAC ), navigate to Recipients > Mailboxes.
2. Select the user or resource mailbox you want to change the assignment policy on and then click Edit .
3. Select Mailbox Features.
4. In the Role assignment policy list, select the assignment policy you want to assign to the mailbox and
then click Save.

Use the Shell to change the assignment policy on a mailbox

To change the assignment policy that's assigned to a mailbox, use the following syntax.

Set-Mailbox <mailbox alias or name> -RoleAssignmentPolicy <assignment policy>

This example sets the assignment policy to Unified Messaging Users on the mailbox Brian.

Set-Mailbox Brian -RoleAssignmentPolicy "Unified Messaging Users"

Use the Shell to change the assignment policy on a group of

mailboxes assigned a specific assignment policy
 NOTE
You can't use the EAC to change the assignment policy on a group of mailboxes all at once.

This procedure makes use of pipelining, the Where cmdlet, and the WhatIf parameter. For more information
about these concepts, see the following topics:
Pipelining
Working with command output
WhatIf, Confirm, and ValidateOnly switches
If you want to change the assignment policy for a group of mailboxes that are assigned a specific policy, use the
following syntax.

Get-Mailbox | Where {$_.RoleAssignmentPolicy -Eq "<assignment policy to find>"} | Set-Mailbox -

RoleAssignmentPolicy <assignment policy to set>

This example finds all the mailboxes assigned to the Redmond Users - No Voicemail assignment policy and
changes the assignment policy to Redmond Users - Voicemail Enabled.

Get-Mailbox | Where {$_.RoleAssignmentPolicy -Eq "Redmond Users - No Voicemail"} | Set-Mailbox -

RoleAssignmentPolicy "Redmond Users - Voicemail Enabled"

This example includes the WhatIf parameter so that you can see all the mailboxes that would be changed
without committing any changes.

Get-Mailbox | Where {$_.RoleAssignmentPolicy -Eq "Redmond Users - No Voicemail"} | Set-Mailbox -

RoleAssignmentPolicy "Redmond Users - Voicemail Enabled" -WhatIf

For detailed syntax and parameter information, see Get-Mailbox or Set-Mailbox.

 Create linked role groups that mirror built-in role
groups
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Using linked management role groups in Microsoft Exchange Server 2013, you can link a role group in an
Exchange 2013 resource forest with a universal security group (USG ) in a foreign user forest. This is useful when
you want administrators with accounts in the user forest to manage the servers running Exchange in the resource
forest. For more information about linked role groups, see Understanding management role groups.
By default, Exchange 2013 includes a number of built-in role groups that provide you with permissions to manage
a variety of features and job functions. Each role group is tailored to provide specific permissions for each feature
and job function. However, these role groups can't be linked to USGs in a foreign forest. They can only contain
users and USGs from the local resource forest. Fortunately, it's possible to replicate these built-in role groups
using linked role groups.
You can re-create each built-in role group as a linked role group. All of the management roles and management
scopes assigned to each role group are added to the new linked role group. For more information about
management roles and scopes, see the following topics:
Understanding management roles
Understanding management role scopes
Looking for other management tasks related to role groups? Check out Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role groups" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
Configuring a linked role group requires a one-way trust between the resource Active Directory forest in
which the linked role group will reside, and the foreign Active Directory forest where the users or USGs
reside. The resource forest must trust the foreign forest.
You must have the following information about the foreign Active Directory forest:
Credentials: You must have a user name and password that can access the foreign Active Directory
forest. This information is used with the LinkedCredential parameter on the New-RoleGroup
cmdlet. This information is obtained by running the Get-Credential cmdlet. The format of the user
name is domain\username.
Domain controller: You must have the fully qualified domain name (FQDN ) of an Active Directory
domain controller in the foreign Active Directory forest. This information is used with the
LinkedDomainController parameter on the New-RoleGroup cmdlet.
Foreign USG: You must have the full name of a USG in the foreign Active Directory forest that
contains the members you want to associate with the linked role group. This information is used
 with the LinkedForeignGroup parameter on the New-RoleGroup cmdlet.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to create linked role groups that replicate built-in role
groups
Each of the following sections shows you how to re-create each role group as a linked role group. Complete the
procedures in each section to re-create all of the built-in role groups as linked role groups.

Create the Organization Management linked role group

To re-create the Organization Management role group as a linked role group, you perform a procedure that's
different than the procedure used to re-create other built-in role groups. This is because the Organization
Management role group has delegating role assignments between it and all of the management roles. Re-creating
the delegating role assignments requires an additional step.
1. Create a USG in the foreign forest that will be linked to the Organization Management role group.
2. Store the foreign Active Directory forest credentials in a variable.

$ForeignCredential = Get-Credential

3. Store all of the roles assigned to the Organization Management role group in a variable.

$OrgMgmt = Get-RoleGroup "Organization Management"

4. Create the Organization Management linked role group and add the roles assigned to the built-in
Organization Management role group.

New-RoleGroup "Organization Management - Linked" -LinkedForeignGroup <name of foreign USG> -

LinkedDomainController <FQDN of foreign Active Directory domain controller> -LinkedCredential
$ForeignCredential -Roles $OrgMgmt.Roles

5. Remove all of the regular assignments between the new Organization Management linked role group and
the My* end-user roles.

Get-ManagementRoleAssignment -RoleAssignee "Organization Management - Linked" -Role My* | Remove-

ManagementRoleAssignment

6. Add delegating role assignments between the new Organization Management linked role group and all
management roles.

Get-ManagementRole | New-ManagementRoleAssignment -SecurityGroup "Organization Management - Linked" -

Delegating

This example assumes the following values are used for each parameter:
 LinkedForeignGroup: Organization Management Administrators

LinkedDomainController: DC01.users.contoso.com

Using the preceding values, this example re-creates the Organization Management role group as a linked role
group.

$ForeignCredential = Get-Credential

$OrgMgmt = Get-RoleGroup "Organization Management"

New-RoleGroup "Organization Management - Linked" -LinkedForeignGroup "Organization Management Administrators"
-LinkedDomainController DC01.users.contoso.com -LinkedCredential $ForeignCredential -Roles $OrgMgmt.Roles
Get-ManagementRoleAssignment -RoleAssignee "Organization Management - Linked" -Role My* | Remove-
ManagementRoleAssignment
Get-ManagementRole | New-ManagementRoleAssignment -SecurityGroup "Organization Management - Linked" -
Delegating

Create all other linked role groups

To re-create the built-in role groups (other than the Organization Management role group) as linked role groups,
use the following procedure for each group.
1. Create a USG in the foreign forest for each role group that will be linked to each new role group.
2. Store the foreign Active Directory forest credentials in a variable. You only need to do this once.

$ForeignCredential = Get-Credential

3. Retrieve a list of role groups using the following cmdlet.

Get-RoleGroup

4. For each role group, other than the Organization Management role group, do the following.

$RoleGroup = Get-RoleGroup <name of role group to re-create>

New-RoleGroup "<role group name> - Linked" -LinkedForeignGroup <name of foreign USG> -
LinkedDomainController <FQDN of foreign Active Directory domain controller> -LinkedCredential
$ForeignCredential -Roles $RoleGroup.Roles

5. Repeat the preceding step for each built-in role group you want to re-create as a linked role group.
This example assumes the following values are used for each parameter:
LinkedDomainController: DC01.users.contoso.com

Built-in role groups to be re-created as linked role groups: Recipient Management, Server Management

Foreign group for Recipient Management linked role group: Recipient Management Administrators

Foreign group for Server Management linked role group: Server Management Administrators

Using the preceding values, this example re-creates the Recipient Management and Server Management role
groups as linked role groups.
 $ForeignCredential = Get-Credential

Get-RoleGroup

$RoleGroup = Get-RoleGroup "Recipient Management"

New-RoleGroup "Recipient Management - Linked" -LinkedForeignGroup "Recipient Management Administrators" -
LinkedDomainController DC01.users.contoso.com -LinkedCredential $ForeignCredential -Roles $RoleGroup.Roles
$RoleGroup = Get-RoleGroup "Server Management"
New-RoleGroup "Server Management - Linked" -LinkedForeignGroup "Server Management Administrators" -
LinkedDomainController DC01.users.contoso.com -LinkedCredential $ForeignCredential -Roles $RoleGroup.Roles

Other tasks
After you create linked role groups, you may also want to:
Add members to the foreign USGs using Active Directory Users and Computers in the foreign forest.
Remove members of built-in role groups. For more information, see Manage role group members.
Add, remove, or change the scope of roles on the new linked role groups. For more information, see Manage role
groups.
Create additional linked role groups. For more information, see Manage linked role groups.
 View effective permissions
6/14/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Permissions in Microsoft Exchange Server 2013 are granted using management roles that are assigned to
management role groups, management role assignment policies, universal security groups (USGs), or directly to
users. Users are granted the permissions if they're members of the role groups or USGs, or are assigned role
assignment policies.
Most permissions are granted based on role group membership or the assignment of assignment policies to end
users. Although using role groups and assignment policies makes it easy to grant permissions to large numbers of
users, you may not be aware of who is a member of a role group, or who has been assigned an assignment policy.
This is where the GetEffectiveUsers switch on the Get-ManagementRoleAssignment cmdlet is useful. It shows
you what users are granted the permissions given by a management role through the role groups, assignment
policies, and USGs that are assigned to them.
The GetEffectiveUsers switch is used with the Get-ManagementRoleAssignment cmdlet when the Role
parameter is used. By specifying this switch with a particular role, the Get-ManagementRoleAssignment cmdlet
examines all the role assignees assigned to the role, such as role groups, assignment policies, and USGs, and lists
the members of each.

NOTE
The GetEffectiveUser switch doesn't list users that are members of a linked foreign role group. Instead of a list of users, if a
linked role group is found, All Linked Group Members is displayed. For more information about permissions in multiple
forests, see Understanding multiple-forest permissions.

For more information about management roles, role groups, and assignment policies, see Understanding Role
Based Access Control. For more information about management role assignments, see Understanding
management role assignments.
Looking for other management tasks related to managing permissions? Check out Permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role groups" or "Role assignment policy" entries in the Role management
permissions topic.
The procedures in this topic can only be performed in the Shell. You can't use the Exchange admin center
(EAC ) to view effective permissions.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Use the Shell to list all effective users
To list all the users that are granted the permissions provided by a management role, use the following syntax.

Get-ManagementRoleAssignment -Role <role name> -GetEffectiveUsers

This example lists all the users that are granted permissions provided by the Mail Recipients role.

Get-ManagementRoleAssignment -Role "Mail Recipients" -GetEffectiveUsers

If you want to change what properties are returned in the list or export the list to a comma-separated value (.csv)
file, see Use the Shell to customize output and display it later in this topic.
For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

Use the Shell to find a specific user on a role

To find a specific user that's been granted permissions by a management role, you must use the Get-
ManagementRoleAssignment cmdlet to retrieve a list of all effective users, and then pipe the output of the
cmdlet to the Where cmdlet. The Where cmdlet filters the output and returns only the user you specified. Use the
following syntax.

Get-ManagementRoleAssignment -Role <role name> -GetEffectiveUsers | Where {$_.EffectiveUserName -Eq "<name of

user>"}

This example finds the user David Strome on the Journaling role.

Get-ManagementRoleAssignment -Role Journaling -GetEffectiveUsers | Where {$_.EffectiveUserName -Eq "David

Strome"}

If you want to change what properties are returned in the list or export the list to a .csv file, see Use the Shell to
customize output and display it later in this topic.
For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

Use the Shell to find a specific user on all roles

To know every role that a user receives permissions from, you must use the Get-ManagementRoleAssignment
cmdlet to retrieve all effective users on all management roles and then pipe the output of the cmdlet to the Where
cmdlet. The Where cmdlet filters the output and returns only the role assignments that grant the user permissions.

Get-ManagementRoleAssignment -GetEffectiveUsers | Where {$_.EffectiveUserName -Eq "<name of user>"}

This example finds all the role assignments that grant permissions to the user Kim Akers.

Get-ManagementRoleAssignment -GetEffectiveUsers | Where { Get-ManagementRoleAssignment -GetEffectiveUsers |

Where {$_.EffectiveUserName -Eq "Kim Akers"}.EffectiveUserName -Eq "Kim Akers"}

If you want to change what properties are returned in the list or export the list to a CSV file, see Use the Shell to
customize output and display it later in this topic.
For detailed syntax and parameter information, see Get-ManagementRoleAssignment.
Use the Shell to customize output and display it
The default output of the Get-ManagementRoleAssignment cmdlet might not have the information you want.
The output of the cmdlet contains many more properties that you can access. The following are some of the
properties that could be useful:
EffectiveUserName: Name of the user.
Role: Role that's granting the permissions.
RoleAssigneeName: Role group, assignment policy, or USG that's assigned to the role and contains the
user in the EffectiveUserName property.
RoleAssigneeType: Indicates whether the role assignment is to a role group, assignment policy, USG, or
user.
AssignmentMethod: Indicates whether the assignment between the role and the role assignee is direct or
indirect.
CustomRecipientWriteScope: Indicates the custom recipient write scope, if any, that was applied to the
role assignment when it was created. The scope specified in this property overrides the implicit recipient
write scope specified in the RecipientWriteScope property.
CustomConfigWriteScope: Indicates the custom configuration write scope, if any, that was applied to the
role assignment when it was created. The scope specified in this property overrides the implicit
configuration write scope specified in the ConfigWriteScope property.
RecipientReadScope: Indicates the implicit recipient read scope that's applied to the role.
RecipientWriteScope: Indicates the implicit recipient write scope that's applied to the role.
ConfigReadScope: Indicates the implicit configuration read scope that's applied to the role.
ConfigWriteScope: Indicates the implicit configuration write scope that's applied to the role.
To select the properties you want to display in your list, you use commands similar to those used in the Use the
Shell to list all effective users, Use the Shell to find a specific user on a role, and Use the Shell to find a specific user
on all roles sections. The difference is that you pipe the results of those commands to the Format-Table or Select-
Object cmdlets. The Format-Table cmdlet is useful to output the list of results to your screen. The Select-Object
cmdlet is useful to output the list of your results to a .csv file.
Both cmdlets let you specify the properties you want to see and in the order you want to see them. The Format-
Table cmdlet gives you more options when you list results to a screen while Select-Object doesn't modify the
output in any way, which is useful when piping the list to a .csv file.
For more information about the Format-Table and Select-Object cmdlets, see Working with command output.

Output a customized list to your screen

1. Choose the information you want to see and find the associated command from one of the following
procedures:
Use the Shell to list all effective users
Use the Shell to find a specific user a role
Use the Shell to find a specific user on all roles
2. Choose the properties you want to see in your list.
3. Use the following syntax to view the list.

<command to retrieve list > | Format-Table <property 1>, <property 2>, <property ...>

This example finds the user David Strome on all roles, and displays the EffectiveUserName , Role ,
CustomRecipientWriteScope , and CustomConfigWriteScope properties.

Get-ManagementRoleAssignment -GetEffectiveUsers | Where {$_.EffectiveUserName -Eq "David Strome"} | Format-

Table EffectiveUserName, Role, CustomRecipientWriteScope, CustomConfigWriteScope

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

Output a customized list to a .csv file

To export a list to a .csv file, you need to pipe the results of the Get-ManagementRoleAssignment command
from the appropriate procedure listed previously to the Select-Object cmdlet. The output of the Select-Object
cmdlet is then piped to the Export-CSV cmdlet, which saves the .csv output to a file name you specify.
1. Choose the information you want to see and find the associated command from one of the following
procedures:
Use the Shell to list all effective users
Use the Shell to find a specific user a role
Use the Shell to find a specific user on all roles
2. Choose the properties you want to see in your list.
3. Use the following syntax to export the list to a .csv file.

<command to retrieve list > | Select-Object <property 1>, <property 2>, <property ...> | Export-CSV
<filename>

This example finds the user David Strome on all roles, and displays the EffectiveUserName , Role ,
CustomRecipientWriteScope , and CustomConfigWriteScope properties.

Get-ManagementRoleAssignment -GetEffectiveUsers | Where {$_.EffectiveUserName -Eq "David Strome"} | Select-

Object EffectiveUserName, Role, CustomRecipientWriteScope, CustomConfigWriteScope | Export-CSV c:\output.csv

You can now view the .csv file in a viewer of your choice.
For detailed syntax and parameter information, see Get-ManagementRoleAssignment.
 Feature permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Permissions in Microsoft Exchange Server 2013 are managed using the Role Based Access Control (RBAC )
permissions model. The following topics identify the management role groups required to administer the features
associated with each functional area in Exchange 2013.
Role management permissions
Messaging policy and compliance permissions
Anti-spam and anti-malware permissions
Mail flow permissions
Recipients Permissions
Email address and address book permissions
Sharing and collaboration permissions
Clients and mobile devices permissions
Unified Messaging permissions
High availability and site resilience permissions
Exchange and Shell infrastructure permissions
Server health and performance permissions
 Role management permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks to configure management roles vary depending on the procedure
being performed or the cmdlet you want to run. For more information about management roles, see
Understanding management roles.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups,
an equivalent custom role group, or an equivalent management role. You can also click on a role group
to see its management roles. If a feature lists more than one role group, you only need to be assigned
one of the role groups to use the feature. For more information about role groups and management
roles, see Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your
Exchange administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

Role management permissions

You can use the features in the following table to manage the management role groups, roles, assignment
policies, assignments, scopes that define the permissions you can apply to administrators, and end users.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Management roles Organization Management

Unscoped management roles Unscoped Role Management role management role

Role groups Organization Management

Assignment policies Organization Management

FEATURE PERMISSIONS REQUIRED

Role assignments Organization Management

Management scopes Organization Management

Management role entries Organization Management

Legacy permissions Organization Management

Active Directory split permissions Organization Management

IMPORTANT
To run the setup.exe command with the PrepareAD
and ActiveDirectorySplitPermissions parameters, the
account you use must be a member of the Schema
Admins and Enterprise Administrators groups.
 Messaging policy and compliance permissions
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to configure messaging policy and compliance vary depending on the procedure
being performed or the cmdlet you want to run. For more information about messaging policy and compliance,
see Messaging policy and compliance.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to
see its management roles. If a feature lists more than one role group, you only need to be assigned one
of the role groups to use the feature. For more information about role groups and management roles,
see Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

NOTE
Some features that you want to manage might exist on Edge Transport servers. To manage features on Edge Transport
servers, you need to become a member of the Local Administrators group on the Edge Transport server you want to
manage. Edge Transport servers don't use Role Based Access Control (RBAC). Features that can be managed on Edge
Transport servers have Edge Transport Local Administrator in the "Permissions required" column in the table below.

Messaging policy and compliance permissions

You can use the features in the following table to configure messaging policy and compliance features. The role
groups that are required to configure each feature are listed.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

FEATURE PERMISSIONS REQUIRED

Data loss prevention (DLP) If using Office 365:

Office 365 global admin, which automatically
includes Exchange Organization Management
Office 365 service admin, plus the Organization
Management admin role group in Exchange
Office 365 password admin
If using Exchange Server 2013 or Exchange Online only:
Compliance Management

Delete mailbox content (using the Search-Mailbox Discovery Management and

cmdlet with the DeleteContent switch)
Mailbox Import Export role

NOTE
By default, the Mailbox Import Export role isn't
assigned to any role group. You can assign a
management role to a built-in or custom role group, a
user or a universal security group. Assigning a role to
a role group is recommended. For more information,
see Add a role to a user or USG.

Discovery mailboxes - Create Organization Management

Recipient Management

Journaling Organization Management

Records Management

Mailbox audit logging Organization Management

Records Management

Message classifications Organization Management

Messaging records management Compliance Management

Organization Management
Records Management
FEATURE PERMISSIONS REQUIRED

In-Place eDiscovery Discovery Management

NOTE
By default, the Discovery Management role group
doesn't have any members. No users, including
administrators, have the required permissions to
search mailboxes. For more information, see Assign
eDiscovery permissions in Exchange.

In-Place Hold Discovery Management

Organization Management

IMPORTANT
To create a query-based In-Place Hold, a user requires
the Mailbox Search and Litigation Hold roles to be
assigned directly or via membership in a role group
that has both roles assigned. To create an In-Place
Hold without using a query, which places all mailbox
items on hold, you must have the Litigation Hold role
assigned. The Discovery Management role group is
assigned both roles.
The Organization Management role group is assigned
the Litigation Hold role. Members of the Organization
Management role group can place an In-Place Hold
on all items in a mailbox, but can't create a query-
based In-Place Hold.

In-Place Archive Organization Management

Recipient Management

In-Place Archive - Test connectivity Organization Management

Server Management

Information Rights Management (IRM) configuration Compliance Management

Organization Management

Retention policies - Apply Organization Management

Recipient Management
Records Management

Retention policies - Create See the entry for Messaging Records Management
FEATURE PERMISSIONS REQUIRED

Transport rules Organization Management

Records Management
 Anti-spam and anti-malware permissions
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks related to anti-spam and anti-malware vary depending on the
procedure being performed or the cmdlet you want to run. For more information about transport features, see
Mail flow.
This topic lists the permissions required to manage the mail flow features in Microsoft Exchange Server 2013.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to see
its management roles. If a feature lists more than one role group, you only need to be assigned one of the
role groups to use the feature. For more information about role groups and management roles, see
Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

NOTE
Some features that you want to manage might exist on Edge Transport servers. To manage features on Edge Transport
servers, you need to become a member of the Local Administrators group on the Edge Transport server you want to
manage. Edge Transport servers don't use Role Based Access Control (RBAC). Features that can be managed on Edge
Transport servers have Edge Transport Local Administrator in the "Permissions required" column in the table below.

NOTE
Some features may require that you have local administrator permissions on the server you want to manage. To manage
these features, you must be a member of the Local Administrators group on that server.

Anti-spam and Anti-Malware Permissions

You can use the features in the following tables to configure anti-spam and anti-malware settings in your
organization. The permissions that are required to configure each feature are listed.
Users who are assigned the View Only Management role group can view the configuration of the features
shown in the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Anti-malware Organization Management

Hygiene Management

Anti-spam features Organization Management

Hygiene Management

Anti-spam features - Edge Transport Edge Transport Local Administrator

 Mail flow permissions
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks related to mail flow vary depending on the procedure being
performed or the cmdlet you want to run. For more information about transport features, see Mail flow.
This topic lists the permissions required to manage the mail flow features in Microsoft Exchange Server
2013. For information about how Office 365 permissions relate to Exchange permissions, see Permissions
in Office 365.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role
groups, an equivalent custom role group, or an equivalent management role. You can also click on a
role group to see its management roles. If a feature lists more than one role group, you only need
to be assigned one of the role groups to use the feature. For more information about role groups
and management roles, see Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or
management roles assigned to you to see if you have the permissions that are necessary to
manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-
ManagementRoleAssignment cmdlet. If you don't have permissions to run the Get-
ManagementRoleAssignment cmdlet, ask your Exchange administrator to retrieve the role groups or
management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

NOTE
Some features that you want to manage might exist on Edge Transport servers. To manage features on Edge
Transport servers, you need to become a member of the Local Administrators group on the Edge Transport server
you want to manage. Edge Transport servers don't use Role Based Access Control (RBAC). Features that can be
managed on Edge Transport servers have Edge Transport Local Administrator in the "Permissions required" column
in the table below.

NOTE
Some features may require that you have local administrator permissions on the server you want to manage. To
manage these features, you must be a member of the Local Administrators group on that server.

Mail flow permissions

You can use the features in the following tables to configure mail flow settings in the Front End Transport
service on Client Access servers, in the Transport service on Mailbox servers, in the Mailbox Transport
service on Mailbox servers, and on Edge Transport servers. The permissions that are required to configure
each feature are listed.
Users who are assigned the View Only Management role group can view the configuration of the features
shown in the following table. For more information, see View -only Organization Management.
Mailbox servers and Client Access servers

FEATURE PERMISSIONS REQUIRED

Accepted domains Organization Management

Active Directory site and site link management Organization Management

Anti-spam features Organization Management

Hygiene Management

Anti-spam updates Organization Management

Hygiene Management

Certificate management Organization Management

Delivery Agent connectors Organization Management

Server Management

DSNs Organization Management

EdgeSync Organization Management

Foreign connectors Organization Management

Front End Transport service Organization Management

Server Management
Hygiene Management

Journaling Organization Management

Records Management

Mailbox access Organization Management

FEATURE PERMISSIONS REQUIRED

Mailbox junk email configuration Organization Management

Records Management
Recipient Management
Help Desk

Mailbox Transport service Organization Management

Server Management
Hygiene Management

MailTips Organization Management

Message classifications Organization Management

Records Management

Message tracking Organization Management

Records Management
Recipient Management

Moderated transport Organization Management

Recipient Management

Queues Organization Management

Server Management

Receive connectors Organization Management

Server Management
Hygiene Management

Remote domains Organization Management

SafeList aggregation Organization Management

Records Management

Send connectors Organization Management

Shadow redundancy Organization Management

 FEATURE PERMISSIONS REQUIRED

Testing mail flow Organization Management

Server Management

Testing Transport rule processing Organization Management

Transport agents Organization Management

Records Management

Transport configuration Organization Management

Transport logs Organization Management

Server Management

Transport rules Organization Management

Records Management

Transport service Organization Management

Server Management
Hygiene Management

X.400 domains Organization Management

Edge Transport servers

FEATURE PERMISSIONS REQUIRED

Accepted domains - Edge Transport Edge Transport Local Administrator

Address Rewriting - Edge Transport Edge Transport Local Administrator

Edge Transport server Edge Transport Local Administrator

EdgeSync - Edge Transport Edge Transport Local Administrator

Queues - Edge Transport Edge Transport Local Administrator

Receive connectors - Edge Transport Edge Transport Local Administrator

Send connectors - Edge Transport Edge Transport Local Administrator

FEATURE PERMISSIONS REQUIRED

Transport configuration - Edge Transport Edge Transport Local Administrator

Transport logs - Edge Transport Edge Transport Local Administrator

Transport rules - Edge Transport Edge Transport Local Administrator

 Recipients Permissions
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks to manage recipients vary depending on the procedure being
performed or the cmdlet you want to run.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role
groups, an equivalent custom role group, or an equivalent management role. You can also click on a
role group to see its management roles. If a feature lists more than one role group, you only need to
be assigned one of the role groups to use the feature. For more information about role groups and
management roles, see Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-
ManagementRoleAssignment cmdlet. If you don't have permissions to run the Get-
ManagementRoleAssignment cmdlet, ask your Exchange administrator to retrieve the role groups or
management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

Mailbox server permissions

Users who are assigned the View -Only Management role group can view the configuration of the features
in the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Calendar repair, server configuration Organization Management

Server Management

Delegating Mailbox servers Organization Management

Email address policies Organization Management

Server Management
FEATURE PERMISSIONS REQUIRED

Exchange Search Organization Management

View-only Organization Management
Server Management

Exchange Search - diagnostics Organization Management

View-only Organization Management
Support Diagnostics role

NOTE
The Support Diagnostics role isn't assigned to a role
group. For more information, see Add a role to a
user or USG.

Group metrics Organization Management

Server Management

Import Export Mailbox Import Export role

NOTE
The Mailbox Import Export role isn't assigned to a
role group. For more information, see Mailbox
Import Export role.

Mailbox Assistants Organization Management

Server Management

Mailbox moves Organization Management

Recipient Management

Mailbox recovery Organization Management

Mailbox repair request Organization Management

Server Management
Recipient Management

Mailbox restore request Organization Management

Mailbox server configuration Organization Management

Server Management
 FEATURE PERMISSIONS REQUIRED

Manage Exchange Search Indexer service on a Mailbox Local Administrator on the Mailbox server
server

MAPI connectivity Organization Management

Server Management

OAB virtual directories Organization Management

Server Management

Remove store mailbox Organization Management

Server Management

Calendar and sharing permissions

Users who are assigned the View -Only Management role group can view the configuration of the features
in the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Calendar configuration Organization Management

Recipient Management
Help Desk

Calendar diagnostics Organization Management

Records Management
Hygiene Management
Compliance Management
Help Desk

Calendar processing Organization Management

Recipient Management
Help Desk

Notifications Organization Management

Recipient Management

Organization relationships Organization Management

Sharing policies Organization Management

Resource mailbox configuration permissions
Users who are assigned the View -Only Management role group can view the configuration of the features
in the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Booking policies Organization Management

Recipient Management
Help Desk

Delegation Organization Management

Recipient Management

Resource mailbox schema configuration Organization Management

Mailbox database permissions

Users who are assigned the View -Only Management role group can view the configuration of the features
in the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Mailbox databases Organization Management

Server Management

Recipient provisioning permissions

This table contains the various permissions that are required to manage recipients.
Users who are assigned the View -Only Management role group can view the configuration of the features
in the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Address list, GAL Organization Management

Anti-spam Organization Management

Recipient Management

Apps for Outlook Organization Management

View-only Organization Management
Help Desk
FEATURE PERMISSIONS REQUIRED

Applying sharing policies Organization Management

Recipient Management

Arbitration Organization Management

Archive connectivity Organization Management

View-only Organization Management
Server Management

Assigning offline address books Organization Management

Recipient Management

Automatic replies Organization Management

Recipient Management
Help Desk

Calendar configuration Organization Management

Recipient Management

Calendar repair Organization Management

Recipient Management

Contact aggregation settings Organization Management

Recipient Management
View-only Organization Management

Disconnected mailboxes Organization Management

Recipient Management
Help Desk

Distribution groups Organization Management

Recipient Management

Dynamic distribution groups Organization Management

Recipient Management
FEATURE PERMISSIONS REQUIRED

Email addresses Organization Management

Recipient Management
UM Management

Inbox rules Organization Management

Recipient Management
Help Desk

Mail contacts Organization Management

Recipient Management

Mail tips Organization Management

Recipient Management

Mail user Organization Management

Recipient Management

Mailbox folder permissions Organization Management

Recipient Management
Help Desk

Mailbox folders Organization Management

Recipient Management

MAPI connectivity Organization Management

Message configuration Organization Management

Recipient Management
Help Desk

Message quotas Organization Management

Recipient Management

Moderation Organization Management

Recipient Management

Permissions and delegation Organization Management

 FEATURE PERMISSIONS REQUIRED

Archive mailboxes Organization Management

Recipient Management

Recipient data properties Organization Management

Recipient Management

Remote mailboxes Organization Management

Recipient Management

Retention and legal holds Organization Management

Recipient Management
Records Management

Send As Organization Management

Recipient Management

Spelling configuration Organization Management

Recipient Management
Help Desk

Unified Messaging Organization Management

UM Management

User mailboxes Organization Management

Recipient Management

User photos Organization Management

Recipient Management
Help Desk

Mailbox move and migration permissions

The table contains the permissions that are required to move on-premises mailboxes to different domains
or forests and to migrate on-premises mailboxes to and from your cloud-based organization.

FEATURE PERMISSIONS REQUIRED

Mailbox moves (local or cross-forest) Organization Management

Recipient Management
FEATURE PERMISSIONS REQUIRED

Mailbox moves (hybrid deployment) Organization Management

Recipient Management

Migration (on-boarding and off-boarding from the Organization Management

cloud)
Recipient Management
 Email address and address book permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to configure email address and address book features vary depending on the procedure
being performed or the cmdlet you want to run. For more information about email addresses and address books,
see Email addresses and address books.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the cmdlet
you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to see
its management roles. If a feature lists more than one role group, you only need to be assigned one of the
role groups to use the feature. For more information about role groups and management roles, see
Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management roles
assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

Email address and address book permissions

Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Address book policies Organization Management

Address lists Organization Management

Email address policies Organization Management

Details templates Organization Management

Global address lists Organization Management

FEATURE PERMISSIONS REQUIRED

Offline address books Organization Management

Offline address book connectivity Organization Management

 Sharing and collaboration permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to configure sharing and collaboration features vary depending on the procedure being
performed or the cmdlet you want to run. For more information about sharing and collaboration, see
Collaboration and Sharing.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the cmdlet
you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to see
its management roles. If a feature lists more than one role group, you only need to be assigned one of the
role groups to use the feature. For more information about role groups and management roles, see
Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management roles
assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

Sharing and collaboration feature permissions

You can use the features in the following table to configure sharing and collaboration features. The role groups
that are required to configure each feature are listed.
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Partner applications - configure Organization Management

Public folders, mail-enabled Organization Management

Recipient Management

Public folders Organization Management

Public Folder Management
FEATURE PERMISSIONS REQUIRED

Site mailboxes Organization Management

Recipient Management

Site mailbox provisioning policy Organization Management

Recipient Management
 Clients and mobile devices permissions
5/28/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks for clients and mobile devices vary depending on the procedure
being performed or the cmdlet you want to run. For more information about client and mobile device features,
see Clients and mobile.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups,
an equivalent custom role group, or an equivalent management role. You can also click on a role group
to see its management roles. If a feature lists more than one role group, you only need to be assigned
one of the role groups to use the feature. For more information about role groups and management
roles, see Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

NOTE
Some features may require that you have local administrator permissions on the server you want to manage. To
manage these features, you must be a member of the Local Administrators group on that server.

Client Access server permissions

You can configure any of the following features for the Client Access server.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Client Access server array settings Organization Management

Server Management

Client Access server settings Server Management

 FEATURE PERMISSIONS REQUIRED

Client Access service email channel settings Organization Management

Server Management

Client Access user settings Server Management

Client Access virtual directory settings Organization Management

Server Management

RPC Client Access settings Organization Management

Server Management
View-only Organization Management

Push notification proxy settings Organization Management

Recipient Management

OAuth authentication redirection settings Organization Management

Exchange ActiveSync permissions

You can configure any of the following for Exchange ActiveSync.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Exchange ActiveSync Autoblock settings Organization Management

Exchange ActiveSync mailbox policy settings Organization Management

Server Management

Exchange ActiveSync server settings Organization Management

Server Management

Exchange ActiveSync settings Organization Management

Server Management

Exchange ActiveSync user settings Recipient Management

 FEATURE PERMISSIONS REQUIRED

Exchange ActiveSync virtual directory settings Organization Management

Server Management

Mobile device mailbox policy settings Organization Management

Server Management

Mobile device user settings Organization Management

Server Management
Recipient Management

Autodiscover permissions
You can configure the following for the Autodiscover service.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Autodiscover service configuration settings Organization Management

Server Management
View-only Organization Management
Delegated Setup
Hygiene Management

Autodiscover virtual directory settings Organization Management

Server Management

Availability service permissions

You can configure the following for the Availability service.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Availability service address space settings Organization Management

View-only Organization Management
 FEATURE PERMISSIONS REQUIRED

Availability service configuration settings Organization Management

Server Management
View-only Organization Management

Client throttling permissions

You can configure the following for client throttling.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Client throttling settings Organization Management

View-only Organization Management

Exchange Web Services permissions

You can configure the following for Web Services virtual directories.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Exchange Web Services virtual directory settings Organization Management

Server Management

Test Exchange Web Services Organization Management

Server Management

Test Outlook Web Services Organization Management

Outlook Anywhere permissions

You can configure and manage the following settings for Outlook Anywhere.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

 FEATURE PERMISSIONS REQUIRED

Outlook Anywhere configuration (enable, disable, Organization Management

change, view)
Server Management
View-only Organization Management
Delegated Setup
Hygiene Management

RPC over HTTP Proxy component Local Server Administrator

Test Outlook Anywhere connectivity Organization Management

View-only Organization Management
Server Management

Outlook Web App permissions

You can use the following features to view Outlook Web App settings, control security and user access to
Outlook Web App, and test Outlook Web App connectivity.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Graphics editor Local Server Administrator

IIS Manager Local Server Administrator

ISA Server 2006 ISA Server Enterprise Administrator

Outlook Web App mailbox policies Organization Management

Recipient Management

Outlook Web App virtual directories Organization Management

Server Management

Registry Editor Local Server Administrator

S/MIME configuration Organization Management

Text editor Local Server Administrator

 FEATURE PERMISSIONS REQUIRED

View Outlook Web App mailbox policies Organization Management

Recipient Management
View-only Organization Management
Delegated Setup
Hygiene Management

POP3 and IMAP4 permissions

You can configure the following for POP3 and IMAP4.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

IMAP4 settings Organization Management

Server Management
View-only Organization Management

POP3 settings Organization Management

Server Management
View-only Organization Management

Test IMAP4 settings Organization Management

Server Management
View-only Organization Management

Test POP3 settings Organization Management

Server Management
View-only Organization Management

Windows PowerShell virtual directory permissions

You can configure the following for Windows PowerShell.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Test Windows PowerShell Organization Management

 FEATURE PERMISSIONS REQUIRED

Windows PowerShell settings Organization Management

Text Messaging permissions

You can configure the following for text messaging.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Text messaging notification settings Recipient Management

Text messaging settings Recipient Management

Text messaging user settings MyTextMessaging role

Users can configure text messaging settings on their
own mailbox. Administrators can't configure the text
messaging settings on another user's mailbox.
 Unified Messaging permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks on Client Access servers that are running the Microsoft Exchange
Unified Messaging Call Router service and Mailbox servers that are running the Microsoft Exchange Unified
Messaging service vary depending on the procedure being performed or the cmdlet you want to run.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to
see its management roles. If a feature lists more than one role group, you only need to be assigned one
of the role groups to use the feature. For more information about role groups and management roles,
see Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

UM component permissions
You can configure settings for the UM components and features in the following table.
Users who are assigned the View -Only Management role group can view the configuration of the features in
the following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

UM auto attendants Organization Management

UM Management

UM call answering rules Organization Management

UM Management

UM call data and summary reports Organization Management

UM Management
FEATURE PERMISSIONS REQUIRED

Client Access Server (UM call router service) Organization Management

UM Management

UM dial plans Organization Management

UM Management

UM hunt groups Organization Management

UM Management

UM IP gateways Organization Management

UM Management

UM mailbox policies Organization Management

UM Management

UM mailboxes Organization Management

UM Management

UM prompts Organization Management

UM Management

Mailbox server (UM service) Organization Management

Server Management
 High availability and site resilience permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to configure high availability vary depending on the procedure being performed or
the cmdlet you want to run. For more information about high availability, see High availability and site resilience.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to
see its management roles. If a feature lists more than one role group, you only need to be assigned one of
the role groups to use the feature. For more information about role groups and management roles, see
Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

Database availability group permissions

You can use the features in the following table to add, remove, and configure settings for database availability
groups (DAGs).
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Database availability group membership Organization Management

Database Availability Groups role

Database availability group properties Organization Management

Database Availability Groups role

Database availability groups Organization Management

Database Availability Groups role
 FEATURE PERMISSIONS REQUIRED

Database availability networks Organization Management

Database Availability Groups role

Mailbox database copy permissions

You can use the features in the following table to add, remove, update, and activate mailbox database copies.

FEATURE PERMISSIONS REQUIRED

Database switchover Organization Management

Databases role

Mailbox database copies Organization Management

Database Copies role

Server switchover Organization Management

Databases role

Update a mailbox database copy Organization Management

Database Copies role
 Exchange and Shell infrastructure permissions
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks to configure various components of Microsoft Exchange Server 2013
depend on the procedure being performed or the cmdlet you want to run. See each of the sections in this topic
for more information about their respective features.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the
cmdlet you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to
see its management roles. If a feature lists more than one role group, you only need to be assigned one of
the role groups to use the feature. For more information about role groups and management roles, see
Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management
roles assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

NOTE
Some features may require that you have local administrator permissions on the server you want to manage. To manage
these features, you must be a member of the Local Administrators group on that server.

Exchange infrastructure permissions

The following table lists the permissions required to perform tasks that configure general Exchange 2013
settings.
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Administrator audit logging Organization Management

Records Management
 FEATURE PERMISSIONS REQUIRED

Exchange admin center configuration settings View-only Organization Management

Exchange admin center connectivity Organization Management

Server Management

Exchange server configuration settings Organization Management

Server Management

Exchange Help settings Organization Management

Message categories Organization Management

Hygiene Management
Recipient Management
Help Desk

Product key Organization Management

Test system health Organization Management

Server Management

View-only administrator audit logging Organization Management

Records Management

NOTE
You can also manually assign the View-Only Audit Logs
management role to a management role group. For
more information, see View-Only Audit Logs role.

Write to audit log Users that are members of any role group or assigned
any management role can write to the administrator
audit log.

Shell infrastructure permissions

The following table lists the permissions required to perform tasks that configure features that control how the
Exchange Management Shell runs.
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.
 FEATURE PERMISSIONS REQUIRED

Active Directory Domain Services server settings Organization Management

Server Management
Recipient Management
UM Management

Cmdlet extension agents Organization Management

PowerShell virtual directories Organization Management

Server Management

PowerShell and WinRM installation Local Server Administrator

Remote Shell Organization Management

Federation and certificates permissions

The following table lists permissions required for performing tasks related to federation trusts, OAuth
configuration, certificate management, and hybrid deployment configuration.
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Certificate management Organization Management

Server Management

Federation trusts, OAuth Organization Management

Test federation trusts, OAuth Organization Management

View-only Organization Management
Server Management

Hybrid deployment configuration Organization Management

Intra-Organization connectors Organization Management

Recipient Management
Records Management
 Server health and performance permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The permissions required to perform tasks to configure various components of Microsoft Exchange Server 2013
depend on the procedure being performed or the cmdlet you want to run. See each of the sections in this topic for
more information about their respective features.
To find out what permissions you need to perform the procedure or run the cmdlet, do the following:
1. In the table below, find the feature that is most related to the procedure you want to perform or the cmdlet
you want to run.
2. Next, look at the permissions required for the feature. You must be assigned one of those role groups, an
equivalent custom role group, or an equivalent management role. You can also click on a role group to see
its management roles. If a feature lists more than one role group, you only need to be assigned one of the
role groups to use the feature. For more information about role groups and management roles, see
Understanding Role Based Access Control.
3. Now, run the Get-ManagementRoleAssignment cmdlet to look at the role groups or management roles
assigned to you to see if you have the permissions that are necessary to manage the feature.

NOTE
You must be assigned the Role Management management role to run the Get-ManagementRoleAssignment
cmdlet. If you don't have permissions to run the Get-ManagementRoleAssignment cmdlet, ask your Exchange
administrator to retrieve the role groups or management roles assigned to you.

If you want to delegate the ability to manage a feature to another user, see Delegate role assignments.

NOTE
Some features may require that you have local administrator permissions on the server you want to manage. To manage
these features, you must be a member of the Local Administrators group on that server.

Exchange workload management permissions

The following table lists the permissions required to perform tasks that manage the health and performance of
your Exchange 2013 organization. For more information, see Exchange workload management.
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

User throttling Organization Management

Recipient Management
View-only Organization Management
 FEATURE PERMISSIONS REQUIRED

Exchange workload throttling Organization Management

View-only Organization Management

Exchange event log permissions

The following table lists the permissions required to perform tasks that manage Exchange event log settings.
Users who are assigned the View -Only Management role group can view the configuration of the features in the
following table. For more information, see View -only Organization Management.

FEATURE PERMISSIONS REQUIRED

Exchange event log management Organization Management

Server Management
View-only Organization Management
UM Management
 Advanced permissions
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The procedures in the following sections enable you to configure advanced permissions models for your
organization. You should have an in-depth knowledge of Role Based Access Control (RBAC ) before performing
advanced customization of your permissions model.
Management roles and role entries
Management role scopes
Management role assignments
Managing split permissions
We recommend you manage your permissions using management role groups and management role
assignment policies. For more information, see the following topics:
Manage role groups
Manage linked role groups
Manage role assignment policies
For more information about RBAC, see Understanding Role Based Access Control.
 Management roles and role entries
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following procedures enable you to perform advanced permissions management. You should only use these
procedures if management role groups and management role assignment policies don't meet the needs of your
organization.
Create a role
View a role
Remove a role
Add a role entry to a role
Change a role entry
View role entries
Remove a role entry from a role
Create an unscoped role
Change a role entry on an unscoped top-level role
Add a role entry to an unscoped top-level role
For more information about managing role groups and role assignment policies, see the following topics:
Manage role groups
Manage linked role groups
Manage role assignment policies
 Create a role
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can create a management role, change the management role entries, add a scope if
needed, and then assign the role to a role assignee. You should rarely need to perform this
procedure. We recommend that you check whether a built-in management role can be used
instead of creating a management role. For a list of built-in management roles, see Built-in
management roles.
For more information about management roles in Microsoft Exchange Server 2013, see
Understanding management roles.

NOTE
This topic doesn't discuss how to create an unscoped management role. For information about
how to create an unscoped management role, see Create an unscoped role.

Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete this procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "Management roles" entry in
the Role management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this
topic, see Keyboard shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Create the management role

New management roles are based on existing roles. When you create a role, an existing
role and its management role entries are copied to the new role. The existing role becomes
the parent to the new child role. You must always choose a role that contains all the cmdlets
and parameters you need to use, and then remove the ones you don't want. Child roles
can't have management role entries that don't exist in the parent role.
Use the following syntax to create the new role.

New-ManagementRole -Parent <existing role to copy> -Name <name of new role>

This example copies the Mail Recipients role and its management role entries to the Seattle
Mail Recipients role.

New-ManagementRole -Parent "Mail Recipients" -Name "Seattle Mail Recipients"

For detailed syntax and parameter information, see New -ManagementRole.

Step 2: Change the new role's management role entries

After you create your role, you need to change the role's entries. You can remove an entire
role entry, which removes access to the associated cmdlet completely. Or, you can remove
parameters from a role entry to remove access to those specific parameters on the
associated cmdlet.
You can't add new role entries or parameters on role entries unless they exist in the parent
role. Because you just created a role from a parent role in Step 1, you can't add any
additional role entries or parameters on role entries because they don't exist in the parent
role.
When you change a role entry on a role, you can do one of the following:
Remove a single, entire role entry.
Remove multiple, entire role entries.
Remove parameters from a role entry.
To remove role entries from your new role, see Remove a role entry from a role.

Step 3: Create a custom management role scope, if

required
Management role scopes determine the objects made available to a user to view or change
using the role entries configured in Step 2. New management roles inherit the read and
write management role scopes of their parent role. These are called implicit scopes.
However, there may be cases where you want to change the write scope of the new role to
match your business needs. When you create a custom scope, you override the implicit
write scope of the role. The implicit read scope of the role doesn't change. For more
information about management role scopes, see Understanding management role scopes.
You can create a custom scope, create an exclusive scope, use a predefined scope, or scope
an assignment to an organizational unit (OU ). The new scope must be within the implicit
read scope of the role. To use a predefined scope or to specify an organizational unit, skip to
Step 4.
To add a custom scope to your new role, see Create a regular or exclusive scope.

Step 4: Assign the new management role

The final step when you create and configure a role is to assign it to a role assignee.
When you create a role assignment, you can choose to do one of the following:
Create the role assignment with no scope.
Create the role assignment with a predefined scope.
 Create the role assignment with an OU without a domain restriction filter.
Create the role assignment with the custom or exclusive scope you created in Step 3.

NOTE
You can't specify a scope when you create an assignment between a role and a
management role assignment policy.

You can assign the new role to a role group, a role assignment policy, a user, or a universal
security group (USG ). For more information, see the following topics:
Manage role groups
Manage role assignment policies
Add a role to a user or USG
 View a role
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management roles can be listed in a variety of ways, depending on the information you want. For example, you can
choose to return only roles of a specific role type, roles that contain only specific cmdlets and parameters, or view
the details of a specific management role. For more information about management roles in Microsoft Exchange
Server 2013, see Understanding management roles.
If you want to view a list of all management role entries on a role, see View role entries.
Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
This topic makes use of pipelining and the Format-List and Format-Table cmdlets. For more information
about these concepts, see the following topics:
Pipelining
Working with command output
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

View a specific management role

You can view the details of a specific role by retrieving a specific role using the Get-ManagementRole cmdlet and
piping the output to the Format-List cmdlet.
To view the details of a specific role, use the following syntax.

Get-ManagementRole <role name> | Format-List

This example retrieves the details about the Mail Recipients management role.

Get-ManagementRole "Mail Recipients" | Format-List

For detailed syntax and parameter information, see Get-ManagementRole.

List all management roles
You can view a list of all the management roles in your organization by not specifying any roles when you run the
Get-ManagementRole cmdlet. By default, the role name and role type of each role are included in the results.
This example returns a list of all roles in your organization.

Get-ManagementRole

To return a list of specific properties for all the roles in your organization, you can pipe the results of the Format-
Table cmdlet and specify the properties you want in the list of results. Use the following syntax.

Get-ManagementRole | Format-Table <property 1>, <property 2...>

This example returns a list of all the roles in your organization and includes the Name property and any property
with the word Implicit at the beginning of the property name.

Get-ManagementRole | Format-Table Name, Implicit*

For detailed syntax and parameter information, see Get-ManagementRole.

List management roles that contain a specific cmdlet

You can return a list of roles that contain a cmdlet that you specify by using the Cmdlet parameter on the Get-
ManagementRole cmdlet.
To return a list of roles that contain the cmdlet you specify, use the following syntax.

Get-ManagementRole -Cmdlet <cmdlet>

This example returns a list of roles that contain the New-Mailbox cmdlet.

Get-ManagementRole -Cmdlet New-Mailbox

For detailed syntax and parameter information, see Get-ManagementRole.

List management roles that contain a specific parameter

You can return a list of roles that contain one or more specified parameters by using the CmdletParameters
parameter on the Get-ManagementRole cmdlet. Only roles that contain all the parameters you specify are
returned.
When you use the CmdletParameters parameter, you can choose to include the Cmdlet parameter. If you include
the Cmdlet parameter, only roles that contain the parameters you specify on the cmdlet you specify are returned. If
you don't include the Cmdlet parameter, roles that contain the parameters you specify, regardless of the cmdlet
they're on, are returned.
To return a list of roles that contain the parameters you specify, use the following syntax.

Get-ManagementRole [-Cmdlet <cmdlet>] -CmdletParameters <parameter 1>, <parameter 2...>

This example returns a list of roles that contain the Database and Server parameters, regardless of the cmdlets
they exist on.

Get-ManagementRole -CmdletParameters Database, Server

This example returns a list of roles where the EmailAddresses parameter exists only on the Set-Mailbox cmdlet.

Get-ManagementRole -Cmdlet Set-Mailbox -CmdletParameters EmailAddresses

You can also use the wildcard character (*) with either the Cmdlet or CmdletParameters parameters to match
partial cmdlet or parameter names.
For detailed syntax and parameter information, see Get-ManagementRole.

List management roles of a specific role type

You can return a list of roles based on a specified role type by using the RoleType parameter on the Get-
ManagementRole cmdlet.
To return a list of roles that match the role type you specify, use the following syntax.

Get-ManagementRole -RoleType <roletype>

This example returns a list of roles based on the UmMailboxes role type.

Get-ManagementRole -RoleType UmMailboxes

For detailed syntax and parameter information, see Get-ManagementRole.

List the immediate child roles of a parent role

You can return a list of roles that are the immediate children of the specified parent role by using the GetChildren
parameter on the Get-ManagementRole cmdlet. Only roles that contain the role you specify as the parent role
are returned.
To return a list of the immediate children roles of a parent role, use the following syntax.

Get-ManagementRole <parent role name> -GetChildren

This example returns a list of immediate children of the Disaster Recovery role.

Get-ManagementRole "Disaster Recovery" -GetChildren

For detailed syntax and parameter information, see Get-ManagementRole.

List all child roles below a parent role

You can return a list of the entire chain of roles from a specified parent role to the last child role by using the
Recurse parameter on the Get-ManagementRole cmdlet. The Recurse parameter tells the Get-
ManagementRole cmdlet to recurse down through every parent and child relationship it finds until it reaches the
last child role. The parent role is included in the list that's returned.
This example returns a list of all the child roles of a parent role.
 Get-ManagementRole <parent role name> -Recurse

This example returns all the child roles of the Mail Recipients role.

Get-ManagementRole "Mail Recipients" -Recurse

For detailed syntax and parameter information, see Get-ManagementRole.

 Remove a role
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management roles that are no longer required can be removed from your organization. You can only remove
management roles that you created. Built-in management roles can't be removed. For more information about
management roles in Microsoft Exchange Server 2013, see Understanding management roles.
Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
Before you can remove a management role, you must remove all its management role assignments. For
more information about how to remove a role assignment, see Remove a role from a user or USG.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Remove a management role with no child roles

To remove a role with no child roles, use the following syntax.

Remove-ManagementRole <role name>

This example removes the Seattle Server Administrators role.

Remove-ManagementRole "Seattle Server Administrators"

For detailed syntax and parameter information, see Remove-ManagementRole.

Remove a management role with child roles

If a role that you want to remove has child roles, you must remove all the child roles also. You receive an error
message if you try to remove a role that has child roles unless you use the Recurse switch. If you use the Recurse
switch when you remove a role, the role you specify and all its child roles are removed.
 WARNING
If you use the Recurse switch, all child roles of the specified role you want to remove are also removed. Make sure that you're
aware of what roles will be removed before you run this command.

To make sure that you remove only the roles that you want to remove, use the WhatIf switch with your command
to verify that it's correct. Use the following syntax.

Remove-ManagementRole <role name> -Recurse -WhatIf

The WhatIf switch performs the command without committing any changes and reports which roles it would have
removed. For more information about the WhatIf switch, see WhatIf, Confirm, and ValidateOnly switches.
After you confirm that only the roles you want to remove will be removed, run the same command without the
WhatIf switch. This example removes the London Administrators role and all its child roles.

Remove-ManagementRole "London Administrators" -Recurse

For detailed syntax and parameter information, see Remove-ManagementRole.

Remove an unscoped management role

To remove an unscoped role, the same procedures provided in Remove a management role with no child roles and
Remove a management role with child roles earlier in this topic can be used. The only difference is that when you
remove an unscoped role, you must specify the UnScopedTopLevel switch when you run the command. This
example removes an unscoped role and all its child roles.

Remove-ManagementRole "Custom IT Scripts" -Recurse -UnScopedTopLevel

As with removing other roles, you should use the WhatIf switch to verify that you're removing the correct roles.
For detailed syntax and parameter information, see Remove-ManagementRole.
 Add a role entry to a role
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

If you want to grant access to a cmdlet, you need to add the associated management role entry to a management
role. After you add the role entry to a role, the users assigned the role will be able to access that cmdlet. For more
information about management role entries in Microsoft Exchange Server 2013, see Understanding management
roles.
You can't add role entries to built-in roles. If you want to customize roles, you must create a new role. For more
information about how to create a new role, see Create a role.

NOTE
This topic doesn't discuss how to add unscoped management role entries to an unscoped management role. For more
information about how to add unscoped role entries, see Add a role entry to an unscoped top-level role.

Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
A role entry that you want to add to a management role must exist in that role's immediate parent
management role.
This topic makes use of pipelining. For more information about pipelining, see Pipelining.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Add a single role entry from a parent role

You can add a role entry to a role exactly as it appears on the parent role by using the following syntax.

Add-ManagementRoleEntry <child role name>\<cmdlet>

This example adds the Set-Mailbox cmdlet to the Recipient Administrators role.

Add-ManagementRoleEntry "Recipient Administrators\Set-Mailbox"

This command checks the parent role, and if the role entry exists, adds it to the child role. If the role entry already
exists on the child role, you can include the Overwrite parameter to overwrite the existing role entry.
For detailed syntax and parameter information, see Add-ManagementRoleEntry.

Add a single role entry from a parent role and include only specific
parameters
If you want to add a role entry from a parent role, but you want to include only specific parameters in the role
entry on the child role, use the following syntax.

Add-ManagementRoleEntry <child role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>, <parameter...>

This example adds the Set-Mailbox cmdlet to the Help Desk role, but includes only the DisplayName and
EmailAddresses parameters in the entry on the child role.

Add-ManagementRoleEntry "Help Desk\Set-Mailbox" -Parameters DisplayName, EmailAddresses

This command checks the parent role, and if the role entry exists, adds it to the child role. If the role entry already
exists on the child role, you can include the Overwrite parameter to overwrite the existing role entry.
For detailed syntax and parameter information, see Add-ManagementRoleEntry.

Add multiple role entries from a parent role

If you want to add more than one role entry to a role, you need to retrieve a list of role entries that exist on the
parent role that you want to add to the child role, and then add them to the child role. To do this, you retrieve the
list of role entries on a parent role by using the Get-ManagementRoleEntry cmdlet. Then you pipe the output
of the Get-ManagementRoleEntry cmdlet to the Add-ManagementRoleEntry cmdlet. To retrieve multiple
role entries, you need to use the wildcard character (*).
To add multiple entries from a parent role to a child role, use the following syntax.

Get-ManagementRoleEntry <parent role name>\*<partial cmdlet name>* | Add-ManagementRoleEntry -Role <child

role name>

This example adds all the role entries that contain the string Mailbox in the cmdlet name on the Mail Recipients
parent role to the Seattle Mail Recipients child role.

Get-ManagementRoleEntry "Mail Recipients\*Mailbox*" | Add-ManagementRoleEntry -Role "Seattle Mail Recipients"

If the role entries already exist on the child role, you can include the Overwrite parameter to overwrite the existing
role entries.
For more information about retrieving a list of management role entries, see View role entries.
For detailed syntax and parameter information, see Get-ManagementRoleEntry and Add-ManagementRoleEntry.
 Change a role entry
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Each management role entry on a management role represents a single cmdlet. By adding
parameters to or removing parameters from a role entry, which is then added to a
management role, you control whether those parameters are available on that cmdlet. For
more information about management role entries in Microsoft Exchange Server 2013, see
Understanding management roles.
You can't modify the role entries on built-in management roles.

NOTE
This topic doesn't discuss how to modify unscoped management role entries on an unscoped
management role. For more information about how to modify unscoped role entries, see Create a
role.

WARNING
To add or remove parameters from a role entry, you must use the AddParameter or
RemoveParameter parameters. If you omit the AddParameter or RemoveParameter parameter
when you run the Set-ManagementRoleEntry cmdlet, only the parameters you specify using the
Parameters parameter will be included in the role entry. All other parameters on the role entry will
be removed.

Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "Management roles" entry in
the Role management permissions topic.
You must use the Shell to perform these procedures.
If you want to add parameters to a role entry, the parameters you add must exist in
the role entry in the parent role. The parameters must also exist on the cmdlet you
specify.
If you want to remove parameters from a role entry, the parameters you remove
can't exist in the role entries of any child roles. You must remove the parameters
from the role entries of the child roles. Use the "Use the Shell to remove one or
more parameters from a role entry" procedure later in this topic to remove the
parameters from the role entries of all child roles.
For information about keyboard shortcuts that may apply to the procedures in this
topic, see Keyboard shortcuts in the Exchange admin center.
 TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to add one or more parameters to a role

entry
To add parameters to a role entry, you need to specify the parameters you want to add
using the Parameters parameter. You then need to specify the AddParameter parameter to
indicate that you want to perform an add operation.
To add parameters to a role entry, use the following syntax.

Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>,

<parameter...> -AddParameter

This example adds the EmailAddresses and Type parameters to the Set-Mailbox cmdlet on
the Recipient Administrators role.

Set-ManagementRoleEntry "Recipient Administrators\Set-Mailbox" -Parameters

EmailAddresses, Type -AddParameter

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Use the Shell to remove one or more parameters from a

role entry
To remove parameters from a role entry, you need to specify the parameters you want to
remove using the Parameters parameter. You then need to specify the RemoveParameter
parameter to indicate that you want to perform a remove operation.
To remove parameters from a role entry, use the following syntax.

Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>,

<parameter...> -RemoveParameter

This example removes the Port, ProtocolLoggingLevel, and SmartHostAuthMechanism

parameters from the Set-SendConnector cmdlet on the Tier 1 Server Administrators role.

Set-ManagementRoleEntry "Tier 1 Server Administrators\Set-SendConnector" -Parameters

Port, ProtocolLoggingLevel, SmartHostAuthMechanism -RemoveParameter

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Use the Shell to remove all parameters from a role entry

To remove all the parameters from a role entry, you need to specify the value $Null on the
Parameters parameter. You don't need to include the RemoveParameters parameter.
Removing all the parameters from a role entry is most useful when you want to make only
a few parameters available on a cmdlet and exclude all of the other parameters. If you don't
want the role to have access to a cmdlet, remove the associated role entry from the role
completely instead of just removing the parameters. For more information about how to
remove a role entry from a role, see Remove a role entry from a role.

WARNING
You can't undo remove operations. If you mistakenly remove all the parameters from a role entry,
you must add them again manually.

To remove all the parameters from a role entry, use the following syntax.

Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters $Null

This example removes all the parameters from the Set-CASMailbox cmdlet on the
Recipient Administrators role.

Set-ManagementRoleEntry "Recipient Administrators\Set-CASMailbox" -Parameters $Null

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Use the Shell to apply a specific set of parameters

If you want only a specific set of parameters to be included on a role entry, specify the
Parameters parameter only. Don't include the AddParameter or RemoveParameter
parameters. When you specify only the Parameters parameter, only the parameters you
specify in the command are included on the role entry. All other parameters are removed.
To specify a specific set of parameters, use the following syntax.

Set-ManagementRoleEntry <role name>\<cmdlet> -Parameters <parameter 1>, <parameter 2>,

<parameter...>

This example includes only the Identity, DisplayName, MissedCallNotificationEnabled, and

PersonalAuthAttendantEnabled parameters on the Set-UMMailbox cmdlet on the Seattle
Mail Recipients role.

Set-ManagementRoleEntry "Seattle Mail Recipients\Set-UMMailbox" -Parameters Identity,

DisplayName, MissedCallNotificationEnabled, PersonalAutoAttendantEnabled

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

 View role entries
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Each management role entry represents a single cmdlet or script. The parameters included on a role entry
determine what parameters on the cmdlet or script a user can access.
The identity of role entries consists of the management role name that the role entry is associated with, and the
cmdlet or script that the role entry refers to. For more information about role entries in Microsoft Exchange Server
2013, see Understanding management roles.
Looking for other management tasks related to role entries? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
This topic makes use of pipelining, the Format-List cmdlet, objects, and properties. For more information
about these concepts, see the following topics:
Pipelining
Working with command output
Structured data
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

View a list of role entries

You can use the Get-ManagementRoleEntry cmdlet to retrieve a list of role entries. When you use the Get-
ManagementRoleEntry cmdlet, you must specify a value that contains both the role name that contains the role
entries you want to list and also the cmdlet name of the role entry you want to list. By combining the role name
and cmdlet name with the wildcard character (*), you can return specific or broad lists of role entries.
For detailed syntax and parameter information, see Get-ManagementRoleEntry.

View a list of all role entries on a role

To view a list of role entries on a specific role, use the following syntax.
 Get-ManagementRoleEntry <role name>\*

This examples retrieves all the role entries on the Recipient Administrators role.

Get-ManagementRole "Recipient Administrators\*"

For detailed syntax and parameter information, see Get-ManagementRoleEntry.

View a list of roles that contain a specific role entry

To view a list of all the roles that contain a specific role entry, use the following syntax.

Get-ManagementRoleEntry *\<cmdlet name>

This example retrieves all the roles that contain the Set-Mailbox role entry.

Get-ManagementRoleEntry *\Set-Mailbox

For detailed syntax and parameter information, see Get-ManagementRoleEntry.

View a targeted list of roles that contain similar role entries

To view a list of targeted roles that contain cmdlets with similar names, use the following syntax.

Get-ManagementRoleEntry *<partial role name>*\*<partial cmdlet name>*

This example returns a list of role entries that contain the string Mailbox that are on roles that contain the string
Tier 1 in their names.

Get-ManagementRoleEntry "*Tier 1*\*Mailbox*"

For detailed syntax and parameter information, see Get-ManagementRoleEntry.

View a single role entry

To view the details of a single role entry, use the following syntax.

Get-ManagementRoleEntry <role name>\<cmdlet name> | Format-List

This example retrieves the details of the Set-Mailbox role entry on the Recipient Administrators role.

Get-ManagementRoleEntry "Recipient Administrators\Set-Mailbox" | Format-List

If the role entry you view has too many parameters to list using the Format-List cmdlet, see "View the parameters
on a single role entry" later in this topic.
For detailed syntax and parameter information, see Get-ManagementRoleEntry.

View the parameters on a single role entry

Some role entries have more parameters than can be viewed by piping the results of the Get-
ManagementRoleEntry cmdlet to the Format-List cmdlet. If you need to view all the parameters on a role
entry, you need to directly access the Parameters property of the role entry object.
To view parameters stored in the Parameters property of a role entry object, use the following syntax.

(Get-ManagementRoleEntry <role name>\<cmdlet name>).Parameters

This example retrieves the parameters on the Set-Mailbox role entry on the Mail Recipients role.

(Get-ManagementRoleEntry "Mail Recipients\Set-Mailbox").Parameters

For detailed syntax and parameter information, see Get-ManagementRoleEntry.

 Remove a role entry from a role
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role entries on a management role determine what cmdlets and parameters
are available on a management role. By removing role entries or parameters on a role
entry, you can restrict what users assigned the management role can perform. For more
information about management role entries in Microsoft Exchange Server 2013, see
Understanding management roles.
Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "Management roles" entry in
the Role management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this
topic, see Keyboard shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Remove a single entire role entry from a role

When you remove a role entry from a role, you remove the ability for users assigned that
role to access the associated cmdlet or script.
Use the following syntax to remove an entire management role entry from a role.

Remove-ManagementRoleEntry <management role>\<management role entry>

This example removes the Enable-MailUser cmdlet from the Seattle Server
Administrators role.

Remove-ManagementRoleEntry "Seattle Server Administrators\Enable-MailUser"

For detailed syntax and parameter information, see Remove-ManagementRoleEntry.

Remove multiple entire role entries from a role

When you remove multiple role entries from a role, you remove the ability for users
assigned that role to access the associated cmdlets or scripts.
To remove multiple role entries from a role, you need to retrieve the list of role entries to
remove using the Get-ManagementRoleEntry cmdlet. Then you need to pipe the output
to the Remove-ManagementRoleEntry cmdlet. You can use wildcard characters with the
Get-ManagementRoleEntry cmdlet to match multiple role entries. It's a good idea to use
the WhatIf switch to verify that you're removing the correct role entries. Use the following
syntax.

Get-ManagementRoleEntry <management role>\<role entry with wildcard character> |

Remove-ManagementRoleEntry -WhatIf

This example removes all the role entries that contain the word journal from the Seattle
Server Administrators role.

Get-ManagementRoleEntry "Seattle Server Administrators\*Journal*" | Remove-

ManagementRoleEntry -WhatIf

When you run the command with the WhatIf switch, the cmdlet returns a list of all the role
entries that would be removed. If the list looks correct, run the command again without the
WhatIf switch to remove the role entries.

Get-ManagementRoleEntry "Seattle Server Administrators\*Journal*" | Remove-

ManagementRoleEntry

For detailed syntax and parameter information, see Get-ManagementRoleEntry and

Remove-ManagementRoleEntry.

Remove parameters from a role entry on a role

When you remove parameters from a role entry on a role, those parameters are no longer
available to users assigned the role.
Use the following syntax to remove parameters from a role entry.

Set-ManagementRoleEntry <management role>\<role entry> -Parameters <parameter 1>,

<parameter 2...> -RemoveParameter

This example removes the MaxSafeSenders, MaxSendSize, SecondaryAddress, and

UseDatabaseQuotaDefaults parameters from the Set-Mailbox role entry on the Seattle
Server Administrators role.

Set-ManagementRoleEntry "Seattle Server Administrators\Set-Mailbox" -Parameters

MaxSafeSenders,MaxSendSize,SecondaryAddress,UseDatabaseQuotaDefaults -RemoveParameter

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

 Create an unscoped role
6/6/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

An unscoped management role can be used to provide administrators and specialist users access to Windows
PowerShell scripts and non-Exchange cmdlets. You can either create an unscoped top-level role and add scripts or
non-Exchange cmdlets to that role, or create a role that's based on an existing, unscoped top-level role. After an
unscoped role has been created and customized, the role can be assigned to management role groups, users, and
universal security groups (USGs). Unscoped roles can't be assigned to management role assignment policies. For
more information about unscoped roles, see Understanding management roles.

WARNING
Unscoped roles can be powerful because, as their name implies, no management scopes are applied to them. This means
that the scripts and non-Exchange cmdlets that they contain can be run against any object in your Exchange organization.
Consider this when adding scripts or non-Exchange cmdlets to an unscoped role and when assigning the unscoped role.

NOTE
If you want to create a role that contains Exchange cmdlets, you must create a role that's based on an existing management
role. For more information about creating roles with Exchange cmdlets, see Create a role.

Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
The ability to create unscoped roles isn't included in any management role group by default. You must first
assign the Unscoped Role Management role to a user, or to a USG or role group of which the user is a
member, before the user is able to create a role group. For more information about adding a role to a user,
USG, or role group, see the following topics:
Manage role groups
Add a role to a user or USG
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Create an unscoped top-level management role
If you want to make scripts or non-Exchange cmdlets available to administrators or specialists in your
organization, you need to create an unscoped top-level role. Scripts and non-Exchange cmdlets can only be added
to an unscoped role that's created as a top-level role, because the initial unscoped role doesn't inherit from other
roles. The new, unscoped top-level role can then be a parent to other unscoped roles that can also use the added
scripts and non-Exchange cmdlets.
Here are the steps to create an unscoped top-level role:

Step 1: Create the unscoped top-level role

Unscoped top-level roles don't have a parent role. You need to specify the UnscopedTopLevel switch to create a
role without a parent. Use the following syntax to create the new role.

New-ManagementRole <name of new role> -UnscopedTopLevel

This example creates the IT Scripts unscoped top-level role.

New-ManagementRole "IT Scripts" -UnscopedTopLevel

After it's created, the role is empty until you add scripts or non-Exchange cmdlets to it.
For detailed syntax and parameter information, see New -ManagementRole.

Step 2a: Add script management role entries

If you want to add a script to the new unscoped role, use this step. If you want to add a non-Exchange cmdlet to
the new unscoped role, use Step 2b.
To add a Windows PowerShell script to an unscoped top-level role, you must add a management role entry to the
role. The role entry contains the script's name and the parameters on the script that you want to make available to
the role.
The script must reside in the RemoteScripts directory in the Microsoft Exchange Server 2013 installation path on
every server running Exchange 2013 where users might connect to run the script. If a user has access to run a
script, but the script isn't located on the Exchange 2013 server the user is connected to, an error occurs. By default,
the path to the RemoteScripts directory is C:\Program Files\Microsoft\Exchange Server\V15\RemoteScripts.
After you copy the script to the appropriate Exchange 2013 servers and you decide what script parameters should
be used, create the role entry using the following syntax.

Add-ManagementRoleEntry <unscoped top-level role name>\<script filename> -Parameters <parameter 1, parameter

2, parameter...> -Type Script -UnscopedTopLevel

This example adds the BulkProvisionUsers.ps1 script to the IT Scripts role with the Name and Location
parameters.

Add-ManagementRoleEntry "IT Scripts\BulkProvisionUsers.ps1" -Parameters Name, Location -Type Script -

UnscopedTopLevel
 NOTE
The Add-ManagementRoleEntry cmdlet performs basic validation to make sure that you add only the parameters that
exist in the script. However, no further validation is done after the role entry is added. If parameters are later added or
removed, you must manually update the role entries that contain the script.

Step 2b: Add non-Exchange cmdlet role entries

If you want to add a non-Exchange cmdlet to the new unscoped role, use this step. If you want to add a script to
the new unscoped role, use Step 2a.
To add a non-Exchange cmdlet to an unscoped top-level role, you must add a management role entry to the role.
The role entry contains the cmdlet snap-in, cmdlet name, and the parameters on the cmdlet that you want to make
available to the role.
If you add non-Exchange cmdlets to the new role, the cmdlets must be installed on every Exchange 2013 server
where users might connect to run the cmdlets. To learn how to properly install and register the Windows
PowerShell snap-ins that contain the cmdlets you want to use, refer to the documentation for your product.
After you install the Windows PowerShell snap-in that contains the cmdlets on the appropriate Exchange 2013
servers and you decide what cmdlet parameters should be used, create the role entry using the following syntax.

Add-ManagementRoleEntry <unscoped top-level role name>\<cmdlet name> -PSSnapinName <snap-in name> -Parameters
<parameter 1, parameter 2, parameter...> -Type Cmdlet -UnscopedTopLevel

This example adds the Set-WidgetConfiguration cmdlet in the Contoso.Admin.Cmdlets snap-in to the Widget
Cmdlets role with the Database and Size parameters.

Add-ManagementRoleEntry "Widget Cmdlets\Set-WidgetConfiguration" -PSSnapinName Contoso.Admin.Cmdlets -

Parameters Database, Size -Type Cmdlet -UnscopedTopLevel

NOTE
The Add-ManagementRoleEntry cmdlet performs basic validation to make sure that you add only the parameters that
exist in the cmdlet. However, no further validation is done after the role entry is added. If the cmdlet is later changed, and
parameters are added or removed, you must manually update the role entries that contain the cmdlet.

Step 3: Assign the management role

The final step when you create and configure a role is to assign it to a role assignee.

IMPORTANT
Management scopes can't be configured on role assignments that assign an unscoped role. Whether you choose to create a
role assignment for a role group, user, or USG, you must choose the option to create a role assignment without a
management scope.

You can assign the new role to a role group, user, or USG. For more information, see the following topics:
Manage role groups
Add a role to a user or USG
Create an unscoped role based on another unscoped role
If you have an existing, unscoped top-level role or other unscoped roles that you want to base new unscoped roles
on, you can create child unscoped roles. The child unscoped roles can contain a subset of the scripts and cmdlets
that exist on the parent unscoped roles. This is useful, for example, if you want to give only a subset of the scripts
or cmdlets available on a parent unscoped role to a less experienced administrator.
Here are the steps to create an unscoped child role:

Step 1: Create the unscoped child role

New, unscoped child roles can be based on existing unscoped roles. When you create a role, an existing role and
its management role entries are copied to the new role. The existing role becomes the parent to the new child role.
If you create an unscoped role that's based on another unscoped role, you must choose a role that contains all the
cmdlets and parameters you need to use, and then remove the ones you don't want. Child unscoped roles can't
have management role entries that don't exist in the parent role.

NOTE
If you need to create an unscoped role that contains scripts or non-Exchange cmdlets that don't exist in any other unscoped
role, create an unscoped top-level role. For more information, see Create an unscoped top-level management role earlier in
this topic.

Use the following syntax to create the new role.

New-ManagementRole -Parent <existing unscoped role to copy> -Name <name of new unscoped role>

This example copies the IT Global Scripts role and its management role entries to the Diagnostic IT Scripts role.

New-ManagementRole -Parent "IT Global Scripts" -Name "Diagnostic IT Scripts"

For detailed syntax and parameter information, see New -ManagementRole.

Step 2: Change the role's management role entries

After you create your role, you need to change the role's entries. You can remove an entire role entry, which
removes access to the associated script or non-Exchange cmdlet completely. Or, you can remove parameters from
a role entry to remove access to those specific parameters on the associated script or non-Exchange cmdlet.
You can't add role entries or parameters on role entries unless they exist in the parent role. Because you just
created a role from a parent role in Step 1, you can't add any additional role entries or parameters on role entries
because they don't exist in the parent role.
When you change a role entry on a role, you can do one of the following:
Remove a single, entire role entry.
Remove multiple, entire role entries.
Remove parameters from a role entry.
To remove role entries from your new role, see Remove a role entry from a role.

Step 3: Assign the management role

The final step when you create and configure a role is to assign it to a role assignee.

IMPORTANT
Management scopes can't be configured on role assignments that assign an unscoped role. Whether you choose to create a
role assignment for a role group, user, or USG, you must choose the option to create a role assignment without a
management scope.

You can assign the new role to a role group, user, or USG. For more information, see the following topics:
Manage role groups
Add a role to a user or USG
 Change a role entry on an unscoped top-level role
5/28/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role entries on unscoped top-level management roles refer to the scripts and non-Exchange cmdlets,
and their parameters, that you want to make available to those assigned the role. By changing the parameters
available on a role entry, you control what those assigned the role can do with the script or non-Exchange cmdlet.
For more information about unscoped role entries, see Understanding management roles.

NOTE
If you want to change a role entry on a management role that contains Exchange cmdlets, see Change a role entry.

Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
The ability to change a role entry on an unscoped top-level role isn't included in any management role
group by default. You must first assign the Unscoped Role Management role to a user, or to a universal
security group (USG ) or role group of which the user is a member, before the user is able to add or change
an unscoped top-level role entry. For more information about adding a role to a user, USG, or role group,
see the following topics:
Manage role groups
Add a role to a user or USG
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to add one or more parameters to a role entry

To add parameters to an unscoped top-level role entry, you need to do the following:
Specify the parameters you want to add using the Parameters parameter.
Specify the AddParameter parameter to indicate that you want to perform an add operation.
Specify the UnscopedTopLevel parameter to indicate that you're changing a role entry on an unscoped top-
level role. If you don't specify this parameter when you change a role entry on an unscoped role, an error
 occurs.
To add parameters to a role entry, use the following syntax.

Set-ManagementRoleEntry <role name>\<script or non-Exchange cmdlet> -Parameters <parameter 1>, <parameter 2>,
<parameter...> -AddParameter -UnscopedTopLevel

This example adds the EmailAddress and City parameters to the CreateUsers.ps1 script on the Recipient
Administrators unscoped role.

Set-ManagementRoleEntry "Recipient Administrators\CreateUsers.ps1" -Parameters EmailAddress, City -

AddParameter -UnscopedTopLevel

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Use the Shell to remove one or more parameters from a role entry
To remove parameters from a role entry, you need to do the following:
Specify the parameters you want to remove using the Parameters parameter.
Specify the RemoveParameter parameter to indicate that you want to perform a remove operation.
Specify the UnscopedTopLevel parameter to indicate that you're changing a role entry on an unscoped top-
level role. If you don't specify this parameter when you change a role entry on an unscoped role, an error
occurs.

WARNING
You can't undo remove operations. If you mistakenly remove a parameter from a role entry, you must add it again manually.

To remove parameters from a role entry, use the following syntax.

Set-ManagementRoleEntry <role name>\<script or non-Exchange cmdlet> -Parameters <parameter 1>, <parameter 2>,
<parameter...> -RemoveParameter -UnscopedTopLevel

This example removes the Delay, Force, and Credential parameters from the Start-Widget non-Exchange cmdlet
on the Tier 1 Server Administrators role.

Set-ManagementRoleEntry "Tier 1 Server Administrators\Start-Widget" -Parameters Delay, Force, Credential -

RemoveParameter -UnscopedTopLevel

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Use the Shell to remove all parameters from a role entry

To remove all of the parameters from a role entry, you need to do the following:
Specify the value $Null on the Parameters parameter. You don't need to include the RemoveParameter
parameter.
Specify the UnscopedTopLevel parameter to indicate that you're changing a role entry on an unscoped top-
level role. If you don't specify this parameter when you change a role entry on an unscoped role, an error
occurs.
Removing all the parameters from a role entry is most useful when you want to make only a few parameters
available on a script or non-Exchange cmdlet and exclude all of the other parameters.
If you don't want the role to have access to a script or non-Exchange cmdlet, remove the associated role entry from
the role completely instead of just removing the parameters. For more information about how to remove a role
entry from a role, see Remove a role entry from a role.

WARNING
You can't undo remove operations. If you mistakenly remove all the parameters from a role entry, you must add them again
manually.

To remove all the parameters from a role entry, use the following syntax.

Set-ManagementRoleEntry <role name>\<script or non-Exchange cmdlet> -Parameters $Null -UnscopedTopLevel

This example removes all the parameters from the FindMailboxesOverQuota.ps1 script on the Recipient
Administrators role.

Set-ManagementRoleEntry "Recipient Administrators\FindMailboxesOverQuota.ps1" -Parameters $Null -

UnscopedTopLevel

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Use the Shell to apply a specific set of parameters

If you want only a specific set of parameters to be included on a role entry, you need to do the following:
Specify the Parameters parameter only. Don't include the AddParameter or RemoveParameter parameters.
Specify the UnscopedTopLevel parameter to indicate that you're changing a role entry on an unscoped role.
If you don't specify this parameter when you change a role entry on an unscoped top-level role, an error
occurs.

WARNING
When you specify only the Parameters parameter, only the parameters you specify in the command are included on the role
entry. All other parameters are removed.

To specify a specific set of parameters, use the following syntax.

Set-ManagementRoleEntry <role name>\<script or non-Exchange cmdlet> -Parameters <parameter 1>, <parameter 2>,
<parameter...> -UnscopedTopLevel

This example includes only the Alias, DisplayName, WidgetConfig, and Enabled parameters on the Set-Widget
cmdlet on the Seattle Mail Recipient Admins role.

Set-ManagementRoleEntry "Seattle Mail Recipient Admins\Set-UMMailbox" -Parameters Alias, DisplayName,

WidgetConfig, Enabled -UnscopedTopLevel

For detailed syntax and parameter information, see Set-ManagementRoleEntry.

Other tasks
After you change a role entry on an unscoped top-level role, you may also want to:
Add a role entry to a role
Manage role groups
Manage role group members
Add a role to a user or USG
Remove a role from a user or USG
 Add a role entry to an unscoped top-level role
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can add scripts and non-Exchange cmdlets to unscoped top-level management roles if you want to make new
scripts or non-Exchange cmdlets available to existing unscoped roles. These scripts and non-Exchange cmdlets are
added as management role entries to unscoped top-level management roles. They can then be used by those
unscoped top-level role entries or any unscoped roles derived from the top-level roles. For more information
about unscoped role entries, see Understanding management roles.

NOTE
If you want to change a role entry on a management role that contains Exchange cmdlets, see Change a role entry.

Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management roles" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
The ability to add a role entry on an unscoped top-level role isn't included in any management role group
by default. You must first assign the Unscoped Role Management role to a user, or to a universal security
group (USG ) or role group of which the user is a member, before the user is able to add an unscoped top-
level role entry. For more information about adding a role to a role group, user, or USG, see the following
topics:
Manage role groups
Add a role to a user or USG
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Add a script role entry to an unscoped top-level role

If you want to add a script to an existing unscoped role, use this procedure. If you want to add a non-Exchange
cmdlet to an existing unscoped role, see "Add a non-Exchange cmdlet role entry to an unscoped top-level role"
later in this topic.
To add a Windows PowerShell script to an unscoped top-level role, you must add a management role entry to the
role. The role entry contains the script's name and the parameters on the script that you want to make available to
the role.
The script must reside in the Scripts directory in the Microsoft Exchange Server 2013 installation path on every
server running Exchange 2013 where users might connect to run the script. If a user has access to run a script, but
the script isn't located on the Exchange 2013 server the user is connected to, an error occurs. By default, the path
to the Scripts directory is C:\Program Files\Microsoft\Exchange Server\V15\Scripts.
After you copy the script to the appropriate Exchange 2013 servers and you decide what script parameters should
be used, create the role entry using the following syntax.

Add-ManagementRoleEntry <unscoped top-level role name>\<script filename> -Parameters <parameter 1, parameter

2, parameter...> -Type Script -UnscopedTopLevel

This example adds the BulkProvisionUsers.ps1 script to the IT Scripts role with the Name and Location
parameters.

Add-ManagementRoleEntry "IT Scripts\BulkProvisionUsers.ps1" -Parameters Name, Location -Type Script -

UnscopedTopLevel

NOTE
The Add-ManagementRoleEntry cmdlet performs basic validation to make sure that you add only the parameters that
exist in the script. However, no further validation is done after the role entry is added. If parameters are later added or
removed, you must manually update the role entries that contain the script.

Add a non-Exchange cmdlet role entry to an unscoped top-level role

If you want to add a non-Exchange cmdlet to an existing unscoped role, use this procedure. If you want to add a
script to an existing unscoped role, see "Add a script role entry to an unscoped top-level role" earlier in this topic.
To add a non-Exchange cmdlet to an unscoped top-level role, you must add a management role entry to the role.
The role entry contains the cmdlet snap-in, cmdlet name, and the parameters on the cmdlet that you want to make
available to the role.
If you add non-Exchange cmdlets to the new role, the cmdlets must be installed on every Exchange 2013 server
where users might connect to run the cmdlets. To learn how to properly install and register the Windows
PowerShell snap-ins that contain the cmdlets you want to use, refer to the documentation for your product.
After you install the Windows PowerShell snap-in that contains the cmdlets on the appropriate the Exchange 2013
servers and you decide what cmdlet parameters should be used, create the role entry using the following syntax.

Add-ManagementRoleEntry <unscoped top-level role name>\<cmdlet name> -PSSnapinName <snap-in name> -Parameters
<parameter 1, parameter 2, parameter...> -Type Cmdlet -UnscopedTopLevel

This example adds the Set-WidgetConfiguration cmdlet in the Contoso.Admin.Cmdlets snap-in to the Widget
Cmdlets role with the Database and Size parameters.

Add-ManagementRoleEntry "Widget Cmdlets\Set-WidgetConfiguration" -PSSnapinName Contoso.Admin.Cmdlets -

Parameters Database, Size -Type Cmdlet -UnscopedTopLevel
 NOTE
The Add-ManagementRoleEntry cmdlet performs basic validation to make sure that you add only the parameters that
exist in the cmdlet. However, no further validation is done after the role entry is added. If the cmdlet is later changed, and
parameters are added or removed, you must manually update the role entries that contain the cmdlet.

Other tasks
After you add a role entry or an unscoped top-level role, you may also want to:
Add a role entry to a role
Manage role groups
Manage role group members
Add a role to a user or USG
Remove a role from a user or USG
 Management role scopes
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following procedures enable you to perform advanced permissions management. You should only use these
procedures if management role groups and management role assignment policies don't meet the needs of your
organization.
Create a regular or exclusive scope
Change a role scope
View role scopes
Remove a role scope
Control automatic mailbox distribution using database scopes
For more information about managing role groups and role assignment policies, see the following topics:
Manage role groups
Manage linked role groups
Manage role assignment policies
 Create a regular or exclusive scope
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role scopes determine what objects are made available to a user so that the
objects can be changed using the cmdlets and parameters assigned to them. By adding a
management scope, you can configure management role assignments so users can administer
specific servers, databases, recipients, and other objects in your organization while being
restricted from changing other objects.

IMPORTANT
When you create a regular or exclusive scope, you override the write scope that's defined on the
management role you're assigning. You can't override the read scope that's configured on the
management role.

You can create a custom management scope and add or change a management role
assignment. If you want to create a management role assignment with a prebuilt or
organizational unit (OU ) management scope, see Add a role to a user or USG.
For more information about management role scopes and assignments in Microsoft Exchange
Server 2013, see the following topics:
Understanding management role scopes
Understanding management role assignments
Looking for other management tasks related to scopes? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "Management scopes" entry in
the Role management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this topic,
see Keyboard shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Create a custom scope

To create a custom scope, choose one of the following types of scopes.
Recipient filter scope
Recipient filter-based scopes are created by using the RecipientRestrictionFilter parameter on
the New-ManagementScope cmdlet. When you create a recipient filter, in addition to the
recipient properties to filter, you can specify the OU in which the filter query runs. When you
specify a base OU, you further restrict the write scope of the role.
For more information about management scope filters, see Understanding management role
scope filters.
Use the following syntax to create a domain restriction filter scope with a base OU.

New-ManagementScope -Name <scope name> -RecipientRestrictionFilter <filter query> [-

RecipientRoot <OU>]

This example creates a scope that includes all mailboxes within the contoso.com/Sales OU.

New-ManagementScope -Name "Mailboxes in Sales OU" -RecipientRestrictionFilter {

RecipientType -eq 'UserMailbox' } -RecipientRoot "contoso.com/Sales OU"

NOTE
You can omit the RecipientRoot parameter if you want the filter to apply to the entire implicit read
scope of the management role and not just within a specific OU.

For detailed syntax and parameter information, see New -ManagementScope.

Server filter configuration scope
Server filter-based configuration scopes are created by using the ServerRestrictionFilter
parameter on the New-ManagementScope cmdlet. A server filter enables you to create a
scope that applies only to the servers that match the filter you specify.
For more information about management scope filters and for a list of filterable server
properties, see Understanding management role scope filters.
Use the following syntax to create a server filter scope.

New-ManagementScope -Name <scope name> -ServerRestrictionFilter <filter query>

This example creates a scope that includes all the servers within the
'CN=Redmond,CN=Sites,CN=Configuration,DC=contoso,DC=com' AD (Active Directory)
site.

New-ManagementScope -Name "Servers in Seattle AD site" -ServerRestrictionFilter {

ServerSite -eq 'CN=Redmond,CN=Sites,CN=Configuration,DC=contoso,DC=com' }

For detailed syntax and parameter information, see New -ManagementScope.

Server list configuration scope
Server list-based configuration scopes are created by using the ServerList parameter on the
New-ManagementScope cmdlet. A server list scope enables you to create a scope that
applies only to the servers you specify in a list.
Use the following syntax to create a server list scope.
 New-ManagementScope -Name <scope name> -ServerList <server 1>, <server 2...>

This example creates a scope that applies only to MBX1, MBX3, and MBX5.

New-ManagementScope -Name "Mailbox servers" -ServerList MBX1,MBX3,MBX5

For detailed syntax and parameter information, see New -ManagementScope.

Database filter configuration scope
Database filter-based configuration scopes are created by using the DatabaseRestrictionFilter
parameter on the New-ManagementScope cmdlet. A database filter enables you to create a
scope that applies only to the databases that match the filter you specify.

IMPORTANT
Role assignments associated with database scopes are applied only to users who connect to servers
running Microsoft Exchange Server 2010 Service Pack 1 (SP1) or later or Exchange 2013. If a user
assigned a role assignment associated with a database scope connects to a pre-Exchange 2010 SP1
server, the role assignment isn't applied to the user, and the user won't be granted any permissions
provided by the role assignment.

For more information about management scope filters and for a list of filterable database
properties, see Understanding management role scope filters.
Use the following syntax to create a database restriction filter.

New-ManagementScope -Name <scope name> -DatabaseRestrictionFilter <filter query>

This example creates a scope that includes all the databases that contain the string "Executive"
in the Name property of the database.

New-ManagementScope -Name "Executive Databases" -DatabaseRestrictionFilter { Name -Like

'*Executive*' }

For detailed syntax and parameter information, see New -ManagementScope.

Database list configuration scope
Database list-based configuration scopes are created by using the DatabaseList parameter on
the New-ManagementScope cmdlet. A database list scope enables you to create a scope that
applies only to the databases you specify in a list.

IMPORTANT
Role assignments associated with database scopes are applied only to users who connect to servers
running Microsoft Exchange Server 2010 Service Pack 1 (SP1) or later or Exchange 2013. If a user
assigned a role assignment associated with a database scope connects to a pre-Exchange 2010 SP1
server, the role assignment isn't applied to the user, and the user won't be granted any permissions
provided by the role assignment.

Use the following syntax to create a database list scope.

 New-ManagementScope -Name <scope name> -DatabaseList <database 1>, <database 2...>

This example creates a scope that applies only to the databases Database 1, Database 2, and
Database 3.

New-ManagementScope -Name "Primary databases" -DatabaseList "Database 1", "Database 2",

"Database 3"

For detailed syntax and parameter information, see New -ManagementScope.

Exclusive scope
Any scope that you create with the New-ManagementScope cmdlet can be designated as an
exclusive scope. To create an exclusive scope, you use the same commands in one of the
preceding sections to create a recipient filter-based scope, server filter-based scope, server list-
based scope, database filter-based scope, or database list-based scope, and then add the
Exclusive switch to the command.

WARNING
When you create exclusive management scopes, only the role assignees assigned exclusive scopes that
contain objects to be modified can access those objects. Only those administrators assigned a role with
the exclusive scope can access these exclusive, or protected, objects.

This example creates an exclusive recipient filter-based scope that matches any user in the
Executives department.

New-ManagementScope "Executive Users Exclusive Scope" -RecipientRestrictionFilter {

Department -Eq "Executives" } -Exclusive

By default, when an exclusive scope is created, you're required to acknowledge that you created
an exclusive scope and that you're aware of the impact that an exclusive scope has on existing
role assignments that aren't exclusive. If you want to suppress the warning, you can use the
Force switch. This example creates the same scope as the previous example, but without a
warning.

New-ManagementScope "Executive Users Exclusive Scope" -RecipientRestrictionFilter {

Department -Eq "Executives" } -Exclusive -Force

For detailed syntax and parameter information, see New -ManagementScope.

Step 2: Add or change a management role assignment

After you create the scope, you must add it to a new or existing management role assignment.
If you create a management scope and want to add it to a new management role assignment
that you're going to create, see the following topics:
Manage role groups
Add a role to a user or USG
If you create a management role scope and want to add it to an existing management role
assignment, see the following topics:
Manage role assignment policies
Change a role assignment
 Change a role scope
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role scopes determine what objects are made available to a user so that the
objects can be changed using the cmdlets and parameters assigned to them. By changing a
scope, you can change what objects are made available to users to create, change, or remove.
You can change a custom management scope. You can change either exclusive or regular scopes.
If you change an exclusive scope, the new scope takes effect immediately. If you want to change
a management role assignment with a predefined or organizational unit (OU ) management
scope, see Change a role assignment.
For more information about management role scopes and assignments in Microsoft Exchange
Server 2013, see the following topics:
Understanding management role scopes
Understanding management role assignments
Looking for other management tasks related to role scopes? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "Management scopes" entry in
the Role management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this topic,
see Keyboard shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Change the name of a scope

To change the name of a scope, use the following syntax.

Set-ManagementScope <current scope name> -Name <new scope name>

This example changes the Seattle Servers scope to Seattle Exchange Servers.

Set-ManagementScope "Seattle Servers" -Name "Seattle Exchange Servers"

For detailed syntax and parameter information, see Set-ManagementScope.

Change a recipient filter on a scope
To change the recipient filter on a scope, use the following syntax.

Set-ManagementScope <scope name> -RecipientRestrictionFilter { <new recipient filter> }

This example changes the recipient filter to match all the recipient objects where the Company
property is set to contoso.

Set-ManagementScope "Company Scope" -RecipientRestrictionFilter { Company -eq 'contoso' }

For detailed syntax and parameter information, see Set-ManagementScope.

For more information about recipient filters and to see a list of filterable recipient properties, see
Understanding management role scope filters.

Change the organizational unit root on a scope

To change the OU root on a scope, use the following syntax.

Set-ManagementScope <scope name> -RecipientRoot <OU>

This example changes the OU root to the North America/Sales Sales Users OU under the
contoso.com domain.

Set-ManagementScope "Sales Users" -RecipientRoot "contoso.com/North America/Sales"

For detailed syntax and parameter information, see Set-ManagementScope.

Change a server filter on a scope

To change the server filter on a scope, use the following syntax.

Set-ManagementScope <scope name> -ServerRestrictionFilter { <new server filter> }

This example changes the server filter to match all the server objects where the ServerSite
property is set to 'CN=Redmond,CN=Sites,CN=Configuration,DC=contoso,DC=com'.

Set-ManagementScope "Company Scope" -ServerRestrictionFilter { ServerSite -eq

'CN=Redmond,CN=Sites,CN=Configuration,DC=contoso,DC=com' }

For detailed syntax and parameter information, see Set-ManagementScope.

For more information about server filters and to see a list of filterable server properties, see
Understanding management role scope filters.

Change the server list on a scope

You can't change the list of servers on a scope. If you need to change the server list, you need to
do the following:
1. If needed, retrieve the current server list in the scope to be replaced by using the "View a
 specific scope" procedure in the View role scopes topic.
2. Create a scope with the new server list by using the "Step 1: Create a custom scope"
procedure in the Create a regular or exclusive scope topic.
3. Change all the management role assignments that use the old scope to use the new
scope by using the "Use the Shell to change the server filter or list-based scope on a role
assignment" procedure in the Change a role assignment topic.
4. Remove the old scope by using the procedure in the Remove a role scope topic.

Change a database filter on a scope

To change the database filter on a scope, use the following syntax.

Set-ManagementScope <scope name> -DatabaseRestrictionFilter { <new database filter> }

This example changes the database filter to match all the database objects where the Name
property contains the string "Executive".

Set-ManagementScope "Database Executive Scope" -DatabaseRestrictionFilter { Name -Like

"*Executive*" }

For detailed syntax and parameter information, see Set-ManagementScope.

For more information about database filters and to see a list of filterable database properties,
see Understanding management role scope filters.

Change the database list on a scope

You can't change the list of databases on a scope. If you need to change the database list, you
need to do the following:
1. If needed, retrieve the current database list in the scope to be replaced by using the "View
a specific scope" procedure in the View role scopes topic.
2. Create a scope with the new database list by using the "Step 1: Create a custom scope"
procedure in the Create a regular or exclusive scope topic.
3. Change all the management role assignments that use the old scope to use the new
scope by using the "Use the Shell to change the database filter or list-based scope on a
role assignment" procedure in the Change a role assignment topic.
4. Remove the old scope by using the procedure in the Remove a role scope topic.
 View role scopes
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role scopes determine what objects are made available to a user so that the objects can be changed
using the cmdlets and parameters assigned to them. You can view scopes to determine what scopes have been
added to your organization, the configuration of a specific scope, or what scopes are orphans.
For more information about management role scopes in Microsoft Exchange Server 2013, see Understanding
management role scopes.
Looking for other management tasks related to role scopes? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management scopes" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
This topic makes use of pipelining and the Format-List cmdlet. For more information about these concepts,
see the following topics:
Pipelining
Working with command output
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

View a specific scope

You can view the details of a scope by piping the output of the Get-ManagementScope cmdlet to the Format-
List cmdlet.
To view the details of a specific scope, use the following syntax.

Get-ManagementScope <scope name> | Format-List

This example retrieves the details of the Seattle Servers scope.

Get-ManagementScope "Seattle Servers" | Format-List

For detailed syntax and parameter information, see Get-ManagementScope.

List all scopes
This example retrieves a list of scopes in your organization.

Get-ManagementScope

This cmdlet retrieves both exclusive and regular scopes. If you only want to return exclusive scopes or regular
scopes, see "List all exclusive or regular scopes only" later in this topic.
For detailed syntax and parameter information, see Get-ManagementScope.

List all orphaned scopes

Orphaned scopes are scopes that haven't been associated with any management role assignments.
This examples retrieves a list of orphaned scopes.

Get-ManagementScope -Orphan

For detailed syntax and parameter information, see Get-ManagementScope.

List all exclusive or regular scopes only

By default, the Get-ManagementScope cmdlet returns a list of scopes that contains both exclusive and regular
scopes. If you want to return only exclusive scopes or only regular scopes use the following syntax.

Get-ManagementScope -Exclusive < $true | $false >

This example returns only exclusive scopes.

Get-ManagementScope -Exclusive $true

This example returns a list of regular scopes only.

Get-ManagementScope -Exclusive $false

For detailed syntax and parameter information, see Get-ManagementScope.

 Remove a role scope
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role scopes determine what objects are made available to a user who can then change the objects
using the cmdlets and parameters assigned to the user. If you're no longer using a scope, it can be removed. For
more information about management role scopes in Microsoft Exchange Server 2013, see Understanding
management role scopes.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management scopes" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
Before you can remove a scope, you must remove the scope from any management role assignments that
might be using it. For more information about how to remove a scope from a role assignment, see Change
a role assignment.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to remove a scope

To remove a scope, use the following syntax.

Remove-ManagementScope <scope name>

For example, to remove the "Dublin Servers" scope, use the following command.

Remove-ManagementScope "Dublin Servers"

 Control automatic mailbox distribution using
database scopes
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Automatic mailbox distribution is a feature in Microsoft Exchange Server 2013 that randomly selects a mailbox
database to store a new or moved mailbox when you don't specify a database explicitly. This feature can be helpful
when you want to allow junior administrators or help desk staff to create mailboxes without needing to know
which mailbox databases mailboxes should be created on.
You can use database management scopes to control which mailbox databases can be selected by automatic
mailbox distribution. When you apply database scopes to an administrator, only the databases that match the
defined database scope are available to the administrator. Because automatic mailbox distribution uses the context
of the current user, it's also constrained by the database scopes applied to the administrator.
For more information about automatic mailbox distribution, database scopes, and role assignments, see the
following topics:
Automatic mailbox distribution
Understanding management role scopes
Understanding management role assignments
Looking for other management tasks related to scopes? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete this procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Management scopes" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Create a database scope

In this step, decide which databases you want to include in the database scope. Also, decide whether you want to
specify a static list of databases, or whether you want to create a database filter that includes only the databases
that match the criteria you specify.
 IMPORTANT
Role assignments associated with database scopes are applied only to users who connect to servers running Microsoft
Exchange Server 2010 Service Pack 1 (SP1) or later or Exchange 2013. If a user assigned a role assignment associated with a
database scope connects to a pre-Exchange 2010 SP1 server, the role assignment isn't applied to the user, and the user
won't be granted any permissions provided by the role assignment.

Use a database list scope

Use a database list if you want to define a static list of mailbox databases that should be included in this scope. Use
the following syntax to create a database list scope.

New-ManagementScope -Name <scope name> -DatabaseList <database 1>, <database 2...>

This example creates a scope that applies only to the databases Database 1, Database 2, and Database 3.

New-ManagementScope -Name "Accounting databases" -DatabaseList "Database 1", "Database 2", "Database 3"

For detailed syntax and parameter information, see New -ManagementScope.

Use a database filter scope
Use a database filter if you want to create a dynamic database scope that includes only the databases that match
the criteria you specify. This can be useful if you don't want to manage the database scope after it's created and
you've defined standard values for your organization that can identify specific sets of mailbox databases.
For a list of filterable database properties, see Understanding management role scope filters.
Use the following syntax to create a database filter scope.

New-ManagementScope -Name <scope name> -DatabaseRestrictionFilter <filter query>

This example creates a scope that includes all the databases that contain the string "ACCT" in the Name property
of the database.

New-ManagementScope -Name "Accounting Databases" -DatabaseRestrictionFilter { Name -Like '*ACCT*' }

For detailed syntax and parameter information, see New -ManagementScope.

Step 2: Add the database scope to a management role assignment

After you create the scope, you must add it to a new or existing management role assignment. We recommend
that you use management role groups to control administrative permissions, so the examples in this step use an
example role group called Accounting Administrators. For more information about how to create a role group, see
Manage role groups.
After you assign the role to a role group with the database scope, the members of the role group will only be able
to create mailboxes on, and move mailboxes to, the databases included in the scope.
For a list of built-in roles that you can assign to role groups, see Built-in management roles.
Add a new role assignment
Use this procedure if you've just created a role group and you need to add roles to it.
Use the following syntax to create a role assignment between the management role you want to assign and the
new role group, with the new database scope.

New-ManagementRoleAssignment -SecurityGroup <role group name> -Role <role name> -CustomConfigWriteScope

<database scope name>

This example creates a role assignment between the Mail Recipients and Mail Recipient Creation roles and the
Accounting Administrators role group, using the Accounting Databases database scope.

New-ManagementRoleAssignment -SecurityGroup "Accounting Administrators" -Role "Mail Recipients" -

CustomConfigWriteScope "Accounting Databases"
New-ManagementRoleAssignment -SecurityGroup "Accounting Administrators" -Role "Mail Recipient Creation" -
CustomConfigWriteScope "Accounting Databases"

For detailed syntax and parameter information, see New -ManagementRoleAssignment.

Modify an existing role assignment
Use this procedure if you have an existing role group that already has role assignments between it and the roles
you want to apply the new database scope to.
This procedure uses pipelining. For more information, see Pipelining.
Use the following syntax to modify a role assignment between the management role that you want to apply the
database scope to, and an existing role group.

Get-ManagementRoleAssignment -RoleAssignee <role group name> -Role <role name> | Set-ManagementRoleAssignment

-CustomConfigWriteScope <database scope name>

This example adds the Accounting Databases database scope to the Mail Recipients and Mail Recipient Creation
roles assigned to the Accounting Administrators role group.

Get-ManagementRoleAssignment -RoleAssignee "Accounting Administrators" -Role "Mail Recipients" | Set-

ManagementRoleAssignment -CustomConfigWriteScope "Accounting Databases"
Get-ManagementRoleAssignment -RoleAssignee "Accounting Administrators" -Role "Mail Recipient Creation" | Set-
ManagementRoleAssignment -CustomConfigWriteScope "Accounting Databases"

For detailed syntax and parameter information, see Get-ManagementRoleAssignment or Set-

ManagementRoleAssignment.

Step 3: Add members to a role group (if applicable)

If you want to add members to a role group, see Manage role group members.

IMPORTANT
If you add members to this role group to restrict what databases they can create users on, or move mailboxes to, make sure
they aren't members of other role groups that could grant extra permissions.

Step 4: Remove members from a role group (if applicable)

If you've added members to a new role group that restricts what databases they can create mailbox on, or move
mailboxes to, and they're members of another role group that has additional permissions, remove them from the
old role group. For more information, see Manage role group members.
 Management role assignments
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following procedures enable you to perform advanced permissions management. You should only use these
procedures if management role groups and management role assignment policies don't meet the needs of your
organization.
Add a role to a user or USG
Change a role assignment
View role assignments
Remove a role from a user or USG
Delegate role assignments
For more information about managing role groups and role assignment policies, see the following topics:
Manage role groups
Manage linked role groups
Manage role assignment policies
 Add a role to a user or USG
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role assignments can assign a management role to
a user or universal security group (USG ). By assigning a role to a
user or USG, you enable those users to perform tasks
dependent on cmdlets or scripts and their parameters defined
on the management role.
If you want to assign roles to a management role group or a
management role assignment policy, see the following topics:
Manage role groups
Manage role assignment policies
If you want to add members to a role group or assign a role
assignment policy to an end user, see the following topics:
Manage role group members
Change the assignment policy on a mailbox
For more information, see Understanding Role Based Access
Control.
Looking for other management tasks related to roles? Check out
Advanced permissions.

What do you need to know before you

begin?
Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can
perform this procedure or procedures. To see what
permissions you need, see the "Role assignments" entry
in the Role management permissions topic.
You must use the Shell to perform these procedures.
Although you can assign roles directly to users and USGs,
the recommended method of granting permissions to
administrators and end users is to use management role
groups and management role assignment policies. When
you use role groups and assignment policies, you simplify
your permissions model.
Role assignments are additive. This means that all the
roles are added together when they're evaluated. If two
roles are assigned to a user and one role contains a
cmdlet but the other doesn't, the cmdlet will still be
 available to the user.
By default, role assignments don't grant the ability to
assign roles to other users. To enable a user to assign
roles to other users or USGs, see Delegate role
assignments.
If you create an assignment with a scope, the scope
overrides the role's implicit write scope. However, the
role's implicit read scope still applies. The new scope can't
return objects outside of the role's implicit read scope. For
more information, see Understanding management role
scopes.
All the procedures in this topic use the SecurityGroup
parameter to assign roles to a USG. If you want to assign
the role to a specific user, use the User parameter instead
of the SecurityGroup parameter. All other syntax for each
command is the same.
For information about keyboard shortcuts that may apply
to the procedures in this topic, see Keyboard shortcuts in
the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the
forums at Exchange Server.

Create a role assignment with no scope

You can create a role assignment with no scope. When you do
this, the implicit read and implicit write scopes of the role apply.
Use the following syntax to assign a role to a USG without any
scope.

New-ManagementRoleAssignment -Name <assignment name> -

SecurityGroup <USG> -Role <role name>

This example assigns the Exchange Servers role to the

SeattleAdmins USG.

New-ManagementRoleAssignment -Name "Exchange

Servers_SeattleAdmins" -SecurityGroup SeattleAdmins -Role
"Exchange Servers"

For detailed syntax and parameter information, see New -

ManagementRoleAssignment.

Create a role assignment with a

predefined relative scope
If a predefined relative scope meets your business requirements,
you can apply that scope to the role assignment rather than
create a custom scope. For a list of predefined scopes and their
descriptions, see Understanding management role scopes.
Use the following syntax to assign a role to a USG with a
predefined scope.

New-ManagementRoleAssignment -Name <assignment name> -

SecurityGroup < USG> -Role <role name> -
RecipientRelativeWriteScope < MyDistributionGroups |
Organization | Self >

This example assigns the Exchange Servers role to the

SeattleAdmins USG and applies the Organization predefined
scope.

New-ManagementRoleAssignment -Name "Exchange

Servers_SeattleAdmins" -SecurityGroup SeattleAdmins -Role
"Exchange Servers" -RecipientRelativeWriteScope Organization

For detailed syntax and parameter information, see New -

ManagementRoleAssignment.

Create a role assignment with a recipient

filter-based scope
If you created a recipient filter-based scope and want to use it
with a role assignment, you need to include the scope in the
command used to assign the role to a USG by using the
CustomRecipientWriteScope parameter. If you use the
CustomRecipientWriteScope parameter, you can't use the
RecipientOrganizationalUnitScope parameter.
Before you can add a scope to a role assignment, you need to
create one. For more information, see Create a regular or
exclusive scope.
Use the following syntax to assign a role to a USG with a
recipient filter-based scope.

New-ManagementRoleAssignment -Name <assignment name> -

SecurityGroup < USG> -Role <role name> -
CustomRecipientWriteScope <role scope name>

This example assigns the Mail Recipients role to the Seattle

Recipient Admins USG and applies the Seattle Recipients scope.

New-ManagementRoleAssignment -Name "Mail Recipients_Seattle

Recipient Admins" -SecurityGroup "Seattle Recipient Admins" -
Role "Mail Recipients" -CustomRecipientWriteScope "Seattle
Recipients"

For detailed syntax and parameter information, see New -

ManagementRoleAssignment.
Create a role assignment with a server or
database filter or list-based configuration
scope
If you created a server or database filter or list-based
configuration scope and want to use it with a role assignment,
you need to include the scope in the command used to assign
the role to a USG by using the CustomConfigWriteScope
parameter.
Before you can add a scope to a role assignment, you need to
create one. For more information, see Create a regular or
exclusive scope.
Use the following syntax to assign a role to a USG with a
configuration scope.

New-ManagementRoleAssignment -Name <assignment name> -

SecurityGroup <USG> -Role <role name> -CustomConfigWriteScope
<role scope name>

This example assigns the Exchange Servers role to the

MailboxAdmins USG and applies the Mailbox Servers scope.

New-ManagementRoleAssignment -Name "Exchange

Servers_MailboxAdmins" -SecurityGroup MailboxAdmins -Role
"Exchange Servers" -CustomConfigWriteScope "Mailbox Servers"

The preceding example shows how to add a role assignment

with a server configuration scope. The syntax to add a database
configuration scope is the same. You specify the name of a
database scope instead of a server scope.
For detailed syntax and parameter information, see New -
ManagementRoleAssignment.

Create a role assignment with an OU

scope
If you want to scope a role's write scope to an organizational unit
(OU ), you can specify the OU in the
RecipientOrganizationalUnitScope parameter directly. If you use
the RecipientOrganizationalUnitScope parameter, you can't use
the CustomRecipientWriteScope parameter.
Use the following syntax to assign a role to a USG and restrict
the write scope of a role to a specific OU.

New-ManagementRoleAssignment -Name <assignment name> -

SecurityGroup <USG> -Role <role name> -
RecipientOrganizationalUnitScope <OU>

This example assigns the Mail Recipients role to the

SalesRecipientAdmins USG and scopes the assignment to the
sales/users OU in the contoso.com domain.

New-ManagementRoleAssignment -Name "Mail

Recipients_SalesRecipientAdmins" -SecurityGroup
SalesRecipientAdmins -Role "Mail Recipients" -
RecipientOrganizationalUnitScope contoso.com/sales/users

For detailed syntax and parameter information, see New -

ManagementRoleAssignment.

Create a role assignment with an

exclusive recipient or configuration
scope
To create an exclusive role assignment with an exclusive
recipient or configuration scope, the same procedures provided
in the Create a role assignment with a recipient filter-based
scope and Create a role assignment with a server or database
filter or list-based configuration scope sections can be used. The
only difference is that when you create a role assignment with
an exclusive scope, you must specify the following exclusive
parameters depending on whether you're using an exclusive
recipient scope or an exclusive configuration scope:
Exclusive recipient scopes: Use the
ExclusiveRecipientWriteScope parameter instead of the
CustomRecipientWriteScope parameter.
Exclusive configuration scopes: Use the
ExclusiveConfigWriteScope parameter instead of the
CustomConfigWriteScope parameter.
When you perform this procedure, the role assignees assigned
the role can perform actions against the objects included in the
exclusive scope. For more information about exclusive scopes,
see Understanding exclusive scopes.
You can't create a role assignment with both exclusive and
regular scopes.
This example assigns the Mail Recipients role to the Protected
User Admins USG and applies the Protected Users exclusive
scope.

New-ManagementRoleAssignment -Name "Mail Recipients_Protected

User Admins" -SecurityGroup "Protected User Admins" -Role
"Mail Recipients" -ExclusiveRecipientWriteScope "Protected
Users"

For detailed syntax and parameter information, see New -

ManagementRoleAssignment.
 Change a
role
assignment
5/28/2019 • 6 minutes to read
• Edit Online

Applies to: Exchange Server 2013

Management role assignments
assign a management role to a role
assignee. By changing the role
assignment, you can control what
objects role assignees assigned a
role can change. Management role
scopes applied to role assignments
override the role's implicit write
scope. However, the role's implicit
read scope still applies. Scopes that
you apply can't return objects
outside of the role's implicit read
scope.
For more information about
management role scopes and
assignments in Microsoft Exchange
Server 2013, see the following
topics:
Understanding management
role assignments
Understanding management
role scopes
Looking for other management
tasks related to role assignments?
Check out Advanced permissions.

What do you need to

know before you
begin?
Estimated time to complete
each procedure: 5 minutes
You need to be assigned
permissions before you can
perform this procedure or
procedures. To see what
 permissions you need, see
the "Role assignments" entry
in the Role management
permissions topic.
You must use the Shell to
perform these procedures.
For information about
keyboard shortcuts that may
apply to the procedures in
this topic, see Keyboard
shortcuts in the Exchange
admin center.

TIP
Having problems? Ask for help in
the Exchange forums. Visit the
forums at Exchange Server.

Use the Shell to enable

or disable a role
assignment
Role assignments are enabled by
default, meaning that the associated
role is applied to the role assignee
to which the role is assigned. If a
role assignment is disabled, the
associated role isn't applied to the
role assignee.
To enable a role assignment, use the
following syntax.

Set-ManagementRoleAssignment
<role assignment> -Enabled $true

To disable a role assignment, use

the following syntax.

Set-ManagementRoleAssignment
<role assignment> -Enabled $false

This example disables the Help

Desk Assignment role assignment.

Set-ManagementRoleAssignment
"Help Desk Assignment" -Enabled
$false
For detailed syntax and parameter
information, see Set-
ManagementRoleAssignment.

Use the Shell to change

a management role or
role assignee on a role
assignment
You can't change the management
role or role assignee specified on a
role assignment. If you want a role
assignment to be associated with
another role or role assignee, you
must create a new role assignment,
and then delete the old role
assignment. For more information
about how to add and remove role
assignments, see the following
topics:
Add a role to a user or USG
Remove a role from a user or
USG
If you've created assignments
directly to a user or universal
security group (USG ), we
recommend that you consider using
management role groups and
management role assignment
policies. Role groups and
assignment policies enable you to
simplify your permissions model
and reduce the number of role
assignments you need to manage.
For more information, see
Understanding Role Based Access
Control.

Use the Shell to change

a predefined relative
scope on a role
assignment
You can change or add a predefined
relative scope on a role assignment.
If you add or change a predefined
scope, any previously specified
recipient scopes are removed from
the role assignment. For a list of
predefined scopes and their
descriptions, see Understanding
management role scopes.
To change or add a predefined
scope on a role assignment, use the
following syntax.

Set-ManagementRoleAssignment
<assignment name> -
RecipientRelativeWriteScope <
MyDistributionGroups |
Organization | Self >

This example changes the

predefined scope on the John's
Assignment role assignment to
MyDistributionGroups.

Set-ManagementRoleAssignment
"John's Assignment" -
RecipientRelativeWriteScope
MyDistributionGroups

For detailed syntax and parameter

information, see Set-
ManagementRoleAssignment.

Use the Shell to change

a recipient filter scope
on a role assignment
You can either specify a new
recipient filter-based scope or
change the recipient filter-based
scope that's already applied to the
role assignment. If you add a
recipient filter scope, any previously
defined recipient scopes are
removed from the role assignment.
To specify a new recipient filter-
based scope or replace an existing
one, use the following syntax.

Set-ManagementRoleAssignment
<assignment name> -
CustomRecipientWriteScope <role
scope name>

This example adds or changes the

recipient filter-based scope to
Redmond Recipients.
 Set-ManagementRoleAssignment
"Redmond Recipient Administrators
Assignment" -
CustomRecipientWriteScope
"Redmond Recipients"

If you want to keep the same

recipient filter-based scope that's
applied to the role assignment but
change the recipient filter used to
match recipient objects, you need to
change the recipient filter on the
scope itself. For more information
about how to change scopes, see
Change a role scope.
For detailed syntax and parameter
information, see Set-
ManagementRoleAssignment.

Use the Shell to change

the server filter or list-
based configuration
scope on a role
assignment
You can either specify a new server
filter or list-based configuration
scope, or change the scope that's
already applied to the role
assignment. If you add or change
the configuration scope, any
previously specified configuration
scopes are removed from the role
assignment.
To specify a new configuration
scope or replace an existing one, use
the following syntax.

Set-ManagementRoleAssignment
<assignment name> -
CustomConfigWriteScope <role
scope name>

This example adds or changes the

configuration scope to Redmond
Servers.
 Set-ManagementRoleAssignment
"Redmond Administrators
Assignment" -
CustomConfigWriteScope "Redmond
Servers"

If you want to keep the same

configuration scope that's applied to
the role assignment but change the
server filter or server list on the
scope, you need to change the
configuration scope itself. For more
information about how to change
scopes, see Change a role scope.
For detailed syntax and parameter
information, see Set-
ManagementRoleAssignment.

Use the Shell to change

the database filter or
list-based configuration
scope on a role
assignment
You can either specify a new
database filter or list-based
configuration scope, or change the
scope that's already applied to the
role assignment. If you add or
change the configuration scope, any
previously specified configuration
scopes are removed from the role
assignment.
To specify a new configuration
scope or replace an existing one, use
the following syntax.

Set-ManagementRoleAssignment
<assignment name> -
CustomConfigWriteScope <role
scope name>

This example adds or changes the

configuration scope to Redmond
Databases.

Set-ManagementRoleAssignment
"Redmond Database Admins" -
CustomConfigWriteScope "Redmond
Databases"
If you want to keep the same
configuration scope that's applied to
the role assignment but change the
database filter or database list on
the scope, you need to change the
configuration scope itself. For more
information about how to change
scopes, see Change a role scope.
For detailed syntax and parameter
information, see Set-
ManagementRoleAssignment.

Use the Shell to change

the organizational unit
on a role assignment
You can either add a new OU or
change an OU that's already applied
to the role assignment. If you
specify a new OU, any previously
specified recipient scopes are
removed from the role assignment.
To change or add a new OU on a
role assignment, use the following
syntax.

Set-ManagementRoleAssignment
<assignment name> -
RecipientOrganizationalUnitScope
<OU>

This example adds the

Engineering\Users OU in the
contoso.com domain to the
Engineering Help Desk role
assignment.

Set-ManagementRoleAssignment
"Engineering Help Desk" -
RecipientOrganizationalUnitScope
contoso.com/Engineering/Users

For detailed syntax and parameter

information, see Set-
ManagementRoleAssignment.

Use the Shell to change

an exclusive recipient or
configuration scope
To change exclusive recipient or
exclusive configuration scopes, you
can use the procedures provided in
the "Use the Shell to change a
recipient filter scope on a role
assignment," "Use the Shell to
change the server filter or list-based
configuration scope on a role
assignment," and "Use the Shell to
change the database filter or list-
based configuration scope on a role
assignment" sections earlier in this
topic. The only difference is that
when you change an exclusive
scope, you must specify the
following exclusive parameters
depending on whether you're
changing an exclusive recipient
scope or an exclusive configuration
scope:
Exclusive recipient scopes:
Use the
ExclusiveRecipientWriteScop
e parameter instead of the
CustomRecipientWriteScope
parameter.
Exclusive server and
database configuration
scopes: Use the
ExclusiveConfigWriteScope
parameter instead of the
CustomConfigWriteScope
parameter.
As with regular recipient and
configuration scopes, if you add or
change an exclusive scope, any
previously defined recipient or
configuration scopes are replaced.
This example changes an exclusive
recipient write scope.

Set-ManagementRoleAssignment
"Exclusive Executive Users" -
ExclusiveRecipientWriteScope
"Exclusive Executives"

For detailed syntax and parameter

information, see Set-
ManagementRoleAssignment.
 View role assignments
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role assignments assign a management role to a role assignee. For more information about
management role assignments in Microsoft Exchange Server 2013, see Understanding management role
assignments.
Looking for other management tasks related to roles? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role assignments" entry in the Role management permissions topic.
You must use the Shell to perform these procedures.
This topic makes use of pipelining and the Format-List cmdlet. For more information about these concepts,
see the following topics:
Pipelining
Working with command output
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

View a list of all role assignments

You can view a list of all role assignments configured in your organization by running the Get-
ManagementRoleAssignment cmdlet. If you want to retrieve a list of role assignments that match a partial
string that you specify, use wildcard characters (*). This example retrieves a list of all the role assignments that start
with the string "Tier 1".

Get-ManagementRoleAssignment "Tier 1*"

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View the details of a specific role assignment

You can view the details of a role assignment by piping the results of the Get-ManagementRoleAssignment
cmdlet to the Format-List cmdlet. Use the following syntax.

Get-ManagementRoleAssignment <assignment name> | Format-List

This example retrieves the details of the Help Desk Assignment role assignment.

Get-ManagementRoleAssignment "Help Desk Assignment" | Format-List

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View the list of role assignments assigned to a specific role assignee

To view a list of role assignments associated with a management role group, role, or role assignment policy, or
associated with a user or universal security group (USG ), use the following syntax.

Get-ManagementRoleAssignment -RoleAssignee <role assignee name>

This example retrieves all of the role assignments associated with the Server Management role group.

Get-ManagementRoleAssignment -RoleAssignee "Server Management"

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View the role assignments associated with a specific role

Each role can have multiple role assignments. You can use the Get-ManagementRoleAssigment cmdlet to view
a list of role assignments associated with a specified role.
To view a list of role assignments associated with a specified role, use the following syntax.

Get-ManagementRoleAssignment -Role <role name>

This example retrieves all of the role assignments associated with the Mail Recipients role.

Get-ManagementRoleAssignment -Role "Mail Recipients"

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View a list of role assignments that use a specific predefined scope

To view a list of role assignments that use a specific predefined scope, use the following syntax.

Get-ManagementRoleAssignment -RecipientWriteScope < MyGAL | MyDistributionGroups | Organization | Self |

CustomRecipientScope | ExecutiveRecipientScope >

This example retrieves all of the role assignments that use the Organization predefined scope.

Get-ManagementRoleAssignment -RecipientWriteScope Organization

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View a list of role assignments that have been scoped to a specific OU

To view a list of role assignments that have been scoped to a specific organizational unit (OU ), use the following
syntax.
 Get-ManagementRoleAssignment -RecipientOrganizationalUnitScope <OU>

This example retrieves all of the role assignments that have been scoped to the North America\Engineering\Users
OU in the contoso.com domain.

Get-ManagementRoleAssignment -RecipientOrganizationalUnitScope "contoso.com/North America/Engineering/Users"

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View a list of assignments that use a specific custom scope

To view a list of role assignments that use a specific custom scope, you need to first determine whether the scope is
a recipient scope, configuration scope, exclusive recipient scope, or exclusive configuration scope. Each type of
scope uses a different parameter on the Get-ManagementRoleAssignment cmdlet. The following lists each
scope and its associated parameter:
Recipient scopes: CustomRecipientWriteScope
Configuration scopes: CustomConfigWriteScope
Exclusive recipient scopes: ExclusiveRecipientWriteScope
Exclusive configuration scopes: ExclusiveConfigWriteScope
The syntax for each parameter is the same. Specify the name of the scope with the parameter that matches the
type of scope it is.
This example retrieves all of the role assignments that use the Vancouver Recipients recipient scope.

Get-ManagementRoleAssignment -CustomRecipientWriteScope "Vancouver Recipients"

This example retrieves all of the role assignments that use the Seattle AD Site exclusive configuration scope.

Get-ManagementRoleAssignment -ExclusiveConfigWriteScope "Seattle AD Site"

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View a list of exclusive or regular scopes

To view a list of exclusive or regular role assignments, use the following syntax.

Get-ManagementRoleAssignment -Exclusive < $True | $False >

For example, to view a list of exclusive scopes, run the following command:

Get-ManagementRoleAssignment -Exclusive $True

This example retrieves a list of regular scopes without any exclusive scopes.

Get-ManagementRoleAssignment -Exclusive $False

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View who can modify a specific recipient or server
To view a list of role assignments that can modify a specific recipient or server, use the WritableRecipient and
WritableServer parameters. Specify the name of the recipient with the WritableRecipient parameter, and the name
of the server with the WritableServer parameter.
This example retrieves a list of role assignments that can modify the recipient Brian.

Get-ManagementRoleAssignment -WritableRecipient "Brian"

You can combine the WritableRecipient and WritableServer parameters with other parameters, such as the
RoleAssignee parameter and the GetEffectiveUsers switch to refine your query and expand any role groups or
USGs. This example retrieves all of the users who can modify the server EX02 and who are assigned the Server
Management role group.

Get-ManagementRoleAssignment -WritableServer EX02 -RoleAssignee "Server Management" -GetEffectiveUsers

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View the users who receive permissions from an assignment via a role
group or USG
To view a list of users that receive permissions from a role assignment, use the following syntax.

Get-ManagementRoleAssignment <assignment name> -GetEffectiveUsers

This example retrieves a list of users in the Help Desk Assignment role assignment.

Get-ManagementRoleAssignment "Help Desk Assignment" -GetEffectiveUsers

You can also combine the GetEffectiveUsers switch with several other parameters on the Get-
ManagementRoleAssignment cmdlet to expand the role groups and USGs that the role assignments are
assigned to. For an example of how the GetEffectiveUsers switch is used with other parameters, see "View who can
modify a specific recipient or server" earlier in this topic.
For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

View a list of role assignments that are enabled or disabled

To view a list of role assignments that are enabled or disabled, use the following syntax.

Get-ManagementRoleAssignment -Enabled < $True | $False >

This example retrieves a list of role assignments that are disabled.

Get-ManagementRoleAssignment -Enabled $False

For detailed syntax and parameter information, see Get-ManagementRoleAssignment.

 Remove a role from a user or
USG
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role assignments assign a management role to a user
or universal security group (USG ). If you remove a role assignment,
the users assigned the role will no longer have access to the cmdlets
available on that role. For more information about management
role assignments in Microsoft Exchange Server 2013, see
Understanding management role assignments.
Looking for other management tasks related to roles? Check out
Advanced permissions.

What do you need to know before you

begin?
Estimated time to complete this procedure: 5 minutes
You need to be assigned permissions before you can perform
this procedure or procedures. To see what permissions you
need, see the "Role assignments" entry in the Role
management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to
the procedures in this topic, see Keyboard shortcuts in the
Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums
at Exchange Server.

Remove a management role assignment

If you know the name of the role assignment you want to remove,
use the following syntax.

Remove-ManagementRoleAssignment <assignment name>

For example, to remove the "Tier 2 Help Desk Assignment" role

assignment, use the following command.

Remove-ManagementRoleAssignment "Tier 2 Help Desk Assignment"

If you don't know the name of the role assignment, you can use the
following syntax.

Get-ManagementRoleAssignment -RoleAssignee <user or USG> -Role

<role name> -Delegating <$true | $false> | Remove-
ManagementRoleAssignment

For example, if you want to remove the Mail Recipients regular role
assignment from the user davids, use the following command.

Get-ManagementRoleAssignment -RoleAssignee davids -Role "Mail

Recipients" -Delegating $false | Remove-ManagementRoleAssignment
 Delegate role assignments
6/10/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Management role delegation enables role assignees to assign a specified management
role to other management role groups, management role assignment policies, users, or
universal security groups (USG ). By default, only members of the Organization
Management management role group can delegate role assignments. When a new
installation of Microsoft Exchange Server 2013 is deployed, only the user account that
installed Exchange 2013 is a member of the Organization Management role group.
If you assign a delegating role assignment to a role group, any member of the role
group can delegate the associated management role to other role assignees.

IMPORTANT
Delegating role assignments doesn't give the role assignee the permissions granted by the role,
only the ability to assign the role to others. If you want to also give the permissions granted by
the role to the role assignee, you must also create a regular role assignment. To create a
regular role assignment, see the following topics:
Manage role groups
Manage role assignment policies
Add a role to a user or USG

NOTE
This topic discusses management role assignment delegation. If you want to delegate who can
add members to or remove members from role groups, which is the recommended method of
delegation, see Manage role groups.

For more information about regular role assignments and delegating management role
assignments, see Understanding management role assignments.
Looking for other management tasks related to managing permissions? Check out
Advanced permissions.

What do you need to know before you begin?

Estimated time to complete this procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "Role assignments" entry
in the Role management permissions topic.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in
this topic, see Keyboard shortcuts in the Exchange admin center.
 TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to delegate a management role

You can create delegating role assignments using the same predefined scopes, recipient
filter or server-filter-based scopes, server list-based scopes, and organizational unit (OU )
scopes that can be used to create regular or exclusive scopes. The only difference
between creating a regular role assignment and a delegating role assignment is the
addition of the Delegating switch to the command. For more information about how to
create role assignments, see the following topics:
Manage role groups
Add a role to a user or USG

NOTE
You can't create a delegating role assignment to a management role assignment policy.

This example creates a delegating role assignment to enable members of the Senior
Admins role group to assign the Mail Recipients role to any role assignee in the
Exchange organization.

New-ManagementRoleAssignment -Role "Mail Recipients" -SecurityGroup "Senior Admins"

-Name "Mail Recipients_Senior Admin - Delegate" -Delegating

This example creates a delegating role assignment to enable members of the Senior
Admins role group to assign the Mail Recipients role only to users in the Sales/Users
OU in the contoso.com domain.

New-ManagementRoleAssignment -Role "Mail Recipients" -SecurityGroup "Senior Admins"

-Name "Mail Recipients_Senior Admins - Delegate" -RecipientOrganizationalUnitScope
contoso.com/sales/users -Delegating

For detailed syntax and parameter information, see New -ManagementRoleAssignment.

 Managing split permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following procedures enable you to perform advanced permissions management. You should only use these
procedures if management role groups and management role assignment policies don't meet the needs of your
organization.
Configure Exchange 2013 for split permissions
Configure Exchange 2013 for shared permissions
For more information about managing role groups and role assignment policies, see the following topics:
Manage role groups
Manage linked role groups
Manage role assignment policies
 Configure Exchange 2013 for split permissions
6/4/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

Split permissions enable two separate groups, such as Active Directory administrators and Microsoft Exchange
Server 2013 administrators, to manage their respective services, objects, and attributes. Active Directory
administrators manage security principals, such as users, that provide permissions to access an Active Directory
forest. Exchange administrators manage the Exchange-related attributes on Active Directory objects and
Exchange-specific object creation and management.
Microsoft Exchange Server 2013 offers the following types of split permissions models:
RBAC split permissions: Permissions to create security principals in the Active Directory domain partition
are controlled by Role Based Access Control (RBAC ). Only those who are members of the appropriate role
groups can create security principals.
Active Directory split permissions: Permissions to create security principals in the Active Directory
domain partition are completely removed from any Exchange user, service, or server. No option is provided
in RBAC to create security principals. Creation of security principals in Active Directory must be performed
using Active Directory management tools.

NOTE
Active Directory split permissions are available in organizations running Microsoft Exchange Server 2010 Service Pack
1 (SP1) or later, Exchange 2013, or both versions of Exchange.

The model that you choose depends on the structure and needs of your organization. Choose the procedure that
follows that's applicable to the model you want to configure. We recommend that you use the RBAC split
permissions model. The RBAC split permissions model provides significantly more flexibility while providing the
same administration separation as Active Directory split permissions.
For more information about shared and split permissions, see Understanding split permissions.
For more information about management role groups, management roles, and regular and delegating
management role assignments, see the following topics:
Understanding Role Based Access Control
Understanding management role groups
Understanding management roles
Understanding management role assignments
Looking for other management tasks related to permissions? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Active Directory split permissions" entry in the Role management
permissions topic.
 You must use Windows PowerShell, Windows Command Shell, or both, to perform these procedures. For
more information, see each procedure.
If you have Exchange 2010 servers in your organization, the permissions model you select will also be
applied to those servers.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Switch to RBAC split permissions

You can configure your Exchange 2013 organization for RBAC split permissions. When you are done, only Active
Directory administrators will be able to create Active Directory security principals. This means that Exchange
administrators won't be able to use the following cmdlets:
New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
Exchange administrators will only be able to manage the Exchange attributes on existing Active Directory security
principals. However, They will be able to create and manage Exchange-specific objects, such as transport rules and
distribution groups. For more information, see the "RBAC Split Permissions" section in Understanding split
permissions.
To configure Exchange 2013 for split permissions, you must assign the Mail Recipient Creation role and the
Security Group Creation and Membership role to a role group that contains members that are Active Directory
administrators. You must then remove the assignments between those roles and any role group or universal
security group (USG ) that contains Exchange administrators.
To configure RBAC split permissions, do the following:
1. If your organization is currently configured for Active Directory split permissions, do the following from a
Windows command shell prompt.
a. Disable Active Directory split permissions by running the following command from the Exchange
2013 installation media.

setup.exe /PrepareAD /ActiveDirectorySplitPermissions:false

b. Restart the Exchange 2013 servers in your organization or wait for the Active Directory access token
to replicate to all of your Exchange 2013 servers.
 NOTE
If you have Exchange 2010 servers in your organization, you also need to restart those servers.

2. Do the following from the Exchange Management Shell:

a. Create a role group for the Active Directory administrators. In addition to creating the role group,
the command creates regular role assignments between the new role group and the Mail Recipient
Creation role and the Security Group Creation and Membership role.

New-RoleGroup "Active Directory Administrators" -Roles "Mail Recipient Creation", "Security

Group Creation and Membership"

NOTE
If you want members of this role group to be able to create role assignments, include the Role Management
role. You don't have to add this role now. However, if you ever want to assign either the Mail Recipient
Creation role or Security Group Creation and Membership role to other role assignees, the Role
Management role must be assigned to this new role group. The steps that follow configure the Active
Directory Administrators role group as the only role group that can delegate these roles.

b. Create delegating role assignments between the new role group and the Mail Recipient Creation
role and Security Group Creation and Membership role using the following commands.

New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup "Active Directory

Administrators" -Delegating
New-ManagementRoleAssignment -Role "Security Group Creation and Membership" -SecurityGroup
"Active Directory Administrators" -Delegating

c. Add members to the new role group using the following command.

Add-RoleGroupMember "Active Directory Administrators" -Member <user to add>

d. Replace the delegate list on the new role group so that only members of the role group can add or
remove members.

Set-RoleGroup "Active Directory Administrators" -ManagedBy "Active Directory Administrators"

IMPORTANT
Members of the Organization Management role group, or those who are assigned the Role Management
role, either directly or through another role group or USG, can bypass this delegate security check. If you
want to prevent any Exchange administrator from adding himself or herself to the new role group, you must
remove the role assignment between the Role Management role and any Exchange administrator and assign
it to another role group.

e. Find all of the regular and delegating role assignments to the Mail Recipient Creation role using the
following command. The command displays only the Name, Role, and RoleAssigneeName
properties.
 Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Format-Table Name, Role,
RoleAssigneeName -Auto

f. Remove all of the regular and delegating role assignments to the Mail Recipient Creation role that
aren't associated with the new role group or any other role groups, USGs, or direct assignments you
want to keep using the following command.

Remove-ManagementRoleAssignment <Mail Recipient Creation role assignment to remove>

NOTE
If you want to remove all of the regular and delegating role assignments to the Mail Recipient Creation role
on any role assignee other than the Active Directory Administrators role group, use the following command.
The WhatIf switch lets you see what role assignments will be removed. Remove the WhatIf switch and run
the command again to remove the role assignments.

Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Where {$_.RoleAssigneeName -NE

"Active Directory Administrators"} | Remove-ManagementRoleAssignment -WhatIf

g. Find all of the regular and delegating role assignments to the Security Group Creation and
Membership role using the following command. The command displays only the Name, Role, and
RoleAssigneeName properties.

Get-ManagementRoleAssignment -Role "Security Group Creation and Membership" | Format-Table Name,

Role, RoleAssigneeName -Auto

h. Remove all of the regular and delegating role assignments to the Security Group Creation and
Membership role that aren't associated with the new role group or any other role groups, USGs, or
direct assignments you want to keep using the following command.

Remove-ManagementRoleAssignment <Security Group Creation and Membership role assignment to

remove>

NOTE
You can use the same command in the preceding Note to remove all of the regular and delegating role
assignments to the Security Group Creation and Membership role on any role assignee other than the Active
Directory Administrators role group, as shown in this example.

Get-ManagementRoleAssignment -Role "Security Group Creation and Membership" | Where

{$_.RoleAssigneeName -NE "Active Directory Administrators"} | Remove-ManagementRoleAssignment -
WhatIf

For detailed syntax and parameter information, see the following topics:
New -RoleGroup
New -ManagementRoleAssignment
Add-RoleGroupMember
 Set-RoleGroup
Get-ManagementRoleAssignment
Remove-ManagementRoleAssignment

Switch to Active Directory split permissions

You can configure your Exchange 2013 organization for Active Directory split permissions. Active Directory split
permissions completely remove the permissions that allow Exchange administrators and servers from creating
security principals in Active Directory or modifying non-Exchange attributes on those objects. When you are done,
only Active Directory administrators will be able to create Active Directory security principals. This means that
Exchange administrators won't be able to use the following cmdlets:
Add-DistributionGroupMember
New-DistributionGroup
New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-DistributionGroup
Remove-DistributionGroupMember
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
Update-DistributionGroupMember
Exchange administrators and servers will only be able to manage the Exchange attributes on existing Active
Directory security principals. However, they will be able to create and manage Exchange-specific objects, such as
transport rules and Unified Messaging dial plans.

WARNING
After you enable Active Directory split permissions, Exchange administrators and servers will no longer be able to create
security principals in Active Directory, and they won't be able to manage distribution group membership. These tasks must
be performed using Active Directory management tools with the required Active Directory permissions. Before you make
this change, you should understand the impact it will have on your administration processes and third-party applications
that integrate with Exchange 2013 and the RBAC permissions model.
For more information, see the "Active Directory split permissions" section in Understanding split permissions.

To switch from shared or RBAC split permissions to Active Directory split permissions, do the following:
1. From a Windows command shell, run the following command from the Exchange 2013 installation media
to enable Active Directory split permissions.

setup.exe /PrepareAD /ActiveDirectorySplitPermissions:true

2. If you have multiple Active Directory domains in your organization, you must either run
setup.exe /PrepareDomain in each child domain that contains Exchange servers or objects or run
setup.exe /PrepareAllDomains from a site that has an Active Directory server from every domain.

3. Restart the Exchange 2013 servers in your organization or wait for the Active Directory access token to
replicate to all of you Exchange 2013 servers.

NOTE
If you have Exchange 2010 servers in your organization, you also need to restart those servers.
 Configure Exchange 2013 for shared permissions
6/7/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Shared permissions enable you, as an administrator of Microsoft Exchange Server 2013, to create Active
Directory security principals, such as users, and then configure them as Exchange recipients. Unlike split
permissions, which separate management tasks between groups of Exchange administrators and Active Directory
administrators, there's no separation of tasks with shared permissions.
For more information about shared and split permissions, see Understanding split permissions.
You can configure your Exchange 2013 organization for shared permissions if you've previously set your
organization for split permissions. The procedure to switch to shared permissions is different depending on
whether you're currently using Role Based Access Control (RBAC ) split permissions or Active Directory split
permissions. Choose the procedure that follows that's applicable to your current configuration. If the following are
true, your organization is using Active Directory split permissions:
The Microsoft Exchange Protected Groups organizational unit (OU ) exists.
The Exchange Windows Permissions security group is located in the Microsoft Exchange Protected Groups
OU.
The Exchange Trusted Subsystem security group is a member of the Exchange Windows Permissions
security group.
There are no regular management role assignments to the Mail Recipient Creation role or Security Group
Creation and Membership role.
If you've never configured your organization for split permissions, you don't need to perform this procedure.
Exchange 2013 is configured for shared permissions by default.
For more information about management role groups, management roles, and regular and delegating
management role assignments, see the following topics:
Understanding Role Based Access Control
Understanding management role groups
Understanding management roles
Understanding management role assignments
Looking for other management tasks related to permissions? Check out Advanced permissions.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
Procedures in this topic require specific permissions. See each procedure for its permissions information.
You must use Windows PowerShell, the Windows Command Shell, or both, to perform these procedures.
For more information, see each procedure.
The Exchange 2013 organization must currently be configured for RBAC or Active Directory split
permissions.
 If you have Microsoft Exchange Server 2010 servers in your organization, the permissions model you
select will also be applied to those servers.
You must have permissions to delegate the Mail Recipient Creation management role and the Security
Group Creation and Membership management role to the Organization Management management role
group or another role group that's assigned the Mail Recipients role.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Switch from RBAC split permissions to shared permissions

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role groups" entry in the Role management permissions topic.
To switch from RBAC split permissions to Exchange 2013 shared permissions, you must assign the Mail Recipient
Creation role and the Security Group Creation and Membership role to a role group that's also assigned the Mail
Recipients role and has Exchange 2013 administrators as members. In the default shared permissions
configuration, the Organization Management role group contains each of these roles. Because of this, the
Organization Management role group is in this procedure.

Configure shared permissions

To configure shared permissions on the Organization Management role group, do the following using an account
that has permissions to delegate role assignments for the Mail Recipient Creation role and the Security Group
Creation and Membership role:
1. Add delegating role assignments for the Mail Recipient Creation role and Security Group Creation and
Membership role to the Organization Management role group using the following commands.

New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup "Organization Management" -

Delegating
New-ManagementRoleAssignment -Role "Security Group Creation and Membership" -SecurityGroup
"Organization Management" -Delegating

NOTE
The role group (in this procedure, the Active Directory Administrators role group) that has delegating role
assignments for the Mail Recipient Creation role and Security Group Creation and Membership role must be
assigned the Role Management role to run the New-ManagementRoleAssignment cmdlet. The role assignee that
can delegate the Role Management role must assign that role to the Active Directory Administrators role group.

2. Add regular role assignments for the Mail Recipient Creation role to the Organization Management and
Recipient Management role groups using the following commands.

New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup "Organization Management"

New-ManagementRoleAssignment -Role "Security Group Creation and Membership" -SecurityGroup "Recipient
Management"

3. Add a regular role assignment for the Security Group Creation and Membership role to the Organization
 Management role group using the following command.

New-ManagementRoleAssignment -Role "Security Group Creation and Membership" -SecurityGroup

"Organization Management"

For detailed syntax and parameter information, see New -ManagementRoleAssignment.

Remove permissions from Active Directory administrators (Optional)

You can optionally remove the permissions granted to Active Directory administrators if you no longer want them
to be able to create or manage Active Directory objects using the Exchange management tools. If you want to
remove permissions from Active Directory administrators, perform this procedure.

NOTE
Although you can remove permissions for Active Directory administrators to manage Active Directory objects using the
Exchange management tools, Active Directory administrators can continue to manage Active Directory objects using Active
Directory management tools, if their Active Directory permissions allow it. They won't, however, be able to manage
Exchange-specific attributes on Active Directory objects. For more information, see Understanding split permissions.

To remove Exchange-related split permissions from Active Directory administrators, do the following:
1. Remove the regular and delegating role assignments that assign the Mail Recipient Creation role to the
role group or universal security group (USG ) that contains the Active Directory administrators as members
using the following command. This command uses the Active Directory Administrators role group as an
example. The WhatIf switch lets you see what role assignments will be removed. Remove the WhatIf
switch, and run the command again to remove the role assignments.

Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Where {$_.RoleAssigneeName -EQ "Active

Directory Administrators"} | Remove-ManagementRoleAssignment -WhatIf

2. Remove the regular and delegating role assignments that assign the Security Group Creation and
Membership role to the role group or USG that contains the Active Directory administrators as members
using the following command. This command uses the Active Directory Administrators role group as an
example. The WhatIf switch lets you see what role assignments will be removed. Remove the WhatIf
switch, and run the command again to remove the role assignments.

Get-ManagementRoleAssignment -Role "Security Group Creation and Membership" | Where

{$_.RoleAssigneeName -EQ "Active Directory Administrators"} | Remove-ManagementRoleAssignment -WhatIf

3. Optional. If you want to remove all Exchange permissions from the Active Directory administrators, you
can remove the role group or USG in which they're members. For more information about how to remove
a role group, see Manage role groups.
For detailed syntax and parameter information, see Get-ManagementRoleAssignment or Remove-
ManagementRoleAssignment.

Switch from Active Directory split permissions to shared permissions

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Active Directory split permissions" entry in the Role management permissions
topic.
To switch from Active Directory split permissions to Exchange 2013 shared permissions, you must rerun Exchange
Setup to disable Active Directory split permissions in the Exchange organization, and then create role assignments
between a role group and the Mail Recipient Creation role and Security Group Creation and Membership role. In
the default shared permissions configuration, the Organization Management role group contains each of these
roles. Because of this, the Organization Management role group is in this procedure.

IMPORTANT
The setup.com command in this procedure makes changes to Active Directory. You must use an account that has the
permissions required to make these changes. This account might not be the same account that has permissions to create
role assignments using the New-ManagementRoleAssignment cmdlet. Use the account, or accounts, with the
permissions necessary to successfully complete each step in this procedure.

To switch from Active Directory split permissions to shared permissions, do the following:
1. From a Windows command shell, run the following command from the Exchange 2013 installation media
to disable Active Directory split permissions.

setup.exe /PrepareAD /ActiveDirectorySplitPermissions:false

2. From the Exchange Management Shell, run the following commands to add regular role assignments
between the Mail Recipient Creation role and Security Group Creation and Management role and the
Organization Management and Recipient Management role groups.

New-ManagementRoleAssignment "Mail Recipient Creation_Organization Management" -Role "Mail Recipient

Creation" -SecurityGroup "Organization Management"
New-ManagementRoleAssignment "Security Group Creation and Membership_Org Management" -Role "Security
Group Creation and Membership" -SecurityGroup "Organization Management"
New-ManagementRoleAssignment "Mail Recipient Creation_Recipient Management" -Role "Mail Recipient
Creation" -SecurityGroup "Recipient Management"

3. Restart the Exchange 2013 servers in your organization.

NOTE
If you have Exchange 2010 servers in your organization, you also need to restart those servers.

For detailed syntax and parameter information, see New -ManagementRoleAssignment.

 Messaging policy and compliance
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Email has become a reliable and ubiquitous communication medium for information workers in organizations of
all sizes. Messaging stores and mailboxes have become repositories of valuable data. It's important for
organizations to formulate messaging policies that dictate the fair use of their messaging systems, provide user
guidelines for how to act on the policies, and where required, provide details about the types of communication
that may not be allowed.
Organizations must also create policies to manage email lifecycle, retain messages for the length of time based
on business, legal, and regulatory requirements, preserve email records for litigation and investigation purposes,
and be prepared to search and provide the required email records to fulfill eDiscovery requests.
Leakage of sensitive information such as intellectual property, trade secrets, business plans, and personally
identifiable information (PII) collected or handled by your organization must also be protected.

Messaging policy and compliance in Exchange 2013

The following table provides an overview of the messaging policy and compliance features in Microsoft
Exchange Server 2013 and includes links to topics that will help you learn about and manage these features.

FEATURE DESCRIPTION RESOURCES

Messaging records management To comply with applicable Messaging records management

(MRM) regulations or meet legal or
business requirements,
organizations include email lifecycle
policies as part of their messaging
policy. Common questions that
should be addressed by these
policies include:
How long should messages
be retained?
Where should the
messages be retained?
Should all messages be
retained for the same
period?
Exchange 2013 includes MRM
features that allow you to
implement your organization's
email lifecycle policies. You can use
MRM to apply uniform retention
settings to all messages, use
custom retention policies to apply
a baseline retention setting for the
mailbox, and optionally allow users
to classify messages so that they
can be retained for a specified
duration.
FEATURE DESCRIPTION RESOURCES

In-Place Archiving In-Place Archiving helps you In-Place Archiving in Exchange

regain control of your 2013
organization's messaging data by
eliminating the need for personal
store (.pst) files and allowing users
to store messages in an archive
mailbox accessible in Outlook
2010 and later and Outlook Web
App.

In-Place Hold When a reasonable expectation of In-Place Hold and Litigation Hold
litigation exists, organizations are
required to preserve electronically
stored information (ESI), including
email that's relevant to the case.
In-Place Hold allows you to search
and preserve messages matching
query parameters. Messages are
protected from deletion,
modification, and tampering and
can be preserved indefinitely or for
a specified period.

In-Place eDiscovery In-Place eDiscovery allows you to In-Place eDiscovery

search mailbox data across your
Exchange organization, preview
search results, and copy them to a
Discovery mailbox.

Journaling Journaling can help your Journaling

organization respond to legal,
regulatory, and organizational
compliance requirements by
recording inbound and outbound
email communications. When
planning for messaging retention
and compliance, it's important to
understand journaling, how it fits
in your organization's compliance
policies, and how Exchange 2013
can help you secure journaled
messages.

Transport Rules Using Transport rules, you can look Mail flow or transport rules
for specific conditions for messages
that pass through your
organization and then take action
on them. Transport rules let you
apply messaging policies to email
messages, secure messages,
protect messaging systems, and
prevent information leakage.
FEATURE DESCRIPTION RESOURCES

Data Loss Prevention (DLP) DLP capabilities help you protect Data loss prevention
your sensitive data and inform
users of your policies and
regulations. DLP can also help you
prevent users from mistakenly
sending sensitive information to
unauthorized people. When you
configure DLP polices, you can
identify and protect sensitive data
by analyzing the content of your
messaging system, which includes
numerous associated file types. The
DLP policy templates supplied in
Exchange 2013 are based on
regulatory standards such as PII
and payment card industry data
security standards (PCI-DSS). DLP
is extensible, which allows you to
include other policies that
important to your organization.
Additionally, the new Policy Tips
capability allows you to inform
users about policy violations before
sensitive data is sent.

Information Rights Management Information Rights Management Information Rights Management

(IRM) (IRM) provides persistent online
and offline protection for email
messages and attachments using
Active Directory Rights
Management Services (AD RMS).

S/MIME Secure/Multipurpose Internet Mail S/MIME for message signing and

Extensions (S/MIME) allows people encryption
who have Office 365 mailboxes
and Exchange 2013 and Exchange
Online to help protect sensitive
information by sending signed and
encrypted email within their
organization. Administrators can
enable S/MIME for Office 365
mailboxes by synchronizing user
certificates between Office 365 and
their on-premises server and then
configuring Outlook Online to
support S/MIME.
FEATURE DESCRIPTION RESOURCES

Mailbox audit logging Because mailboxes can potentially Mailbox audit logging
contain sensitive, high business
impact (HBI) information and PII, Exchange auditing reports
it's important that you track who
logs on to the mailboxes in your
organization and what actions are
taken. It's especially important to
track access to mailboxes by users
other than the mailbox owner
(known as delegate users). Using
mailbox audit logging, you can log
mailbox access by mailbox owners,
delegates (including administrators
with full mailbox access
permissions), and administrators.

Administrator audit logging Administrator audit logs enable Administrator audit logging
you to keep a log of changes made
by administrators to Exchange
server and organization
configuration and to Exchange
recipients. You might use
administrator audit logging as part
of your change control process or
to track changes and access to
configuration and recipients for
compliance purposes.
 In-Place Archiving in Exchange 2013
6/14/2019 • 13 minutes to read • Edit Online

Applies to: Exchange Server 2013

In-Place Archiving helps you regain control of your organization's messaging data by eliminating the need for
personal store (.pst) files and allowing users to store messages in an archive mailbox accessible in
Microsoft Outlook 2010 and later and Microsoft Office Outlook Web App.
In Microsoft Exchange Server 2013, In-Place Archiving provides users with an alternate storage location in which
to store historical messaging data. An In-Place Archive is an additional mailbox (called an archive mailbox)
enabled for a mailbox user. Outlook 2007 and later and Outlook Web App users have seamless access to their
archive mailbox. Using either of these client applications, users can view an archive mailbox and move or copy
messages between their primary mailbox and the archive. In-Place Archiving presents a consistent view of
messaging data to users and eliminates the user overhead required to manage .pst files.
You can provision a user's archive on the same mailbox database as the user's primary mailbox, another mailbox
database on the same Mailbox server, or a mailbox database on another Mailbox server in the same Active
Directory site. In hybrid deployments of Exchange 2010 and later, you can also provision a cloud-based archive for
mailboxes located on your on-premises Mailbox servers.

Messaging data and .pst files

Outlook uses .pst files to store data locally on users' computers or network shares. Unlike offline store (.ost) files
(which are used by Outlook in Cached Exchange Mode to store a copy of the mailbox for offline access), .pst files
aren't synchronized with the user's Exchange mailbox. If a user moves messages to a .pst file, those messages are
removed from the mailbox.
Using .pst files to manage messaging data can result in the following issues:
Unmanaged files: Generally, .pst files are created by users and reside on their computers or network
shares. They aren't managed by your organization. As a result, users can create several .pst files containing
the same or different messages and store them in different locations, with no organizational control.
Increased discovery costs: Lawsuits and some business or regulatory requirements sometimes result in
discovery requests. Locating messaging data that resides in .pst files on users' computers can be a costly
manual effort. Because tracking unmanaged .pst files can be difficult, .pst data may be undiscoverable in
many cases. This could possibly expose your organization to legal and financial risks.
Inability to apply messaging retention policies: Messaging retention policies can't be applied to
messages located in .pst files. As a result, depending on business or applicable regulations, your
organization may not be in compliance.
Risk of data theft: Messaging data stored in .pst files is vulnerable to data theft. For example, .pst files are
often stored in portable devices such as laptops, removable hard drives, and portable media such as USB
drives, CDs, and DVDs.
Fragmented view of messaging data: Users who store information in .pst files don't get a uniform view
of their data. Messages stored in .pst files are generally available only on the computer where the .pst file
resides. As a result, if users access their mailboxes using Outlook Web App or Outlook on another
computer, the messages stored in their .pst files are inaccessible.
Client access to archive mailboxes
The following table lists the client applications that can be used to access archive mailboxes.

CLIENT ACCESS TO ARCHIVE MAILBOX

Outlook 2013, Outlook 2010, Outlook 2007, and Yes. Outlook 2013, Outlook 2010, Outlook 2007 and
Outlook Web App Outlook Web App users can copy or move items from
their primary mailbox to their archive mailbox, and can
also use retention policies to move items to the archive.

NOTE
Outlook 2010 and later and Outlook 2007 users can
also copy or move items from .pst files to their archive
mailbox. Outlook 2007 users require the Office 2007
Cumulative Update for February 2011. Some differences
in archive support exist between Outlook 2010 and later
and Outlook 2007. For more information, see Exchange
Team Blog article, see Yes Virginia, there is Exchange
2010 archive support in Outlook 2007.

Exchange ActiveSync No

NOTE
In-Place Archiving is a premium feature and requires an Exchange Enterprise client access license (CAL). For details about
how to license Exchange, see Exchange Server Licensing. For details about the versions of Outlook required to access an
archive mailbox, see License requirements for Personal Archive and retention policies.

Outlook doesn't create a local copy of the archive mailbox on a user's computer, even if it's configured to use
Cached Exchange Mode. Users can access an archive mailbox in online mode only.

Delegate access
Delegate access is when a user or set of users is provided access to another user's mailbox. There are several
scenarios for providing delegate access, including:
Providing one or more users with access to the mailbox of a user who is no longer employed by the
organization. In this case, users who may be given delegate access include the departed user's manager or
supervisor or another user who will assume the departed user's responsibilities.
Providing one or more users with access to a shared mailbox.
Providing executive assistants with access to the mailboxes of the executives they're assisting.
In Exchange 2013, when you assign Full Access permissions to a mailbox, the delegate to which you assign the
permissions can also access the user's archive. Delegates must use Outlook to access the mailbox, and they must
connect to an Exchange 2010 SP1 or later Client Access server for Autodiscover purposes. Autodiscover is an
Exchange service that provides configuration settings to automatically configure Outlook clients. When delegates
use Outlook to access an Exchange 2013 mailbox, both the primary mailbox and the archive to which they have
access are visible from Outlook.

Moving messages to the archive mailbox

There are several ways to move messages to archive mailboxes:
Move or copy messages manually: Mailbox users can manually move or copy messages from their
primary mailbox or a .pst file to their archive mailbox. The archive mailbox appears as another mailbox or
.pst file in Outlook and Outlook Web App.
Move or copy messages using Inbox rules: Mailbox users can create Inbox rules in Outlook or Outlook
Web App to automatically move messages to a folder in their archive mailbox. To learn more, see Learn
About Inbox Rules.
Move messages using retention policies: You can use retention policies to automatically move
messages to the archive. Users can also apply a personal tag to move messages to the archive. For details
about archive and retention policies, see Archive and retention policies later in this topic.

NOTE
Personal tags are available only in Outlook Web App and Outlook 2010 and later.

Import messages from .pst files: In Exchange 2013, you can use a mailbox import request to import
messages from a .pst file to a user's archive or primary mailbox. For details, see Mailbox import and export
requests. You can also use the PST Capture tool to search for .pst files on computers in your organization
and import .pst file data to users' archives.

Archive and retention policies

In Exchange 2013, you can apply archive policies to a mailbox to automatically move messages from a user's
primary mailbox to the archive mailbox after a specified period. Archive policies are implemented by creating
retention tags that use the Move to Archive retention action.
Messages are moved to a folder in the archive mailbox that has the same name as the source folder in the
primary mailbox. If a folder with the same name doesn't exist in the archive mailbox, it's created when the
Managed Folder Assistant moves a message. Re-creating the same folder hierarchy in the archive mailbox allows
users to find messages easily.
To learn more about retention policies, retention tags, and the Move to Archive retention action, see Retention
tags and retention policies.

Default MRM policy

Exchange 2013 Setup creates a default archive and retention policy named Default MRM Policy. This policy
contains retention tags that have the Move to Archive action, as shown in the following table.

NOTE
In Exchange 2010, the default archive and retention policy created by Exchange Setup is named Default Archive and
Retention Policy.

RETENTION TAG NAME TAG TYPE DESCRIPTION

 RETENTION TAG NAME TAG TYPE DESCRIPTION

Default 2 year move to archive Default (DPT) Messages are automatically moved
to the archive mailbox after two
years. Applies to items in the entire
mailbox that don't have a retention
tag applied explicitly or inherited
from the folder.

Personal 1 year move to archive Personal Messages are automatically moved

to the archive mailbox after one
year.

Personal 5 year move to archive Personal Messages are automatically moved

to the archive mailbox after five
years.

Personal never move to archive Personal Messages are never moved to the
archive mailbox.

Recoverable Items 14 days Recoverable Items Folder Messages are moved from the
move to archive Recoverable Items folder of the
user's primary mailbox to the
Recoverable Items folder of the
archive mailbox. Users attempting
to recover deleted items in the
archive must use the Recover
Deleted Items feature on the
archive mailbox.

If you enable an In-Place Archive for a mailbox user and the mailbox doesn't already have a retention policy
assigned, the default archive and retention policy is automatically assigned. After the Managed Folder Assistant
processes the mailbox, these tags become available to the user, who can then tag folders or messages to be
moved to the archive mailbox. By default, email messages from the entire mailbox are moved after two years.
Before provisioning archive mailboxes for your users, we recommend that you inform them about the archive
policies that will be applied to their mailbox and provide subsequent training or documentation to meet their
needs. This should include details about the following:
Functionality available within the archive, the default archive, and retention policies.
Information about when messages may be moved automatically to the archive.
Information about the folder hierarchy created in the archive mailbox.
How to apply personal tags (displayed in the Archive policy menu in Outlook and Outlook Web App).

NOTE
If you apply a retention policy to users who have an archive mailbox, the retention policy replaces the default MRM policy.
You can create one or more retention tags with the Move to Archive action, and then link the tags to the retention policy.
You can also add the default Move to Archive tags (which are created by Setup and linked to the Default MRM Policy) to
any retention policies you create.
For information about compliance and archiving in Outlook 2010 and later, see Plan for compliance and archiving
in Outlook 2010.

Archive quotas
Archive mailboxes are designed so that users can store historical messaging data outside their primary mailbox.
Often, users use .pst files due to low mailbox storage quotas and the restrictions imposed when these quotas are
exceeded. For example, users can be prevented from sending messages when their mailbox size exceeds the
Prohibit send quota. Similarly, users can be prevented from sending and receiving messages when their mailbox
size exceeds the Prohibit send and receive quota.
To eliminate the need for .pst files, you can provide an archive mailbox with storage limits that meet the user's
requirements. However, you may still want to retain some control of the storage quotas and growth of archive
mailboxes to help monitor costs and expansion.
To help with this control, you can configure archive mailboxes with an archive warning quota and an archive
quota. When an archive mailbox exceeds the specified archive warning quota, a warning event is logged in the
Application event log. When an archive mailbox exceeds the specified archive quota, messages are no longer
moved to the archive, a warning event is logged in the Application event log, and a quota message is sent to the
mailbox user. By default, in Exchange 2013, the archive warning quota is set to 45 gigabytes (GB ) and the archive
quota is set to 50 GB.
The following table lists the events logged and warning messages sent when the archive warning quota and
archive quota are met.

QUOTA EVENT ID TYPE SOURCE CATEGORY MESSAGE

Archive 10022 Warning MSExchange Managed The archive

warning MailboxAssist Folder mailbox
quota ants Assistant '<Display
Name>:
<GUID>:
<Mailbox
Database>:
<Server
FQDN>'
exceeded the
archive
warning
quota
'<Archive
warning
quota>'.
Archive
mailbox size
is '<Size>'
bytes.
 QUOTA EVENT ID TYPE SOURCE CATEGORY MESSAGE

Archive 8537 Warning MSExchangeI General The archive

quota S mailbox for
<Legacy
DN> has
exceeded the
maximum
archive
mailbox size.
You can't
copy or
move items
into the
archive
mailbox. All
message
retention
actions that
move items
to the
archive
mailbox will
fail, and the
primary
mailbox may
contain items
with expired
retention
tags until the
archive
mailbox is
within the
maximum
size limit. The
mailbox
owner
should be
notified
about the
condition of
the archive
mailbox.

In-Place Archives and other Exchange features

This section explains the functionality between In-Place Archives and various Exchange features:
Exchange Search: The ability to quickly search messages becomes even more critical with archive
mailboxes. For Exchange Search, there's no difference between the primary and archive mailbox. Content in
both mailboxes is indexed. Because the archive mailbox isn't cached on a user's computer (even when using
Outlook in Cached Exchange Mode), search results for the archive are always provided by Exchange
Search. When searching the entire mailbox in Outlook 2010 and later and Outlook Web App, search results
include the users' primary and archive mailbox.
In-Place eDiscovery: When a discovery manager performs an In-Place eDiscovery search, users' archive
mailboxes are also searched. There's no option to exclude archive mailboxes when creating a discovery
search from the Exchange admin center (EAC ). When using the Exchange Management Shell to create a
discovery search, you can exclude the archive by using the DoNotIncludeArchive switch. For details, see
New -MailboxSearch. To learn more, see In-Place eDiscovery.
 IMPORTANT
You can't use In-Place eDiscovery to search a disconnected mailbox.

In-Place Hold and litigation hold: When you put a mailbox on In-Place Hold or litigation hold, the hold
is placed on both the primary and the archive mailbox. To learn more about In-Place Hold and litigation
hold, see In-Place Hold and Litigation Hold.
Recoverable Items folder: The archive mailbox contains its own Recoverable Items folder and is subject
to the same Recoverable Items folder quotas as the primary mailbox. To learn more about recoverable
items, see Recoverable Items folder.
Archiving Lync content in Exchange: You can archive instant messaging conversations and shared
online meeting documents in the user's primary mailbox. The mailbox must reside on an Exchange 2013
Mailbox server and you must have Microsoft Lync 2013 deployed in your organization. For details, see
Integration with SharePoint and Lync.

Managing archive mailboxes

In Exchange 2013, creating and managing archive mailboxes is integrated with common mailbox management
tasks, including:
Creating an archive mailbox: You can create an archive mailbox when creating a mailbox, or you can
enable an archive mailbox for an existing mailbox. For details, see Manage In-Place Archives in Exchange
2013.
Moving an archive mailbox: You can move a user's archive mailbox to another mailbox database on the
same Mailbox server or to another server, independent of the primary mailbox. To move a user's archive
mailbox, you must create a mailbox move request. For details, see Manage on-premises moves.

IMPORTANT
Locating a user's mailbox and archive on different versions of Exchange Server is not supported.

Disabling an archive mailbox: You may want to disable a user's archive mailbox for troubleshooting
purposes or if you're moving the primary mailbox to a version of Exchange that doesn't support In-Place
Archiving. Disabling an archive is similar to disabling a primary mailbox. For details, see Manage In-Place
Archives in Exchange 2013. In on-premises deployments, a disabled archive mailbox is retained in the
mailbox database until the deleted mailbox retention period for that database is reached. During this
period, you can reconnect the archive to a mailbox user. When the deleted mailbox retention period is
reached, the disconnected archive mailbox is purged from the mailbox database.
Retrieving mailbox statistics and folder statistics: You can retrieve mailbox statistics and mailbox
folder statistics for a user's archive mailbox by using the Archive switch with the Get-MailboxStatistics and
Get-MailboxFolderStatistics cmdlets.
Test archive connectivity: In Exchange 2013, you can use the Test-ArchiveConnectivity cmdlet to test
connectivity to a specified user's on-premises or cloud-based archive.
 Manage In-Place Archives in Exchange 2013
6/6/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

In-Place Archiving helps you regain control of your organization's messaging data by eliminating the need for
personal store (.pst) files and allowing you to meet your organization's message retention and eDiscovery
requirements. With archiving enabled, users can store messages in an archive mailbox, which is accessible by
using Microsoft Outlook and Outlook Web App.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place Archive" entry in the Messaging policy and compliance
permissions topic.
It's not supported to have a user's primary mailbox reside on an older Exchange version than the user's
archive. If the user's primary mailbox is still on Exchange 2010, you must move it to Exchange 2013 at the
same time you move the archive to Exchange 2013.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Create a mailbox and enable an on-premises archive

Use the EAC
1. Navigate to Recipients > Mailboxes.
2. Click New > User mailbox.
3. On the New user mailbox page, in the Alias box, type an alias for the user.

NOTE
If you leave this box blank, the value you type in the User logon name box is used for the alias.

4. Select one of the following options:

Existing user: Click this button and then click Browse to open the Select User - Entire Forest
dialog box. This dialog box displays a list of Active Directory user accounts in the forest that aren't
mail-enabled or don't have Exchange mailboxes. Select the user account you want to mail-enable,
and then click OK. If you select this option, you don't have to provide user account information
because this information already exists in Active Directory.
 New user: Click this button to create a new user account in Active Directory and create a mailbox for
the user. If you select this option, you'll have to provide the required user account information.

NOTE
The Active Directory account that is associated with user mailboxes must reside in the same forest as the Exchange
server. To create a mailbox for a user account that resides in a trusted forest, you have to create a linked mailbox. For
details, see Manage linked mailboxes.

5. Click More options to configure the following settings.

Mailbox database: Click Browse to select a mailbox database in which to store the mailbox. If you
don't select a database, Exchange will automatically assign one.
Archive: Select this check box to create an archive mailbox for the mailbox. If you create an archive
mailbox, mailbox items will be moved automatically from the primary mailbox to the archive, based
on the default retention policy settings or those you define.
Click Browse to select a database that resides in the local forest to store the archive mailbox.
To learn more, see In-Place Archiving in Exchange 2013.
Address book policy: Use this list to select an address book policy (ABP ) for the mailbox. ABPs
contain a global address list (GAL ), an offline address book (OAB ), a room list, and a set of address
lists. When assigned to mailbox users, an ABP provides them with access to a customized GAL in
Outlook and Outlook Web App. To learn more, see Address book policies.
6. When you're finished, click Save to create the mailbox.

Use the Shell

This example creates the user Chris Ashton in Active Directory, creates the mailbox on mailbox database DB01,
and enables an archive. The password must be reset at the next logon. To set the initial value of the password, this
example creates a variable ($password), prompts you to enter a password, and assigns that password to the
variable as a SecureString object.

$password = Read-Host "Enter password" -AsSecureString

New-Mailbox -UserPrincipalName [email protected] -Alias chris -Archive -Database "DB01" -Name ChrisAshton -
OrganizationalUnit Users -Password $password -FirstName Chris -LastName Ashton -DisplayName "Chris Ashton"

For detailed syntax and parameter information, see New -Mailbox.

How do you know this worked?

To verify that you've successfully created a user mailbox with an on-premises archive, do one of the following:
In the EAC, navigate to Recipients > Mailboxes, and then select the new user mailbox from the list. In the
details pane, under In-Place Archive, confirm that it is set to Enabled. Click View details to view archive
properties, including archive status and the mailbox database in which it is created.
In the Shell, run the following command to display information about the new user mailbox and archive.

Get-Mailbox <Name> | FL Name,RecipientTypeDetails,PrimarySmtpAddress,*Archive*

In the Shell, use the Test-ArchiveConnectivity cmdlet to test connectivity to the archive. For an example
 of how to test archive connectivity, see the Examples section in Test-ArchiveConnectivity.

Enable an on-premises archive for existing mailbox

You can also create archives for existing users that have a mailbox but aren't archive-enabled. This is known as
enabling an archive for an existing mailbox.

Use the EAC

1. Navigate to Recipients > Mailboxes.
2. Select a mailbox.
3. In the details pane, under In-Place Archive, click Enable

TIP
You can also bulk-enable archives by selecting multiple mailboxes (use the Shift or Ctrl keys). After selecting multiple
mailboxes, in the details pane, click More options. Then, under Archive click Enable.

4. On the Create in-place archive page, click OK to have Exchange automatically select a mailbox database
for the archive or click Browse to specify one.

Use the Shell

This example enables the archive for Tony Smith's mailbox.

Enable-Mailbox "Tony Smith" -Archive

This example retrieves mailboxes in database DB01 that don't have an on-premises or cloud-based archive
enabled and don't have a name starting with DiscoverySearchMailbox. It pipes the result to the Enable-Mailbox
cmdlet to enable the archive for all mailboxes on mailbox database DB01.

Get-Mailbox -Database DB01 -Filter {ArchiveGuid -Eq $null -AND ArchiveDomain -eq $null -AND Name -NotLike
"DiscoverySearchMailbox*"} | Enable-Mailbox -Archive

For detailed syntax and parameter information, see Enable-Mailbox and Get-Mailbox.

How do you know this worked?

To verify that you've successfully enabled an on-premises archive for an existing mailbox, do one of the following:
In the EAC, navigate to Recipients > Mailboxes, and then select the mailbox from the list. In the details
pane, under In-Place Archive, confirm that it is set to Enabled. Click View details to view archive
properties, including archive status and the mailbox database in which it is created.
In the Shell, run the following command to display information about the new archive.

Get-Mailbox <Name> | FL Name,*Archive*

In the Shell, use the Test-ArchiveConnectivity cmdlet to test connectivity to the archive. For an example
of how to test archive connectivity, see Examples in Test-ArchiveConnectivity.
Disable an on-premises archive
You may want to disable a user's archive for troubleshooting purposes or if you're moving the mailbox to a version
of Exchange that doesn't support In-Place Archiving. If you disable an on-premises archive, all information in the
archive will be kept in the mailbox database until the mailbox retention time passes and the archive is permanently
deleted. (By default, Exchange keeps disconnected mailboxes, including archive mailboxes, for thirty days.)

IMPORTANT
Disabling the archive will remove the archive from the mailbox and mark it in the mailbox database for deletion.

If you want to reconnect the on-premises archive to that mailbox, you can use the Connect-Mailbox cmdlet with
the Archive parameter.

Use the EAC

1. Navigate to Recipients > Mailboxes.
2. Select a mailbox.
3. In the details pane, under In-Place Archive, click Disable.

TIP
You can also bulk-disable archives by selecting multiple mailboxes (use the Shift or Ctrl keys). After selecting multiple
mailboxes, in the details pane, click More options. Then, under Archive click Disable.

Use the Shell

This example disables the archive for Chris Ashton's mailbox. It doesn't disable the mailbox.

Disable-Mailbox -Identity "Chris Ashton" -Archive

For detailed syntax and parameter information, see Disable-Mailbox.

How do you know this worked?

To verify that you have successfully disabled an archive, do the following:
In the EAC, select the mailbox. Then, in the details pane check its archive status under In-Place Archive.
In the Shell, run the following command to check the archive properties for the mailbox user.

Get-Mailbox -Identity "Chris Ashton" | Format-List *Archive*

If the archive is disabled, the following values are returned for archive-related properties.

PROPERTY VALUE

ArchiveDatabase (for on-premises archives) <blank>

 PROPERTY VALUE

ArchiveState None

DisabledArchiveDatabase (for on-premises archives) <name of mailbox database>

DisabledArchiveGuid <guid of disabled archive>

Connect an on-premises archive

When you disable an archive mailbox, it becomes disconnected. A disconnected archive mailbox is retained in the
mailbox database for a specified amount of time. By default, Exchange retains disconnected archives for 30 days.
During this time, you can recover the archive by associating it with an existing mailbox. You can modify the deleted
mailbox retention period to retain a deleted mailbox or archive for a longer or shorter period.

WARNING
If you disable an archive for a user and then enable an archive for that same user, the user will get a new archive. The new
archive won't contain the data that was in the user's disconnected archive. If you want to reconnect a user to his or her
disconnected archive, you must perform this procedure.

NOTE
You can't use the EAC to connect a disconnected archive to a mailbox user.

Use the Shell

1. If you don't know the name of the archive, you can view it in the Shell by running the following command.
This example retrieves the mailbox database DB01, pipes it to the Get-MailboxStatistics cmdlet to
retrieve mailbox statistics for all mailboxes on the database, and then uses the Where-Object cmdlet to
filter the results and retrieve a list of disconnected archives. The command displays additional information
about each archive such as the GUID and item count.

Get-MailboxDatabase "DB01" | Get-MailboxStatistics | Where {($_.DisconnectDate -ne $null) -and

($_.IsArchiveMailbox -eq $true)} | Format-List

2. Connect the archive to the primary mailbox. This example connects Chris Ashton's archive to Chris
Ashton's primary mailbox and uses the GUID as the archive's identity.

Enable-Mailbox -ArchiveGuid "8734c04e-981e-4ccf-a547-1c1ac7ebf3e2" -ArchiveDatabase "DB01" -Identity

"Chris Ashton"

For detailed syntax and parameter information, see the following topics:
Get-MailboxDatabase
Get-MailboxStatistics
Enable-Mailbox
How do you know this worked?
To verify that you have successfully connected a disconnected archive to a mailbox user, run the following Shell
command to retrieve the mailbox user's archive properties and verify the values returned for the ArchiveGuid and
ArchiveDatabase properties.:

Get-Mailbox -Identity "Chris Ashton" | Format-List *Archive*

 Configure archive quotas for an In-Place Archive in
Exchange 2013
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In on-premises deployments, In-Place Archives are created with unlimited storage quotas by default. As a result,
you'll need to edit a mailbox's properties to set storage quotas for the archive. You can set the following quotas for
an archive:
Archive warning quota: When an In-Place Archive exceeds the specified archive warning quota, an event
is logged for the Exchange administrator and a warning message is sent to the mailbox user.
Archive quota: When an In-Place Archive exceeds the specified archive quota, messages are no longer
moved to the archive and a warning message is sent to the mailbox user.
To learn more about In-Place Archives, see In-Place Archiving in Exchange 2013.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes.
In the Exchange admin center (EAC ), you can use a drop-down list with fixed values to configure the archive
quota and archive warning quota. If you want to set either quota to a value that's not listed in the EAC, use
the Shell.
Configure the archive warning quota to a lower value than the archive quota. Depending on the rate of
archive growth for a user, the difference between the archive warning quota and the archive quota should
allow for sufficient time for the user to take appropriate actions, such as deleting items from the archive or
requesting that an administrator or IT helpdesk to raise the archive quota.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Recipient Provisioning Permissions" section in the Recipients Permissions
topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure the archive quota and archive warning quota
for a mailbox
1. Navigate to Recipients > Mailboxes
2. In the list view, select a mailbox,
3. In the details pane, under In-Place Archive, click View details.
4. In Archive Mailbox, use the Quota value (GB ) and Issue warning at (GB ) lists to select the desired
 values.
5. Click OK.

Use the Shell to configure the archive quota and archive warning quota
for a mailbox
This example sets Chris Ashton's mailbox archive quota to 10 gigabyte (GB ), at which time the user will receive a
warning message that the In-Place Archive is full and he will no longer be able to move items to the archive. This
example also sets the archive warning quota to 9.5 GB, at which time the user will receive a warning message that
the In-Place Archive is almost full.

Set-Mailbox -Identity "Chris Ashton" -ArchiveQuota 10GB -ArchiveWarningQuota 9.5GB

For detailed syntax and parameter information, see Set-Mailbox.

How do you know this worked?

To verify that you've successfully enabled an on-premises archive for an existing mailbox, do one of the following:
In the EAC, navigate to Recipients > Mailboxes and select the mailbox you want. In the details pane,
under In-Place Archive, click View Details and verify the archive's quota settings.
In the Shell, run the following command to display quota information about the archive.

Get-Mailbox <Name> | FL Name,Archive*Quota

 Archive Lync conversations and meeting content to
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In on-premises deployments, you can archive Lync 2013 content to Exchange 2013 mailboxes. This requires
placing a Litigation Hold or an In-Place Hold on the user's mailbox. When Lync content is permanently deleted by a
user whose mailbox is on hold, the archived Lync content is preserved in the Recoverable Items folder in the user's
mailbox. It's not visible to users but it's included in eDiscovery searches.
When you place a mailbox on Litigation Hold, all content types, including Lync items, are preserved. By default, this
is also the case when you create an In-Place Hold. However, if you want to use an In-Place Hold to preserve only
Lync items, you can use the select message types option from the In-Place eDiscovery & Hold wizard to select
Lync items, as shown in the screenshot below.

NOTE
You can also configure an In-Place Hold to exclude Lync items. For example, organizations may prefer to preserve instant
message and voice mail items for a shorter period of time than other types of content. To implement this type of hold policy,
you would create an In-Place Hold to preserve content for a long period of time (for example, 7 years) and exclude Lync items
from this hold. Then you would create another In-Place Hold with a shorter hold duration that preserves only Lync items.
You can also specify how long the content should be preserved. For more information about creating a hold with a specific
duration, see In-Place Hold and Litigation Hold.

See the following topics for step-by-step instructions for placing a user on hold:
 Create or remove an In-Place Hold
Place a mailbox on Litigation Hold
For additional management tasks related to archiving, see Manage In-Place Archives in Exchange 2013.

More information
Archiving of Lync content occurs on the server, independent of whether the user has Lync client configured
to save Lync IM conversations in the Conversation History folder.
Archiving of Lync content begins after the user is placed on Litigation Hold or In-Place Hold. To ensure
user's Lync communications are archived from the time their account is created, place the account on hold
immediately after it's created.
Additionally, in on-premises Exchange 2013 and Lync 2013 deployments:
You must configure OAuth authentication between Lync 2013 and Exchange 2013. For details, see
Integration with SharePoint and Lync.
You can also archive Lync 2013 content to Exchange 2013 regardless of whether a user is placed on hold.
This is done by configuring the user's Exchange Archiving Policy. Use the Set-CsUser cmdlet on Lync 2013
server to set the Lync user's ExchangeArchivingPolicy property to ArchivingToExchange .
For more details about archiving Lync content in on-premises deployments, see Planning for Archiving in
Lync 2013 documentation.
 Using OAuth authentication to support Archiving in
an Exchange hybrid deployment
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

If you're in an Exchange 2013 hybrid deployment and use Exchange Online Archiving (EOA) for Exchange Server,
you must configure OAuth authentication between your on-premises and Exchange Online organizations after
upgrading to Exchange 2013 Cumulative Update 5 (CU5). EOA allows you to have a cloud-based archive for your
users with on-premises mailboxes. In this scenario, the Messaging Records Management (MRM ) assistant on your
on-premises mailbox server applies archiving policies and moves messages automatically from a user's mailbox to
their cloud-based archive. In Exchange 2013 CU5, it uses OAuth authentication.
For step-by-step instructions for configuring OAuth authentication, see Configure OAuth authentication between
Exchange and Exchange Online organizations.

What is OAuth authentication?

OAuth authentication is a server-to-server authentication protocol that allows applications to authenticate to each
other. With OAuth authentication, user credentials and passwords are not passed from one computer to another.
Instead, authentication and authorization is based on the exchange of security tokens, which grant access to a
specific set of resources for a specific amount of time.
OAuth authentication typically involves three parties: a single authorization server and the two realms that need to
communicate with one another. Security tokens are issued by the authorization server (also known as a security
token server) to the two realms that need to communicate; these tokens verify that communications originating
from one realm should be trusted by the other realm. When using OAuth authentication between an on-premises
Exchange organization and Exchange Online, the function of the authorization server is provided by Azure Active
Directory Access Control Services (ACS ) in your Office 365 organization. For example, during a cross-premises
eDiscovery search, Azure Active Directory ACS issues tokens that verify that an administrator or compliance officer
from the Exchange on-premises organization is able to access mailboxes in the Exchange Online organization, and
vice-versa.

Configuring OAuth authentication to support Archiving

As previously stated, see Configure OAuth authentication between Exchange and Exchange Online organizations
for instructions to configure OAuth authentication to support Archiving in an Exchange hybrid deployment.
If OAuth isn't configured for your Exchange hybrid deployment, you can't use archive policies to automatically
move items from a user's primary mailbox in your on-premises organization to the user's cloud-based archive in
Exchange Online.

More information
You must also configure OAuth authentication to perform cross-premises eDiscovery searches of your on-
premises and cloud-based mailboxes in a single eDiscovery search. See Using OAuth authentication to
support eDiscovery in an Exchange hybrid deployment.
You can also configure OAuth authentication to allow other applications, such as SharePoint 2013 and Lync
Server 2013, to authenticate to Exchange 2013. For more information, see Configure OAuth authentication
with SharePoint 2013 and Lync 2013.
You can configure server-to-server authentication between Exchange 2013 and SharePoint 2013 so
administrators and compliance officers can use the eDiscovery Center in SharePoint 2013 to search
Exchange 2013 mailboxes. For more information, see Configure Exchange for SharePoint eDiscovery
Center.
You can configure an Exchange hybrid deployment using the Hybrid Configuration Wizard in Exchange
2013. For a customized, step-by-step hybrid deployment configuration checklist, see the Exchange Server
Deployment Assistant.
 In-Place Hold and Litigation Hold in Exchange 2013
6/14/2019 • 17 minutes to read • Edit Online

Applies to: Exchange Server 2013

When a reasonable expectation of litigation exists, organizations are required to preserve electronically stored
information (ESI), including email that's relevant to the case. This expectation often exists before the specifics of
the case are known, and preservation is often broad. Organizations may need to preserve all email related to a
specific topic or all email for certain individuals. Depending on the organization's electronic discovery
(eDiscovery) practices, the following measures can be adopted to preserve email:
End users may be asked to preserve email by not deleting any messages. However, users can still delete
email knowingly or inadvertently.
Automated deletion mechanisms such as messaging records management (MRM ) may be suspended. This
could result in large volumes of email cluttering the user mailbox, and thus impacting user productivity.
Suspending automated deletion also doesn't prevent users from manually deleting email.
Some organizations copy or move email to an archive to make sure it isn't deleted, altered, or tampered
with. This increases costs due to the manual efforts required to copy or move messages to an archive, or
third-party products used to collect and store email outside Exchange.
Failure to preserve email can expose an organization to legal and financial risks such as scrutiny of the
organization's records retention and discovery processes, adverse legal judgments, sanctions, or fines.
You can use In-Place Hold or Litigation Hold to accomplish the following goals:
Place user mailboxes on hold and preserve mailbox items immutably.
Preserve mailbox items deleted by users or automatic deletion processes such as MRM.
Use query-based In-Place Hold to search for and retain items matching specified criteria.
Preserve items indefinitely or for a specific duration.
Place a user on multiple holds for different cases or investigations.
Keep holds transparent from the user by not having to suspend MRM.
Enable In-Place eDiscovery searches of items placed on hold.

In-Place Hold scenarios

In previous versions of Exchange, the notion of legal hold is to hold all mailbox data for a user indefinitely or until
when hold is removed. In Exchange 2013, In-Place Hold includes a new model that allows you to specify the
following parameters:
What to hold: You can specify which items to hold by using query parameters such as keywords, senders
and recipients, start and end dates, and also specify the message types such as email messages or calendar
items that you want to place on hold.
How long to hold: You can specify a duration for items on hold.
Using this new model, In-Place Hold allows you to create granular hold policies to preserve mailbox items in the
following scenarios:
 Indefinite hold: The indefinite hold scenario is similar to Litigation Hold. It's intended to preserve
mailbox items so you can meet eDiscovery requirements. During the period of litigation or investigation,
items are never deleted. The duration isn't known in advance, so no end date is configured. To hold all mail
items indefinitely, you don't specify any query parameters or time duration when creating an In-Place
Hold.
Query-based hold If your organization preserves items based on specified query parameters, you can
use a query-based In-Place Hold. You can specify query parameters such as keywords, start and end dates,
sender and recipient addresses, and message types. After you create a query-based In-Place Hold, all
existing and future mailbox items (including messages received at a later date) that match the query
parameters are preserved.

IMPORTANT
Items that are marked as unsearchable, generally because of failure to index an attachment, are also preserved
because it can't be determined whether they match query parameters. For more details about unsearchable item,
see Unsearchable Items in Exchange eDiscovery.

Time-based hold: Both In-Place Hold and Litigation Hold allow you to specify a duration of time for
which to hold items. The duration is calculated from the date a mailbox item is received or created.
If your organization requires that all mailbox items be preserved for a specific period, you can create a
time-based hold. For example, consider a mailbox that's placed on a time-based In-Place Hold and has a
retention period set to 365 days. If an item in that mailbox is deleted after 300 days from the date it was
received, it's held for an additional 65 days before being permanently deleted. You can use a time-based In-
Place Hold in conjunction with a retention policy to make sure items are preserved for the specified
duration and permanently removed after that period.
You can use In-Place Hold to place a user on multiple holds. When a user is placed on multiple holds, the search
queries from any query-based hold are combined (with OR operators). In this case, the maximum number of
keywords in all query-based holds placed on a mailbox is 500. If there are more than 500 keywords, then all
content in the mailbox is placed on hold (not just that content that matches the search criteria). All content is held
until the total number of keywords is reduced to 500 or less.

In-Place Hold and Litigation Hold

Litigation Hold, the hold feature introduced in Exchange 2010 to preserve data for eDiscovery, is still available in
Exchange 2013. Litigation Hold uses the LitigationHoldEnabled property of a mailbox. Whereas In-Place Hold
provides granular hold capability based on query parameters and the ability to place multiple holds, Litigation
Hold only allows you to place all items on hold. You can also specify a duration period to hold items when a
mailbox is placed on Litigation Hold. The duration is calculated from the date a mailbox item is received or
created. If a duration isn't set, items are held indefinitely or until the hold is removed.
When a mailbox is placed on one or more In-Place Holds and on Litigation Hold (without a duration period) at
the same time, all items are held indefinitely or until the holds are removed. If you remove Litigation Hold and the
user is still placed on one or more In-Place Holds, items matching the In-Place Hold criteria are held for the
period specified in the hold settings. When you move a mailbox that's on Litigation Hold in Exchange 2010 to an
Exchange 2013 Mailbox server, the Litigation Hold setting continues to apply, ensuring that compliance
requirements are met during and after the move.
 NOTE
When you place a mailbox on In-Place Hold or Litigation Hold, the hold is placed on both the primary and the archive
mailbox. If you place an on-premises primary mailbox on hold in an Exchange hybrid deployment, the cloud-based archive
mailbox (if enabled) is also placed on hold.

For more information, see:

Place a mailbox on Litigation Hold
Place all mailboxes on hold

Placing a mailbox on In-Place Hold

Authorized users that have been added to the Discovery Management role-based access control (RBAC ) role
group or assigned the Legal Hold and Mailbox Search management roles can place mailbox users on In-Place
Hold. You can delegate the task to records managers, compliance officers, or attorneys in your organization's legal
department, while assigning the least privileges. To learn more about assigning the Discovery Management role
group, see Assign eDiscovery permissions in Exchange.

IMPORTANT
In Exchange 2010, the Legal Hold role provided users with sufficient permissions to place mailboxes on Litigation Hold. In
Exchange 2013, you can use the same permission to place mailboxes on an indefinite or time-based In-Place Hold.
However, to create a query-based In-Place Hold, the user must be assigned the Mailbox Search role. The Discovery
Management role group has both these roles assigned.

In Exchange 2013, In-Place Hold functionality is integrated with In-Place eDiscovery searches. You can use the In-
Place eDiscovery & Hold wizard in the Exchange admin center (EAC ) or the New-MailboxSearch and related
cmdlets in Exchange Management Shell to place a mailbox on In-Place Hold. To learn more about placing a
mailbox on In-Place Hold, see Create or remove an In-Place Hold.

NOTE
If you use Exchange Online Archiving to provision a cloud-based archive for your on-premises mailboxes, you must manage
In-Place Hold from your on-premises Exchange 2013 organization. Hold settings are automatically propagated to the
cloud-based archive using DirSync. As previously stated, when you put an on-premises mailbox on hold, the corresponding
cloud-based archive is also placed on hold.

Many organizations require that users be informed when they're placed on hold. Additionally, when a mailbox is
on hold, any retention policies applicable to the mailbox user don't need to be suspended. Because messages
continue to be deleted as expected, users may not notice they're on hold. If your organization requires that users
on hold be informed, you can add a notification message to the mailbox user's Retention Comment property
and use the RetentionUrl property to link to a web page for more information. Outlook 2010 and later displays
the notification and URL in the backstage area. You must use the Shell to add and manage these properties for a
mailbox.

Holds and the Recoverable Items folder

In-Place Hold and Litigation Hold uses the Recoverable Items folder to preserve items. The Recoverable Items
folder replaces the feature informally known as the dumpster in previous versions of Exchange. The Recoverable
Items folder is hidden from the default view of Outlook, Outlook Web App, and other email clients. To learn more
about the Recoverable Items folder, see Recoverable Items folder.
By default, when a user deletes a message from a folder other than the Deleted Items folder, the message is
moved to the Deleted Items folder. This is known as a move. When a user soft deletes an item (accomplished by
pressing the SHIFT and DELETE keys) or deletes an item from the Deleted Items folder, the message is moved to
the Recoverable Items folder, thereby disappearing from the user's view.
Items in the Recoverable Items folder are retained for the deleted item retention period configured on the user's
mailbox database. By default, the deleted item retention period is set to 14 days for mailbox databases. You can
also configure a storage quota for the Recoverable Items folder. This protects the organization from a potential
denial of service (DoS ) attack due to rapid growth of the Recoverable Items folder and therefore the mailbox
database. If a mailbox isn't placed on In-Place Hold or Litigation Hold, items are purged permanently from the
Recoverable Items folder on a first in, first out basis when the Recoverable Items warning quota is exceeded, or
the item has resided in the folder for a longer duration than the deleted item retention period.
The Recoverable Items folder contains the following subfolders used to store deleted items in various sites and
facilitate In-Place Hold and Litigation Hold:
Deletions: Items removed from the Deleted Items folder or soft-deleted from other folders are moved to
the Deletions subfolder and are visible to the user when using the Recover Deleted Items feature in
Outlook and Outlook Web App. By default, items reside in this folder until the deleted item retention
period configured for the mailbox database or the mailbox expires.
Purges: When a user deletes an item from the Recoverable Items folder (by using the Recover Deleted
Items tool in Outlook and Outlook Web App, the item is moved to the Purges folder. Items that exceed the
deleted item retention period configured on the mailbox database or the mailbox are also moved to the
Purges folder. Items in this folder aren't visible to users if they use the Recover Deleted Items tool. When
the mailbox assistant processes the mailbox, items in the Purges folder are purged from the mailbox
database. When you place the mailbox user on Litigation Hold, the mailbox assistant doesn't purge items in
this folder.
DiscoveryHold: If a user is placed on an In-Place Hold, deleted items are moved to this folder. When the
mailbox assistant processes the mailbox, it evaluates messages in this folder. Items matching the In-Place
Hold query are retained until the hold period specified in the query. If no hold period is specified, items are
held indefinitely or until the user is removed from the hold.
Versions: When a user placed on In-Place Hold or Litigation Hold, mailbox items must be protected from
tampering or modification by the user or a process. This is accomplished using a copy-on-write process.
When a user or a process changes specific properties of a mailbox item, a copy of the original item is saved
in the Versions folder before the change is committed. The process is repeated for subsequent changes.
Items captured in the Versions folder are also indexed and returned in In-Place eDiscovery searches. After
the hold is removed, copies in the Versions folder are removed by the Managed Folder Assistant.

ITEM TYPE PROPERTIES THAT TRIGGER COPY-ON-WRITE

Messages (IPM.Note*) Subject

Posts (IPM.Post*) Body
Attachments
Senders/Recipients
Sent/Received Dates

Items other than messages and posts Any change to a visible property, except the following:
Item location (when an item is moved between folders)
Item status change (read or unread)
Changes to retention tag applied to an item

Items in the default folder Drafts None (items in the Drafts folder are exempt from copy on
write)
 IMPORTANT
Copy-on-write is disabled for calendar items in the organizer's mailbox when meeting responses are received from
attendees and the tracking information for the meeting is updated. For calendar items and items that have a reminder set,
copy-on-write is disabled for the ReminderTime and ReminderSignalTime properties. Changes to these properties are not
captured by copy-on-write. Changes to RSS feeds aren't captured by copy-on-write.

Although the DiscoveryHold, Purges, and Versions folders aren't visible to the user, all items in the Recoverable
Items folder are indexed by Exchange Search and are discoverable using In-Place eDiscovery. After a mailbox
user is removed from In-Place Hold or Litigation Hold, items in the DiscoveryHold, Purges, and Versions folders
are purged by the Managed Folder Assistant.

Holds and mailbox quotas

Items in the Recoverable Items folder aren't calculated toward the user's mailbox quota. In Exchange, the
Recoverable Items folder has its own quota. For Exchange, the default values for the
RecoverableItemsWarningQuota and RecoverableItemsQuota mailbox properties are set to 20 GB and 30 GB
respectively. To modify these values for a mailbox database for Exchange Server 2013, use the Set-
MailboxDatabase cmdlet. To modify them for individual mailboxes, use the Set-Mailbox cmdlet.
When a user's Recoverable Items folder exceeds the warning quota for recoverable items (as specified by the
RecoverableItemsWarningQuota parameter), an event is logged in the Application event log of the Mailbox
server. When the folder exceeds the quota for recoverable items (as specified by the RecoverableItemsQuota
parameter), users won't be able to empty the Deleted Items folder or permanently delete mailbox items. Also
copy-on-write won't be able to create copies of modified items. Therefore, it's critical that you monitor
Recoverable Items quotas for mailbox users placed on In-Place Hold.
In Exchange Online, the quota for the Recoverable Items folder (in the user's primary mailbox) is automatically
increased to 100 GB when you place a mailbox on Litigation Hold or In-Place Hold. When the storage quota for
the Recoverable Items folder in the primary mailbox of a mailbox on hold is close to reaching its limit, you can do
the following things:
Enable the archive mailbox and turn on auto-expanding archiving: You can enable an unlimited
storage capacity for the Recoverable Items folder simply by enabling the archive mailbox and then turning
on the auto-expanding archiving feature in Exchange Online. This results in 100 GB for the Recoverable
Items folder in the primary mailbox and an unlimited amount of storage capacity for the Recoverable
Items folder in the user's archive. See how: Enable archive mailboxes in the Office 365 Security &
Compliance Center and Enable unlimited archiving in Office 365.
Notes:
After you enable the archive for a mailbox that's close to exceeding the storage quota for the
Recoverable Items folder, you might want to run the Managed Folder Assistant to manually trigger
the assistant to process the mailbox so that expired items are moved the Recoverable Items folder in
the archive mailbox. For instructions, see Step 4 in Increase the Recoverable Items quota for
mailboxes on hold.
Note that other items in the user's mailbox might be moved to the new archive mailbox. Consider
telling the user that this might happen after you enable the archive mailbox.
Create a custom retention policy for mailboxes on hold In addition to enabling the archive mailbox
and auto-expanding archiving for mailboxes on Litigation Hold or In-Place Hold, you might also want to
create a custom retention policy for mailboxes on hold. This let's you apply a retention policy to mailboxes
on hold that's different from the Default MRM Policy that's applied to mailboxes that aren't on hold. This
lets you to apply retention tags that are specifically designed for mailboxes on hold. This includes creating
 a new retention tag for the Recoverable Items folder.
For more information, see Increase the Recoverable Items quota for mailboxes on hold.

Holds and email forwarding

Users can use Outlook and Outlook Web App to set up email forwarding for their mailbox. Email forwarding lets
users configure their mailbox to forward email messages sent to their mailbox to another mailbox located in or
outside of their organization. Email forwarding can be configured so that any message sent to the original
mailbox isn't copied to that mailbox and is only sent to the forwarding address.
If email forwarding is set up for a mailbox and messages aren't copied to the original mailbox, what happens if
the mailbox is on hold?
If messages are forwarded to another mailbox and not copied to the original mailbox, they aren't captured and
copied to the Recoverable Items folder. That means forwarded messages won't be returned in an In-Place
eDiscovery search. To address this issue, Exchange 2013 organizations can consider removing the ability for users
to configure email forwarding.

Preserving archived Lync content

Exchange 2013, Microsoft Lync 2013 and Microsoft SharePoint 2013 provide an integrated preservation and
eDiscovery experience that allows you to preserve and search for items across the different data stores. Exchange
2013 allows you to archive Lync Server 2013 content in Exchange, removing the requirement of having a
separate SQL Server database to store archived Lync content. The integrated hold and eDiscovery capability in
SharePoint 2013 allows you to preserve and search data across all stores from a single console.
When you place an Exchange 2013 mailbox on In-Place Hold or Litigation Hold, Microsoft Lync 2013 content
(such as instant messaging conversations and files shared in an online meeting) are archived in the mailbox. If
you search the mailbox using the eDiscovery Center in Microsoft SharePoint 2013 or In-Place eDiscovery in
Exchange 2013, any archived Lync content matching the search query is also returned in search results. You can
also restrict the search to Lync content archived in the mailbox.
To enable archiving of Lync content in Exchange 2013 mailbox, you must configure Lync 2013 integration with
Exchange 2013. For details, see the following topics:
Planning for Archiving
Deploying Archiving

Deleting a mailbox on hold

If an administrator deletes a user account that has a mailbox, the Exchange Information store will eventually
detect that the mailbox is no longer connected to a user account and mark that mailbox for deletion, even if the
mailbox is on hold. If you want to retain the mailbox, you must do the following:
1. Instead of deleting the user account, disable the user account.
2. Change the properties of the mailbox to restrict its use and access to the mailbox. For example, set send
and receive quotas equal to 1, block who can send messages to the mailbox, and restrict who can access
the mailbox.
3. Retain the mailbox until all data has been expunged, or until preserving the data is no longer required.

Migrating mailboxes on hold from Exchange 2013 to Office 365

If you have an Exchange hybrid deployment, the following conditions are true when you move (onboard) an on-
premises Exchange 2013 mailbox to Exchange Online in Office 365:
If the on-premises mailbox is on Litigation Hold or In-Place Hold, the hold settings are preserved after the
mailbox is moved to Exchange Online.
If the on-premises mailbox is on Litigation Hold or In-Place Hold, any content in the Recoverable Items
folder is moved to the Exchange Online mailbox.

NOTE
Hold settings and content in the Recoverable Items folder are also preserved when you move (offboard) an Exchange
Online mailbox to your on-premises Exchange 2013 organization.

There are other ways to migrate on-premises email data to Office 365, such as using a Staged Exchange
migration or a Cutover Exchange migration.
A staged migration can be used to migrate mailboxes from Exchange 2003 or Exchange 2007 to Office
365. In these versions of Exchange, the Recoverable Items folder (and its functionality) doesn't exist. So
when you migrate Exchange 2003 or Exchange 2007 mailboxes to Office 365, there isn't any Recoverable
Items folder content to move.
A cutover migration can be used to migrate mailboxes from Exchange 2003, Exchange 2007, and Exchange
2010 to Office 365. As previously stated, Exchange 2003 and Exchange 2007 mailboxes don't have a
Recoverable Items folder that can be migrated. Because the Recover Items folder was introduced in
Exchange 2010, content in the Recoverable Items folder is migrated to Office 365 when you use a cutover
migration to migrate Exchange 2010 mailboxes.

TIP
For Exchange 2013 and Exchange 2010, an Exchange hybrid deployment is the recommended way to migrate on-premises
mailboxes to Office 365.
 Create or remove an In-Place Hold in Exchange 2013
5/30/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

An In-Place Hold preserves all mailbox content, including deleted items and original versions of modified items.
All such mailbox items are returned in an In-Place eDiscovery search. When you place an In-Place Hold on a
user's mailbox on, the contents in the corresponding archive mailbox (if it's enabled) are also placed on hold, and
returned in a eDiscovery search.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place Hold" entry in the Messaging Policy and Compliance Permissions
topic.
Depending on your Active Directory topology and replication latency, it may take up to an hour for an In-
Place Hold to take effect.
As previously explained, when you place an In-Place Hold on a user's mailbox, content in the user's archive
mailbox is also placed on hold. If you place an In-Place Hold on an on-premises primary mailbox in an
Exchange hybrid deployment, the cloud-based archive mailbox (if enabled) is also placed on hold.
If a user is placed on multiple In-Place Holds, the search queries from any query-based hold are combined
(with OR operators). In this case, the maximum number of keywords in all query-based holds placed on a
mailbox is 500. If there are more than 500 keywords, then all content in the mailbox is placed on hold (not
just that content that matches the search criteria). All content is held until the total number of keywords is
reduced to 500 or less.

Create an In-Place Hold

Use the EAC to create an In-Place Hold
1. Navigate to Compliance management > In-place eDiscovery & hold.
2. Click New .
3. In In-Place eDiscovery & Hold, on the Name and description page, type a name for the search and an
optional description, and then click Next.
4. On the Mailboxes and Public folders page, choose the content locations that you want to place on hold
and then click Next.
a. Search all mailboxes: You can't select this option to create an In-Place Hold. You can select this
option for In-Place eDiscovery searches, but to create an In-Place Hold, you must select the specific
mailboxes that you want to place on hold.
b. Don't search any mailboxes: Select this option when you're creating an In-Place Hold exclusively
for public folders.
c. Specify mailboxes to search: Select this option and then click Add to select the mailboxes or
distribution groups that you want to place on hold.
d. On the Search query page, complete the following fields, and then click Next:
Include all user mailbox content Click this button to place all content in selected
mailboxes on hold.
Filter based on criteria Click this button to specify search criteria, including keywords, start
and end dates, sender and recipient addresses, and message types. When you create a query-
based hold, only items that match the search criteria are preserved.

TIP
When you place public folders on In-Place Hold, email messages related to the public folder hierarchy
synchronization process are also preserved. This might result in thousands of hierarchy synchronization
related email items being preserved. These messages can fill up the storage quota for the Recoverable Items
folder on public folder mailboxes. To prevent this, you can create a query-based In-Place Hold and add the
following property:value pair to the search query: > NOT(subject:HierarchySync*) > The result is that
any message (related to the synchronization of the public folder hierarchy) that contains the phrase
"HierarchySync" in the subject line is not placed on hold.

e. On the In-Place Hold settings page, select the Place content matching the search query in
selected mailboxes on hold check box and then select one of the following options:
Hold indefinitely Click this button to place items returned by the search on an indefinite
hold. Items on hold will be preserved until you remove the mailbox from the search or
remove the search.
 Specify number of days to hold items relative to their received date Click this button
to hold items for a specific period. For example, you can use this option if your organization
requires that all messages be retained for at least seven years. You can use a time-based In-
Place Hold along with a retention policy to make sure items are deleted in seven years. To
learn more about retention polices, see Retention tags and retention policies.
Use the Shell to create an In-Place Hold
This example creates an In-Place Hold named Hold-CaseId012 and adds the mailbox [email protected] to the
hold.

IMPORTANT
If you don't specify additional search parameters for an In-Place Hold, all items in the specified source mailboxes are placed
on hold. If you don't specify the ItemHoldPeriod parameter, items are placed on hold indefinitely or until the mailbox is
either removed from hold or the hold is deleted.

New-MailboxSearch "Hold-CaseId012"-SourceMailboxes "[email protected]" -InPlaceHoldEnabled $true

For detailed syntax and parameter information, see New -MailboxSearch.

How do you know this worked?
To verify that you have successfully created the In-Place Hold, do one of the following:
Use the EAC to verify that the In-Place Hold is listed in the list view of the In-place eDiscovery & hold
tab.
Use the Get-MailboxSearch cmdlet to retrieve the mailbox search and check the search parameters. For
an example of how to retrieve a mailbox search, see the examples in Get-MailboxSearch.

Remove an In-Place Hold

IMPORTANT
In Exchange 2013, mailbox searches can be used for an In-Place Hold and In-Place eDiscovery. You can't remove a mailbox
search that's used for In-Place Hold. You must first disable the In-Place Hold by clearing the Place content matching the
search query in selected mailboxes on hold check box on the In-Place Hold settings page or by setting the
InPlaceHoldEnabled parameter to $false in the Shell. You can also remove a mailbox by using the SourceMailboxes
parameter specified in the search.

Use the EAC to remove an In-Place Hold

1. Navigate to Compliance management > In-Place eDiscovery & hold.
2. In the list view, select the In-Place Hold you want to remove and then click Edit .
3. In In-Place eDiscovery & Hold properties, on the In-Place Hold page, clear the Place content
matching the search query in selected mailboxes on hold, and then click Save.
4. Select the In-Place Hold again from the list view, and then click Delete .
5. In warning, click Yes to remove the search.
Use the Shell to remove an In-Place Hold
This example first disables In-Place Hold named Hold-CaseId012 and then removes the mailbox search.
 Set-MailboxSearch "Hold-CaseId012" -InPlaceHoldEnabled $false
Remove-MailboxSearch "Hold-CaseId012"

For detailed syntax and parameter information, see Set-Mailboxsearch.

How do you know this worked?
To verify that you have successfully removed an In-Place Hold, do one of the following:
Use the EAC to verify that the In-Place Hold doesn't appear in the list view of the In-place eDiscovery &
hold tab.
Use the Get-MailboxSearch cmdlet to retrieve all mailbox searches and check that the search you
removed is no longer listed. For an example of how to retrieve a mailbox search, see the examples in Get-
MailboxSearch.
 Place a mailbox on Litigation Hold in Exchange 2013
6/18/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Place a mailbox on Litigation Hold to preserve all mailbox content, including deleted items and original versions of
modified items. When you place a user' mailbox on Litigation Hold, content in the user's archive mailbox (if it's
enabled) is also placed on hold. Deleted and modified items are preserved for a specified period, or until you
remove the mailbox from Litigation Hold. All such mailbox items are returned in an In-Place eDiscovery search.

IMPORTANT
Litigation Hold preserves items in the Recoverable Items folder in the user's mailbox. Depending on number and size of
items deleted or modified, the size of the Recoverable Items folder of the mailbox may increase quickly. The Recoverable
Items folder is configured with a high quota by default. In Exchange Server 2013, we recommend that you monitor
mailboxes that are placed on Litigation Hold on a weekly basis to ensure they don't reach the limits of the Recoverable Items
quotas.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
The Litigation Hold setting may take up to 60 minutes to take effect.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place Hold" entry in the Messaging policy and compliance permissions
topic.
As previously explained, when you place a Litigation Hold on a user's mailbox, content in the user's archive
mailbox is also placed on hold. If you place a Litigation Hold on an on-premises primary mailbox in an
Exchange hybrid deployment, the cloud-based archive mailbox (if enabled) is also placed on hold.
Litigation Hold preserves deleted items and also preserves original versions of modified items until the
hold is removed. You can optionally specify a hold duration, which preserves a mailbox item for the
specified duration period. If you specify a hold duration period, it's calculated from the date a message is
received or a mailbox item is created. To preserve items that meet your specified criteria, use an In-Place
Hold to create a query-based hold. For details, see Create or remove an In-Place Hold.
Placing a Litigation Hold on a public folder mailbox isn't supported. You have to use In-Place Hold to place
a hold on public folders.

Use the EAC to place a mailbox on Litigation Hold

1. Go to Recipients > Mailboxes.
2. In the list of user mailboxes, click the mailbox that you want to place on Litigation Hold, and then click Edit
.
3. On the mailbox properties page, click Mailbox features.
4. Under Litigation hold: Disabled, click Enable to place the mailbox on Litigation Hold.
5. On the Litigation Hold page, enter the following optional information:
 Litigation hold duration (days): Use this box to specify how long mailbox items are held when the
mailbox is placed on Litigation Hold. The duration is calculated from the date a mailbox item is
received or created. If you leave this box blank, items are held indefinitely or until the hold is
removed. Use days to specify the duration.
Note: Use this box to inform the user their mailbox is on Litigation Hold. The note will appear in the
user's mailbox if they're using Outlook 2010 or later.
URL: Use this box to direct the user to a website for more information about Litigation Hold. This
URL appears in the user's mailbox if they are using Outlook 2010 or later.
6. Click Save on the Litigation Hold page, and then click Save on the mailbox properties page.

Use the Shell to place a mailbox on Litigation Hold indefinitely

This example places the mailbox [email protected] on Litigation Hold. Items in the mailbox are held
indefinitely or until the hold is removed.

Set-Mailbox [email protected] -LitigationHoldEnabled $true

NOTE
When you place a mailbox on Litigation Hold indefinitely (by not specifying a duration period), the value for the
LitigationHoldDuration property mailbox is set to Unlimited .

Use the Shell to place a mailbox on Litigation Hold and preserve items
for a specified duration
This example places the mailbox [email protected] on Litigation Hold and preserves items for 2555 days
(approximately 7 years).

Set-Mailbox [email protected] -LitigationHoldEnabled $true -LitigationHoldDuration 2555

Use the Shell to place all mailboxes on Litigation Hold for a specified
duration
Your organization may require that all mailbox data be preserved for a specific period of time. Before you place all
mailboxes in an organization on Litigation Hold, consider the following:
This example places all user mailboxes in the organization on Litigation Hold for one year (365 days).

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -

LitigationHoldEnabled $true -LitigationHoldDuration 365

The example uses the Get-Mailbox cmdlet to retrieve all mailboxes in the organization, specifies a recipient filter to
include all user mailboxes, and then pipes the list of mailboxes to the Set-Mailbox cmdlet to enable the Litigation
Hold and hold duration.
To place all user mailboxes on an indefinite hold, run the previous command but don't include the
LitigationHoldDuration parameter.
See the More information section for examples of using other recipient properties in a filter to include or exclude
one or more mailboxes.

Use the Shell to remove a mailbox from Litigation Hold

This example removes the mailbox [email protected] from Litigation Hold.

Set-Mailbox [email protected] -LitigationHoldEnabled $false

How do you know this worked?

To verify that you have successfully placed a mailbox on Litigation Hold, do the one of the following:
In the EAC:
1. Go to Recipients > Mailboxes.
2. In the list of user mailboxes, click the mailbox that you want to verify Litigation Hold settings for, and
then click Edit .
3. On the mailbox properties page, click Mailbox features.
4. Under Litigation hold, verify that hold is enabled.
5. Click View details to verify when the mailbox was placed on Litigation Hold and by whom. You can
also verify or change the values in the optional Litigation hold duration (days), Note, and URL
boxes.
In the Shell, run one of the following commands:

Get-Mailbox <name of mailbox> | Format-List LitigationHold*

or

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Format-List

Name,LitigationHold*

If a mailbox is placed on Litigation Hold indefinitely, the value for the LitigationHoldDuration property
mailbox is set to Unlimited .

More information
If your organization requires that all mailbox data has to preserved for a specific period of time, consider
the following before you place all mailboxes in an organization on Litigation Hold.
When you use the previous command to place a hold on all mailboxes in an organization (or a
subset of mailboxes matching a specified recipient filter) only mailboxes that exist at the time that
you run the command are placed on hold. If you create new mailboxes later, you have to run the
command again to place the new mailboxes on hold. If you create new mailboxes often, you can run
the command as a scheduled task as frequently as required.
Placing all mailboxes on Litigation Hold can significantly impact mailbox sizes. In an Exchange
Server 2013 organization, plan for adequate storage to meet your organization's preservation
requirements.
The Recoverable Items folder has its own storage limit, so items in the folder don't count towards the
 mailbox storage limit. As previously explained, preserving mailbox data for a long period of time will
result in growth of the Recoverable Items folder in a user's mailbox and archive.
In Exchange Server 2013, the default storage limit for the Recoverable Items folder is also 30 GB.
We recommend that you periodically monitor the size of this folder to ensure it doesn't reach the
limit. For more information, see Recoverable Items Folder.
The previous command to place a hold on all mailboxes uses a recipient filter that returns all user
mailboxes. You can use other recipient properties to return a list of specific mailboxes that you can then
pipe to the Set-Mailbox cmdlet to place a Litigation Hold on those mailboxes.
Here are some examples of using the Get-Mailbox and Get-Recipient cmdlets to return a subset of
mailboxes based on common user or mailbox properties. These examples assume that relevant mailbox
properties (such as CustomAttributeN or Department) have been populated.

Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'CustomAttribute15 -eq

"OneYearLitigationHold"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'Department -eq "HR"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'PostalCode -eq "98052"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'StateOrProvince -eq

"WA"'

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -ne "DiscoveryMailbox"}

You can use other user mailbox properties in a filter to include or exclude mailboxes. For details, see
Filterable Properties for the -Filter Parameter.
 Place all mailboxes on hold in Exchange 2013
5/30/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Your organization may require all mailbox data to be preserved for a specific period. You can use Litigation Hold or
In-Place Hold to meet this requirement. After you place a mailbox on Litigation Hold or In-Place Hold, mailbox
items that are modified or that are permanently deleted are preserved in the Recoverable Items folder. For more
information, see In-Place Hold and Litigation Hold.
Before you place all mailboxes in an organization on Litigation Hold or In-Place Hold, consider the following:
When you place mailboxes on hold, content in a user's archive mailbox (if it's enabled) is also placed on
hold.
Placing all mailboxes in an organization on hold can significantly impact mailbox sizes. In an Exchange
Server 2013 deployment, plan for adequate storage to meet your organization's preservation requirements.
Preserving mailbox data for a long duration will result in growth of the Recoverable Items folder in a user's
primary mailbox and archive mailbox. The Recoverable Items folder has its own storage limit, so items in
the folder don't count towards the mailbox storage limit. In Exchange Server 2013, the default storage limit
for the Recoverable Items folder is 30 GB. We recommend that you periodically monitor the size of this
folder to ensure it doesn't reach the limit. For more information, see Recoverable Items Folder.

Choosing between Litigation Hold and In-Place Hold

Here are some factors to consider when deciding the hold feature you should use to place all mailboxes in your
organization on hold.

YOU WANT TO... USE LITIGATION HOLD USE IN-PLACE HOLD

Use the EAC Yes Yes

For setting Litigation Hold, EAC is best However, you can't select more than
suited for quick one-off actions on a 500 source mailboxes in the EAC.
few mailboxes. We recommend using
the Shell for setting Litigation Hold for
all users in your organization.

Use the Shell Yes Yes

Place more than 10,000 mailboxes on Yes Yes; use multiple In-Place Holds
hold Litigation Hold is a mailbox property. You can use distribution groups to
You can place all mailboxes in an specify a maximum of 10,000 mailboxes
organization on hold by using the Set- in a single In-Place Hold. To place
Mailbox cmdlet. additional mailboxes on hold, you must
create additional In-Place Holds. This
will result in additional management
overhead. Using Litigation Hold placing
large numbers of mailboxes on hold is
simpler.
 YOU WANT TO... USE LITIGATION HOLD USE IN-PLACE HOLD

Place many different mailboxes on hold Yes Yes

for different periods. Litigation Hold is a mailbox property. If you're placing individual holds on
You can place each mailbox (or sets of thousands of mailboxes, we recommend
mailboxes) on hold for a different using Litigation Hold. If you're creating
duration. holds for specific events that involve
See the More information section for multiple users, use a single in-Place
examples of using recipient properties hold for the group of users.
in a filter so you can place a Litigation It's not recommended to create
Hold on a subset of mailboxes. separate In-place Holds for each
mailbox as this will create many In-Place
Hold queries that will be more difficult
to manage than Litigation Holds. A
large number of In-Place Hold objects
may also result in slow performance in
the EAC when refreshing, creating, or
modifying hold objects.

Automatically place new mailboxes on No No

hold You have to place a new mailbox on You have to add a new mailbox to an
Litigation Hold after it's created. You In-Place Hold, even if you specified a
can schedule the command or script to distribution group when you created
run as frequently as required to achieve the In-Place Hold. You can also
the same effect. schedule the command or script to run
as frequently as required to achieve the
same effect. We recommend that the
script check if an existing In-Place Hold
has already reached the 10,000 mailbox
limit, and then create a new In-Place
Hold if required.

Place all public folders on hold No Yes

Place all mailboxes on Litigation Hold

You can easily and quickly place all mailboxes on hold indefinitely or for a specified duration using the Shell. This
command places all mailboxes on hold for 2555 days (approximately 7 years).

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -

LitigationHoldEnabled $true -LitigationHoldDuration 2555

The example uses the Get-Mailbox cmdlet and a recipient filter to retrieve all user mailboxes in the organization,
and then pipes the list of mailboxes to the Set-Mailbox cmdlet to enable the Litigation Hold and specify a hold
duration. For more information, see Place a mailbox on Litigation Hold.

Place all mailboxes on In-Place Hold

You can use the EAC to select up to 500 mailboxes and place them on hold. For details, see Create or remove an
In-Place Hold.

TIP
To place more than 500 users on In-Place Hold, use the Shell. See New-MailboxSearch.

More information
When you place all mailboxes in your organization on hold, only the mailboxes that exist at the time you run
the command are placed on hold. If you create new mailboxes later, run the command again to place them
on hold. If you frequently create new mailboxes, you can run the command as a scheduled task as
frequently as required.
Placing mailboxes on hold preserves data by preventing deletion before the specified period and saving the
original version of a message before it's modified. It doesn't automatically delete messages after the
specified period. Combine Litigation Hold or In-Place Hold with a Retention Policy, which can automatically
delete messages after the specified period, to meet your organization's email retention requirements. See
Retention tags and retention policies for details.
The PowerShell command used in this topic to place a Litigation Hold on all mailboxes uses a recipient filter
that returns all user mailboxes. You can use other recipient properties to return a list of specific mailboxes
that you can then pipe to the Set-Mailbox cmdlet to place a Litigation Hold on those mailboxes.
Here are some examples of using the Get-Mailbox and Get-Recipient cmdlets to return a subset of
mailboxes based on common user or mailbox properties. These examples assume that relevant mailbox
properties (such as CustomAttributeN or Department) have been populated.

Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'CustomAttribute15 -eq

"OneYearLitigationHold"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'Department -eq "HR"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'PostalCode -eq "98052"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'StateOrProvince -eq "WA"'

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -ne "DiscoveryMailbox"}

You can use other user mailbox properties in a filter to include or exclude mailboxes. For details, see
Filterable Properties for the -Filter Parameter.
 Preserve Bcc and expanded distribution group
recipients for eDiscovery in Exchange 2013
5/30/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

In-Place Hold and Litigation Hold allow you to preserve mailbox content to meet regulatory compliance and
eDiscovery requirements. Information about recipients directly addressed in the To and Cc fields of a message is
included in all messages by default, but your organization may require the ability to search for and reproduce
details about all recipients of a message. This includes:
Recipients addressed using the Bcc field of a message: Bcc recipients are stored in the message in the
sender's mailbox, but not included in headers of the message delivered to recipients.
Expanded distribution group recipients: Recipients who receive the message because they're members
of a distribution group to which the message was addressed, either in the To, Cc or Bcc fields.
Exchange Server 2013 (Cumulative Update 7 and later versions) retain information about Bcc and expanded
distribution group recipients. You can search for this information by using an In-Place eDiscovery search in the
Exchange admin center (EAC ).

How Bcc recipients and expanded distribution group recipients are

preserved
As stated earlier, information about Bcc'ed recipients is stored with the message in the sender's mailbox. This
information is indexed and available to eDiscovery searches and holds.
Information about expanded distribution group recipients is stored with the message after you place a mailbox on
In-Place Hold or Litigation Hold. Distribution group membership is determined at the time the message is sent.
The expanded recipients list stored with the message is not impacted by changes to membership of the group after
the message is sent.

INFORMATION ABOUT... IS STORED IN... IS STORED BY DEFAULT? IS ACCESSIBLE TO...

To and Cc recipients Message properties in the Yes Sender, recipients, and

sender and recipients' compliance officers
mailboxes.

Bcc recipients Message property in the Yes Sender and compliance

sender's mailbox. officers

Expanded distribution group Message properties in the No. Expanded distribution Compliance officers
recipients sender's mailbox. group recipient information
is stored after a mailbox is
placed on In-Place Hold or
Litigation Hold

Searching for messages sent to Bcc and expanded distribution group

recipients
When searching for messages sent to a recipient, eDiscovery search results now include messages sent to a
distribution group that the recipient is a member of. The following table shows the scenarios where messages sent
to Bcc and expanded distribution group recipients are returned in eDiscovery searches.
Scenario 1: John is a member of the US -Sales distribution group. This table shows eDiscovery search results when
Bob sends a message to John directly or indirectly via a distribution group.

WHEN YOU SEARCH BOB'S MAILBOX FOR

MESSAGES SENT... AND THE MESSAGE IS SENT WITH... RESULTS INCLUDE MESSAGE?

To:John John on TO Yes

To:John US-Sales on TO Yes

To:US-Sales US-Sales on TO Yes

Cc:John John on CC Yes

Cc:John US-Sales on CC Yes

Cc:US-Sales US-Sales on CC Yes

Scenario 2: Bob sends an email to John (To/Cc) and Jack (Bcc directly, or indirectly via a distribution group). The
table below shows eDiscovery search results.

WHEN YOU SEARCH... FOR MESSAGES SENT... RESULTS INCLUDE MESSAGE? NOTES

Bob's mailbox To/Cc:John Yes Presents an indication that

Jack was Bcc'ed.

Bob's mailbox Bcc:Jack Yes Presents an indication that

Jack was Bcc'ed.

Bob's mailbox Bcc:Jack (via distribution Yes List of members of the

group) Bcc'ed distribution group,
expanded when the message
was sent, is visible in
eDiscovery search preview,
export and logs.

John's mailbox To/Cc:John Yes No indication of Bcc

recipients.

John's mailbox Bcc:Jack (directly or via No Bcc information is not stored

distribution group) in the message delivered to
recipients. You must search
the sender's mailbox.

Jack's mailbox To/Cc:John (directly or via Yes To/Cc information is included

distribution group) in message delivered to all
recipients.

Jack's mailbox Bcc:Jack (directly or via No Bcc information is not stored

distribution group) in the message delivered to
recipients. You must search
the sender's mailbox.
Frequently asked questions
Q. When and where is Bcc recipient information stored?
A. Bcc recipient information is preserved by default in the original message in sender's mailbox. If the Bcc recipient
is a distribution group, distribution group membership is only expanded if the sender's mailbox is on hold or
assigned to a retention policy.
Q. When and where is the list of expanded distribution group recipients stored?
A. Group membership is expanded at the time the message is sent. The list of expanded distribution group
members is stored in the original message in the sender's mailbox. The sender's mailbox must be on In-Place Hold,
Litigation Hold, or assigned to a retention policy.
Q. Can the To/Cc recipients see which recipients were Bcc'ed?
A. No. This information is not included in message headers, and isn't visible to To/Cc recipients. The sender can see
the Bcc field stored in the original message stored in their mailbox. Compliance officers can see this information
when searching the sender's mailbox.
Q. How can I ensure expanded distribution group recipients are always preserved?
A. To ensure expanded distribution group members are always preserved with a message, Place all mailboxes on
hold or create an organization-wide retention policy.
Q. Which types of groups are supported?
A. Distribution groups, mail-enabled security groups, and dynamic distribution groups are supported.
Q. Is there a limit on the number of distribution group recipients that are expanded and stored in the
message?
A. Up to 10,000 members of a distribution group is preserved.
Q. Are nested distribution groups supported?
A. Yes, 25 levels of nested distribution groups are expanded.
Q. Where is the Bcc and expanded distribution group recipient information visible?
A. Bcc and expanded distribution group recipients information is visible to Compliance officers when performing
an eDiscovery search. Bcc and expanded distribution group recipients are included in search results copied to a
Discovery mailbox or exported to a PST file and in the eDiscovery log included in search results. Bcc recipient
information is also available in search preview.
Q. What happens if a member of a distribution group is hidden from the organization's global address
list (GAL )?
A. There's no impact. If recipients are hidden from the GAL, they're still included in the list of recipients for the
expanded distribution group.
 In-Place eDiscovery in Exchange 2013
5/30/2019 • 26 minutes to read • Edit Online

Applies to: Exchange Server 2013

If your organization adheres to legal discovery requirements (related to organizational policy, compliance, or
lawsuits), In-Place eDiscovery in Microsoft Exchange Server 2013 can help you perform discovery searches for
relevant content within mailboxes. Exchange 2013 also offers federated search capability and integration with
Microsoft SharePoint 2013. Using the eDiscovery Center in SharePoint, you can search for and hold all content
related to a case, including SharePoint 2013 websites, documents, file shares indexed by SharePoint, mailbox
content in Exchange, and archived Lync 2013 content. You can also use In-Place eDiscovery in an Exchange hybrid
environment to search on-premises and cloud-based mailboxes in the same search.

IMPORTANT
In-Place eDiscovery is a powerful feature that allows a user with the correct permissions to potentially gain access to all
messaging records stored throughout the Exchange 2013 organization. It's important to control and monitor discovery
activities, including addition of members to the Discovery Management role group, assignment of the Mailbox Search
management role, and assignment of mailbox access permission to discovery mailboxes.

How In-Place eDiscovery works

In-Place eDiscovery uses the content indexes created by Exchange Search. Role Based Access Control (RBAC )
provides the Discovery Management role group to delegate discovery tasks to non-technical personnel, without
the need to provide elevated privileges that may allow a user to make any operational changes to Exchange
configuration. The Exchange admin center (EAC ) provides an easy-to-use search interface for non-technical
personnel such as legal and compliance officers, records managers, and human resources (HR ) professionals.
Authorized users can perform an In-Place eDiscovery search by selecting the mailboxes, and then specifying
search criteria such as keywords, start and end dates, sender and recipient addresses, and message types. After
the search is complete, authorized users can then select one of the following actions:
Estimate search results This option returns an estimate of the total size and number of items that will be
returned by the search based on the criteria you specified.
Preview search results This option provides a preview of the results. Messages returned from each
mailbox searched are displayed.
Copy search results This option lets you copy messages to a discovery mailbox.
Export search results After search results are copied to a discovery mailbox, you can export them to a
PST file.
Exchange Search
In-Place eDiscovery uses the content indexes created by Exchange Search. Exchange Search has been retooled to
use Microsoft Search Foundation, a rich search platform that comes with significantly improved indexing and
querying performance and improved search functionality. Because the Microsoft Search Foundation is also used
by other Office products, including SharePoint 2013, it offers greater interoperability and similar query syntax
across these products.
With a single content indexing engine, no additional resources are used to crawl and index mailbox databases for
In-Place eDiscovery when eDiscovery requests are received by IT departments.
In-Place eDiscovery uses Keyword Query Language (KQL ), a querying syntax similar to the Advanced Query
Syntax (AQS ) used by Instant Search in Microsoft Outlook and Outlook Web App. Users familiar with KQL can
easily construct powerful search queries to search content indexes.
For more information about the file formats indexed by Exchange search, see File Formats Indexed By Exchange
Search.

Discovery Management role group and management roles

For authorized users to perform In-Place eDiscovery searches, you must add them to the Discovery Management
role group. This role group consists of two management roles: the Mailbox Search Role, which allows a user to
perform an In-Place eDiscovery search, and the Legal Hold Role, which allows a user to place a mailbox on In-
Place Hold or litigation hold.
By default, permissions to perform In-Place eDiscovery-related tasks aren't assigned to any user or Exchange
administrators. Exchange administrators who are members of the Organization Management role group can add
users to the Discovery Management role group and create custom role groups to narrow the scope of a discovery
manager to a subset of users. To learn more about adding users to the Discovery Management role group, see
Assign eDiscovery permissions in Exchange.
 IMPORTANT
If a user hasn't been added to the Discovery Management role group or isn't assigned the Mailbox Search role, the In-Place
eDiscovery & Hold user interface isn't displayed in the EAC, and the In-Place eDiscovery cmdlets aren't available in the
Exchange Management Shell.

Auditing of RBAC role changes, which is enabled by default, makes sure that adequate records are kept to track
assignment of the Discovery Management role group. You can use the administrator role group report to search
for changes made to administrator role groups. For more information, see Search the role group changes or
administrator audit logs.

Custom management scopes for In-Place eDiscovery

You can use a custom management scope to let specific people or groups use In-Place eDiscovery to search a
subset of mailboxes in your Exchange 2013 organization. For example, you might want to let a discovery
manager search only the mailboxes of users in a specific location or department. You do this by creating a custom
management scope that uses a custom recipient filter to control which mailboxes can be searched. Recipient filter
scopes use filters to target specific recipients based on recipient type or other recipient properties.
For In-Place eDiscovery, the only property on a user mailbox that you can use to create a recipient filter for a
custom scope is distribution group membership. If you use other properties, such as CustomAttributeN,
Department, or PostalCode, the search fails when it's run by a member of the role group that's assigned the
custom scope. For more information, see Create a custom management scope for In-Place eDiscovery searches.

Integration with SharePoint Server

Exchange Server offers integration with SharePoint Server, allowing a discovery manager to use eDiscovery
Center in SharePoint to perform the following tasks:
Search and preserve content from a single location: An authorized discovery manager can search and
preserve content across SharePoint and Exchange, including Lync content such as instant messaging
conversations and shared meeting documents archived in Exchange mailboxes.
Case management: eDiscovery Center uses a case management approach to eDiscovery, allowing you to
create cases and search and preserve content across different content repositories for each case.
Export search results: A discovery manager can use eDiscovery Center to export search results. Mailbox
content included in search results is exported to a PST file.
SharePoint also uses Microsoft Search Foundation for content indexing and querying. Regardless of whether a
discovery manager uses the EAC or the eDiscovery Center to search Exchange content, the same mailbox content
is returned.
In on-premises deployments, before you can use eDiscovery Center in SharePoint to search Exchange mailboxes,
you must establish trust between the two applications. In Exchange 2013 and SharePoint 2013, this is done using
OAuth authentication. For details, see Configure Exchange for SharePoint eDiscovery Center. eDiscovery
searches performed from SharePoint are authorized by Exchange using RBAC. For a SharePoint user to be able
to perform an eDiscovery search of Exchange mailboxes, they must be assigned delegated Discovery
Management permission in Exchange. To be able to preview mailbox content returned in an eDiscovery search
performed using SharePoint eDiscovery Center, the discovery manager must have a mailbox in the same
Exchange organization.

eDiscovery in an Exchange hybrid deployment

To successfully perform cross-premises eDiscovery searches in an Exchange 2013 hybrid organization, you will
have to configure OAuth (Open Authorization) authentication between your Exchange on-premises and Exchange
Online organizations so that you can use In-Place eDiscovery to search on-premises and cloud-based mailboxes.
OAuth authentication is a server-to-server authentication protocol that allows applications to authenticate to each
other.
OAuth authentication supports the following eDiscovery scenarios in an Exchange hybrid deployment:
Search on-premises mailboxes that use Exchange Online Archiving for cloud-based archive mailboxes.
Search on-premises and cloud-based mailboxes in the same eDiscovery search.
Search on-premises mailboxes by using the eDiscovery Center in SharePoint Online.
For more information about the eDiscovery scenarios that require OAuth authentication to be configured in an
Exchange hybrid deployment, see Using Oauth Authentication to Support eDiscovery in an Exchange Hybrid
Deployment. For step-by-step instructions for configuring OAuth authentication to support eDiscovery, see
Configure OAuth Authentication Between Exchange and Exchange Online Organizations.

Discovery mailboxes
After you create an In-Place eDiscovery search, you can copy the search results to a target mailbox. The EAC
allows you to select a discovery mailbox as the target mailbox. A discovery mailbox is a special type of mailbox
that provides the following functionality:
Easier and secure target mailbox selection: When you use the EAC to copy In-Place eDiscovery search
results, only discovery mailboxes are made available as a repository in which to store search results. You
don't need to sort through a potentially long list of mailboxes available in the organization. This also
eliminates the possibility of a discovery manager accidentally selecting another user's mailbox or an
unsecured mailbox in which to store potentially sensitive messages.
Large mailbox storage quota: The target mailbox should be able to store a large amount of message
data that may be returned by an In-Place eDiscovery search. By default, discovery mailboxes have a
mailbox storage quota of 50 gigabytes (GB ). This storage quota can't be increased.
More secure by default: Like all mailbox types, a discovery mailbox has an associated Active Directory
user account. However, this account is disabled by default. Only users explicitly authorized to access a
discovery mailbox have access to it. Members of the Discovery Management role group are assigned Full
Access permissions to the default discovery mailbox. Any additional discovery mailboxes you create don't
have mailbox access permissions assigned to any user.
Email delivery disabled: Although visible in Exchange address lists, users can't send email to a discovery
mailbox. Email delivery to discovery mailboxes is prohibited by using delivery restrictions. This preserves
the integrity of search results copied to a discovery mailbox.
Exchange Setup creates one discovery mailbox with the display name Discovery Search Mailbox. You can use
the Shell to create additional discovery mailboxes. By default, the discovery mailboxes you create won't have any
mailbox access permissions assigned. You can assign Full Access permissions for a discovery manager to access
messages copied to a discovery mailbox. For details, see Create a discovery mailbox.
In-Place eDiscovery also uses a system mailbox with the display name SystemMailbox{e0dc1c29-89c3-4034-
b678-e6c29d823ed9} to hold In-Place eDiscovery metadata. System mailboxes aren't visible in the EAC or in
Exchange address lists. In on-premises organizations, before removing a mailbox database where the In-Place
eDiscovery system mailbox is located, you must move the mailbox to another mailbox database. If the mailbox is
removed or corrupted, your discovery managers are unable to perform eDiscovery searches until you re-create
the mailbox. For details, see Re-Create the Discovery System Mailbox.
Using In-Place eDiscovery
Users who have been added to the Discovery Management role group can perform In-Place eDiscovery searches.
You can perform a search using the web-based interface in the EAC. This makes it easier for non-technical users
such as records managers, compliance officers, or legal and HR professionals to use In-Place eDiscovery. You can
also use the Shell to perform a search. For more information, see Create an In-Place eDiscovery search

NOTE
In on-premises organizations, you can use In-Place eDiscovery to search mailboxes located on Exchange 2013 Mailbox
servers. To search mailboxes located on Exchange 2010 Mailbox servers, use Multi-Mailbox Search on an Exchange 2010
server. > > In a hybrid deployment, which is an environment where some mailboxes exist on your on-premises Mailbox
servers and some mailboxes exist in a cloud-based organization, you can perform In-Place eDiscovery searches of your
cloud-based mailboxes using the EAC in your on-premises organization. If you intend to copy messages to a discovery
mailbox, you must select an on-premises discovery mailbox. Messages from cloud-based mailboxes that are returned in
search results are copied to the specified on-premises discovery mailbox. To learn more about hybrid deployments, see
Exchange Server 2013 Hybrid Deployments.

The In-Place eDiscovery & Hold wizard in the EAC allows you to create an In-Place eDiscovery search and also
use In-Place Hold to place search results on hold. When you create an In-Place eDiscovery search, a search object
is created in the In-Place eDiscovery system mailbox. This object can be manipulated to start, stop, modify, and
remove the search. After you create the search, you can choose to get an estimate of search results, which
includes keyword statistics that help you determine query effectiveness. You can also do a live preview of items
returned in the search, allowing you to view message content, the number of messages returned from each
source mailbox and the total number of messages. You can use this information to further fine-tune your query if
required.
When satisfied with the search results, you can copy them to a discovery mailbox. You can also use the EAC or
Outlook to export a discovery mailbox or some of its content to a PST file.
When creating an In-Place eDiscovery search, you must specify the following parameters:
Name: The search name is used to identify the search. When you copy search results to a discovery
mailbox, a folder is created in the discovery mailbox using the search name and the timestamp to uniquely
identify search results in a discovery mailbox.
Mailboxes: You can choose to search all mailboxes in your Exchange 2013 organization or specify the
mailboxes to search. A user's primary and archive mailboxes are included in the search. If you also want to
use the same search to place items on hold, you must specify the mailboxes. You can specify a distribution
group to include mailbox users who are members of that group. Membership of the group is calculated
once when creating the search and subsequent changes to group membership are not automatically
reflected in the search.
Search query: You can either include all mailbox content from the specified mailboxes or use a search
query to return items that are more relevant to the case or investigation. You can specify the following
parameters in a search query:
Keywords: You can specify keywords and phrases to search message content. You can also use the
logical operators AND, OR, and NOT. Additionally, Exchange 2013 also supports the NEAR
operator, allowing you to search for a word or phrase that's in proximity to another word or phrase.
To search for an exact match of a multiple word phrase, you must enclose the phrase in quotation
marks. For example, searching for the phrase "plan and competition" returns messages that contain
an exact match of the phrase, whereas specifying plan AND competition returns messages that
contain the words plan and competition anywhere in the message.
 Exchange 2013 also supports the Keyword Query Language (KQL ) syntax for In-Place eDiscovery
searches.

NOTE
In-Place eDiscovery does not support regular expressions.

You must capitalize logical operators such as AND and OR for them to be treated as operators
instead of keywords. We recommend that you use explicit parenthesis for any query that mixes
multiple logical operators to avoid mistakes or misinterpretations. For example, if you want to
search for messages that contain either WordA or WordB AND either WordC or WordD, you must
use (WordA OR WordB ) AND (WordC OR WordD ).
Start and End dates: By default, In-Place eDiscovery doesn't limit searches by a date range. To
search messages sent during a specific date range, you can narrow the search by specifying the start
and end dates. If you don't specify an end date, the search will return the latest results every time
you restart it.
Senders and recipients: To narrow down the search, you can specify the senders or recipients of
messages. You can use email addresses, display names, or the name of a domain to search for items
sent to or from everyone in the domain. For example, to find email sent by or sent to anyone at
Contoso, Ltd, specify **@contoso.com** in the From or the To/cc field in the EAC. You can also
specify **@contoso.com** in the Senders or Recipients parameters in the Shell.
Message types: By default, all message types are searched. You can restrict the search by selecting
specific message types such as email, contacts, documents, journal, meetings, notes and Lync
content.
The following screenshot shows an example of a search query in the EAC.

When using In-Place eDiscovery, also consider the following:

Attachments: In-Place eDiscovery searches attachments supported by Exchange Search. For details, see
 Default Filters for Exchange Search. In on-premises deployments, you can add support for additional file
types by installing search filters (also known as an iFilter) for the file type on Mailbox servers.
Unsearchable items: Unsearchable items are mailbox items that can't be indexed by Exchange Search.
Reasons they can't be indexed include the lack of an installed search filter for an attached file, a filter error,
and encrypted messages. For a successful eDiscovery search, your organization may be required to include
such items for review. When copying search results to a discovery mailbox or exporting them to a PST file,
you can include unsearchable items. For more information, see Unsearchable Items in Exchange
eDiscovery.
Encrypted items: Because messages encrypted using S/MIME aren't indexed by Exchange Search, In-
Place eDiscovery doesn't search these messages. If you select the option to include unsearchable items in
search results, these S/MIME encrypted messages are copied to the discovery mailbox.
IRM -protected items: Messages protected using Information Rights Management (IRM ) are indexed by
Exchange Search and therefore included in the search results if they match query parameters. Messages
must be protected by using an Active Directory Rights Management Services (AD RMS ) cluster in the
same Active Directory forest as the Mailbox server. For more information, see Information Rights
Management.

IMPORTANT
When Exchange Search fails to index an IRM-protected message, either due to a decryption failure or because IRM
is disabled, the protected message isn't added to the list of failed items. If you select the option to include
unsearchable items in search results, the results may not include IRM-protected messages that could not be
decrypted. > > To include IRM-protected messages in a search, you can create another search to include messages
with .rpmsg attachments. You can use the query string attachment:rpmsg to search all IRM-protected messages
in the specified mailboxes, whether successfully indexed or not. This may result in some duplication of search results
in scenarios where one search returns messages that match the search criteria, including IRM-protected messages
that have been indexed successfully. The search doesn't return IRM-protected messages that couldn't be indexed. >
> Performing a second search for all IRM-protected messages also includes the IRM-protected messages that were
successfully indexed and returned in the first search. Additionally, the IRM-protected messages returned by the
second search may not match the search criteria such as keywords used for the first search.

De-duplication: When copying search results to a discovery mailbox, you can enable de-duplication of
search results to copy only one instance of a unique message to the discovery mailbox. De-duplication has
the following benefits:
Lower storage requirement and smaller discovery mailbox size due to reduced number of messages
copied.
Reduced workload for discovery managers, legal counsel, or others involved in reviewing search
results.
Reduced cost of eDiscovery, depending on the number of duplicate items excluded from search
results.

Estimate, preview, and copy search results

After an In-Place eDiscovery search is completed, you can view search result estimates in the Details pane in the
EAC. The estimate includes number of items returned and total size of those items. You can also view keyword
statistics, which returns details about number of items returned for each keyword used in the search query. This
information is helpful in determining query effectiveness. If the query is too broad, it may return a much bigger
data set, which could require more resources to review and raise eDiscovery costs. If the query is too narrow, it
may significantly reduce the number of records returned or return no records at all. You can use the estimates and
keyword statistics to fine-tune the query to meet your requirements.

NOTE
In Exchange 2013, keyword statistics also include statistics for non-keyword properties such as dates, message types, and
senders/recipients specified in a search query.

You can also preview the search results to further ensure that messages returned contain the content you're
searching for and further fine-tune the query if required. eDiscovery Search Preview displays the number of
messages returned from each mailbox searched and the total number of messages returned by the search. The
preview is generated quickly without requiring you to copy messages to a discovery mailbox.
After you're satisfied with the quantity and quality of search results, you can copy them to a discovery mailbox.
When copying messages, you have the following options:
Include unsearchable items: For details about the types of items that are considered unsearchable, see
the eDiscovery search considerations in the previous section.
Enable de-duplication: De-duplication reduces the dataset by only including a single instance of a
unique record if multiple instances are found in one or more mailboxes searched.
Enable full logging: By default, only basic logging is enabled when copying items. You can select full
logging to include information about all records returned by the search.
Send me mail when the copy is completed: An In-Place eDiscovery search can potentially return a
large number of records. Copying the messages returned to a discovery mailbox can take a long time. Use
this option to get an email notification when the copying process is completed. For easier access using
Outlook Web App, the notification includes a link to the location in a discovery mailbox where the
messages are copied.
For more information, see Copy eDiscovery Search Results to a Discovery Mailbox.

Export search results to a PST file

After search results are copied to a discovery mailbox, you can export the search results to a PST file.

After search results are exported to a PST file, you or other users can open them in Outlook to review or print
messages returned in the search results. For more information, see Export eDiscovery search results to a PST file.

Different search results

Because In-Place eDiscovery performs searches on live data, it's possible that two searches of the same content
sources and using the same search query can return different results. Estimated search results can also be
different from the actual search results that are copied to a discovery mailbox. This can happen even when
rerunning the same search within a short amount of time. There are several factors that can affect the consistency
of search results:
The continual indexing of incoming email because Exchange Search continuously crawls and indexes your
organization's mailbox databases and transport pipeline.
Deletion of email by users or automated processes.
Bulk importing large amounts of email, which takes time to index.
If you do experience dissimilar results for the same search, consider placing mailboxes on hold to preserve
content, running searches during off-peak hours, and allowing time for indexing after importing large amounts of
email.

Logging for In-Place eDiscovery searches

There are two types of logging available for In-Place eDiscovery searches:
Basic logging: Basic logging is enabled by default for all In-Place eDiscovery searches. It includes
information about the search and who performed it. Information captured about basic logging appears in
the body of the email message sent to the mailbox where the search results are stored. The message is
located in the folder created to store search results.
Full logging: Full logging includes information about all messages returned by the search. This
information is provided in a comma-separated value (.csv) file attached to the email message that contains
the basic logging information. The name of the search is used for the .csv file name. This information may
be required for compliance or record-keeping purposes. To enable full logging, you must select the Enable
full logging option when copying search results to a discovery mailbox in the EAC. If you're using the
Shell, specify the full logging option using the LogLevel parameter.

NOTE
When using the Shell to create or modify an In-Place eDiscovery search, you can also disable logging.

Besides the search log included when copying search results to a discovery mailbox, Exchange also logs cmdlets
used by the EAC or the Shell to create, modify or remove In-Place eDiscovery searches. This information is
logged in the admin audit log entries. For details, see Administrator Audit Logging.

In-Place eDiscovery and In-Place Hold

As part of eDiscovery requests, you may be required to preserve mailbox content until a lawsuit or investigation
is disposed. Messages deleted or altered by the mailbox user or any processes must also be preserved. In
Exchange 2013, this is accomplished by using In-Place Hold. For details, see In-Place Hold and Litigation Hold.
In Exchange 2013, you can use the new In-Place eDiscovery & Hold wizard to search items and preserve them
for as long as they're required for eDiscovery or to meet other business requirements. When using the same
search for both In-Place eDiscovery and In-Place Hold, be aware of the following:
You can't use the option to search all mailboxes. You must select the mailboxes or distribution groups.
You can't remove an In-Place eDiscovery search if the search is also used for In-Place Hold. You must first
disable the In-Place Hold option in a search and then remove the search.

Preserving mailboxes for In-Place eDiscovery

When an employee leaves an organization, it's a common practice to disable or remove the mailbox. After you
disable a mailbox, it is disconnected from the user account but remains in the mailbox for a certain period, 30
days by default. The Managed Folder Assistant does not process disconnected mailboxes and any retention
policies are not applied during this period. You can't search content of a disconnected mailbox. Upon reaching the
deleted mailbox retention period configured for the mailbox database, the mailbox is purged from the mailbox
database.
In on-premises deployments, if your organization requires that retention settings be applied to messages of
employees who are no longer in the organization or if you may need to retain an ex-employee's mailbox for an
ongoing or future eDiscovery search, do not disable or remove the mailbox. You can take the following steps to
ensure the mailbox can't be accessed and no new messages are delivered to it.
1. Disable the Active Directory user account using Active Directory Users & Computers or other Active
Directory or account provisioning tools or scripts. This prevents mailbox logon using the associated user
account.

IMPORTANT
Users with Full Access mailbox permission will still be able to access the mailbox. To prevent access by others, you
must remove their Full Access permission from the mailbox. For information about how to remove Full Access
mailbox permissions on a mailbox, see Manage permissions for recipients.

2. Set the message size limit for messages that can be sent from or received by the mailbox user to a very
low value, 1 KB for example. This prevents delivery of new mail to and from the mailbox. For details, see
Configure Message Size Limits for a Mailbox.
3. Configure delivery restrictions for the mailbox so nobody can send messages to it. For details, see
Configure message delivery restrictions for a mailbox.

IMPORTANT
You must take the above steps along with any other account management processes required by your organization, but
without disabling or removing the mailbox or removing the associated user account.

When planning to implement mailbox retention for messaging retention management (MRM ) or In-Place
eDiscovery, you must take employee turnover into consideration. Long-term retention of ex-employee mailboxes
will require additional storage on Mailbox servers and also result in an increase in Active Directory database
because it requires that the associated user account be retained for the same duration. Additionally, it may also
require changes to your organization's account provisioning and management processes.

In-Place eDiscovery limits and throttling policies

In Exchange 2013, the resources In-Place eDiscovery can consume are controlled using throttling policies.
The default throttling policy contains the following throttling parameters.

PARAMETER DESCRIPTION DEFAULT VALUE

 PARAMETER DESCRIPTION DEFAULT VALUE

DiscoveryMaxConcurrency The maximum number of In-Place 2

eDiscovery searches that can run at the Note: If an eDiscovery search is started
same time in your organization. while two previous searches are still
running, the third search won't be
queued and will instead fail. You have
to wait until one of the previous
searches finishes before you can
successfully start a new search.

DiscoveryMaxMailboxes The maximum number of mailboxes 5,000

that can be searched in a single In-
Place eDiscovery search.

DiscoveryMaxStatsSearchMailboxes The maximum number of mailboxes 100

that can be searched in a single In- Note: After you run an eDiscovery
Place eDiscovery search that still allows search estimate, you can view keyword
you to view keyword statistics. statistics. These statistics show details
about the number of items returned for
each keyword used in the search query.
If more than 100 source mailboxes are
included in the search, an error will be
returned if you try to view keyword
statistics.

DiscoveryMaxKeywords The maximum number of keywords 500

that can be specified in a single In-Place
eDiscovery search.

DiscoveryMaxSearchResultsPageSize The maximum number of items 200

displayed on a single page when
previewing In-Place eDiscovery search
results.

DiscoverySearchTimeoutPeriod The number of minutes that an In- 10 minutes

Place eDiscovery search will run before
it times out.

In Exchange Server 2013, you can change the default values for these parameters to suit your requirements or
create additional throttling policies and assign them to users with delegated Discovery Management permission.

In-Place eDiscovery documentation

The following table contains links to topics that will help you learn about and manage In-Place eDiscovery.

TOPIC DESCRIPTION

Assign eDiscovery permissions in Exchange Learn how to give a user access to use In-Place eDiscovery in
the EAC to search Exchange mailboxes. Adding a user to the
Discovery Management role group also allows the person to
use the eDiscovery Center in SharePoint 2013 to search
Exchange mailboxes.

Create a discovery mailbox Learn how to use the Shell to create a discovery mailbox and
assign access permissions.
 TOPIC DESCRIPTION

Create an In-Place eDiscovery search Learn how to create an In-Place eDiscovery search, and how
to estimate and preview eDiscovery search results.

Message properties and search operators for In-Place Learn which email message properties can be searched using
eDiscovery In-Place eDiscovery. The topic provides syntax examples for
each property, information about search operators such as
AND and OR, and information about other search query
techniques such as using double quotation marks (" ") and
prefix wildcards.

Start or stop an In-Place eDiscovery search Learn how to start, stop, and restart eDiscovery searches.

Modify an In-Place eDiscovery search Learn how to modify an existing eDiscovery search.

Copy eDiscovery Search Results to a Discovery Mailbox Learn how to copy the results of an eDiscovery search to a
discovery mailbox.

Export eDiscovery search results to a PST file Learn how to export the results of an eDiscovery search to a
PST file.

Create a custom management scope for In-Place eDiscovery Learn how to use custom management scopes to limit the
searches mailboxes that a discovery manager can search.

Remove an In-Place eDiscovery search Learn how to delete an eDiscovery search.

Search for and delete messages in Exchange 2013 Learn how to use the Search-Mailbox cmdlet to search for
and then delete email messages.

Reduce the size of a discovery mailbox in Exchange Use this process to reduce the size of a discovery mailbox
that's larger than 50 GB.

Delete and re-create the default discovery mailbox in Learn how to delete the default discovery mailbox, re-create
Exchange it, and then reassign permissions to it. Use this procedure if
this mailbox has exceeded the 50 GB limit and you don't need
the search results.

Re-Create the Discovery System Mailbox Learn how to recreate the discovery system mailbox. This task
is applicable only to Exchange 2013 organizations.

Using Oauth Authentication to Support eDiscovery in an Learn about the eDiscovery scenarios in an Exchange hybrid
Exchange Hybrid Deployment deployment that require you to configure OAuth
authentication.

Configure Exchange for SharePoint eDiscovery Center Learn how to configure Exchange 2013 so that you can use
the eDiscovery Center in SharePoint 2013 to search Exchange
mailboxes.

Unsearchable Items in Exchange eDiscovery Learn about mailbox items that can't be indexed by Exchange
Search and are returned in eDiscovery search results as
unsearchable items.

For more information about eDiscovery in Office 365, Exchange 2013, SharePoint 2013, and Lync 2013, see the
eDiscovery FAQ.
 Assign eDiscovery permissions in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

If you want users to be able to use Microsoft Exchange Server 2013 In-Place eDiscovery, you must first authorize
them by adding them to the Discovery Management role group. Members of the Discovery Management role
group have Full Access mailbox permissions for the Discovery mailbox that's created by Exchange Setup.
Cau t i on

Members of the Discovery Management role group can access sensitive message content. Specifically, these
members can use In-Place eDiscovery to search all mailboxes in your Exchange organization, preview messages
(and other mailbox items), copy them to a Discovery mailbox and export the copied messages to a .pst file. In most
organizations, this permission is granted to legal, compliance, or Human Resources personnel. >
To learn more about the Discovery Management role group, see Discovery Management. To learn more about
Role Based Access Control (RBAC ), see Understanding Role Based Access Control.
Interested in scenarios where this procedure is used? See the following topics:
Create an In-Place eDiscovery search
Create or remove an In-Place Hold

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Role groups" entry in the Role Management Permissions topic.
By default, the Discovery Management role group doesn't contain any members. Administrators with the
Organization Management role are also unable to create or manage discovery searches without being
added to the Discovery Management role group.
In Exchange 2013, members of the Organization Management role group can create an In-Place Hold and
Litigation Hold to place all mailbox content on hold. However, to create a query-based In-Place Hold, the
user must be a member of the Discovery Management role group or have the Mailbox Search role
assigned.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

Use the EAC to add a user to the Discovery Management role group
1. Go to Permissions > Admin roles.
2. In the list view, select Discovery Management and then click Edit
3. In Role Group, under Members, click Add .
4. In Select Members, select one or more users, click Add, and then click OK.
5. In Role Group, click Save.
Use the Shell to add a user to the Discovery Management role group
This example adds the user Bsuneja to the Discovery Management role group.

Add-RoleGroupMember -Identity "Discovery Management" -Member Bsuneja

For detailed syntax and parameter information, see Add-RoleGroupMember.

How do you know this worked?

To verify that you've added the user to the Discovery Management role group, do the following:
1. In the EAC, go to Permissions > Admin roles.
2. In the list view, select Discovery Management.
3. In the details pane, verify that the user is listed under Members.
You can also run this command to list the members of the Discovery Management role group.

Get-RoleGroupMember -Identity "Discovery Management"

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
 Create an In-Place eDiscovery search in Exchange
2013
6/26/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Use In-Place eDiscovery to search across all mailbox content, including deleted items and original versions of
modified items for users placed on In-Place Hold and Litigation Hold.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place eDiscovery" entry in the Messaging Policy and Compliance
Permissions topic.
To create eDiscovery searches, you have to have an SMTP address in the organization that you're creating
the searches in.
Exchange 2013 Setup creates a Discovery mailbox called Discovery Search Mailbox to copy search
results. You can create additional Discovery mailboxes. For details, see Create a discovery mailbox.
When you create an In-Place eDiscovery search, messages returned in search results aren't copied
automatically to a discovery mailbox. After you create the search, you can use the Exchange admin center
(EAC ) to estimate and preview search results or copy them to a discovery mailbox. For details, see:
Use the EAC to estimate or preview search results (later in this topic)
Copy eDiscovery search results to a discovery mailbox
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create an In-Place eDiscovery search

As previously explained, to create eDiscovery searches, you have to sign in to a user account that has an SMTP
address in your organization.
1. Go to Compliance management > In-place eDiscovery & hold.
2. Click New .
3. In In-Place eDiscovery & Hold, on the Name and description page, type a name for the search, add an
optional description, and then click Next.
4. On the Mailboxes page, select the mailboxes to search. You can search across all mailboxes or select
specific ones to search.
 IMPORTANT
You can't use the Search all mailboxes option to place all mailboxes on hold. To create an In-Place Hold, you must
select Specify mailboxes to search. For more details, see Create or remove an In-Place Hold.

5. On the Search query page, complete the following fields:

Include all user mailbox content Select this option to place all content in the selected mailboxes
on hold. If you select this option, you can't specify additional search criteria.
Filter based on criteria Select this option to specify search criteria, including keywords, start and
end dates, sender and recipient addresses, and message types.

NOTE
The From: and To/Cc/Bcc: fields are connected by an OR operator in the search query that's created when
you run the search. That means any message sent or received by any of the specified users (and matches the
other search criteria) is included in the search results. > The dates are connected by an AND operator.

6. On the In-place hold settings page, you can select the Place content matching the search query in
selected mailboxes on hold check box, and then select one of the following options to place items on In-
Place Hold:
Hold indefinitely Select this option to place the returned items on an indefinite hold. Items on hold
will be preserved until you remove the mailbox from the search or remove the search.
Specify number of days to hold items relative to their received date Use this option to hold
items for a specific period. For example, you can use this option if your organization requires that all
messages be retained for at least seven years. You can use a time-based In-Place Hold along with a
retention policy to make sure items are deleted in seven years.
 IMPORTANT
When placing mailboxes or items on In-Place Hold for legal purposes, it is generally recommended to hold
items indefinitely and remove the hold when the case or investigation is completed.

7. Click Finish to save the search and return an estimate of the total size and number of items that will be
returned by the search based on the criteria you specified. Estimates are displayed in the details pane. Click
Refresh to update the information displayed in the details pane.

Use the Shell to create an In-Place eDiscovery search

This example creates the In-Place eDiscovery search named Discovery-CaseId012 that searches for items
containing the keywords Contoso and ProjectA and that also meet the following criteria:
Start date: 1/1/2009
End date: 12/31/2011
Source mailbox: DG -Finance
Target mailbox: Discovery Search Mailbox
Message types: Email
Includes unsearchable items in the search statistics
Log level: Full

IMPORTANT
If you don't specify additional search parameters when running an In-Place eDiscovery search, all items in the specified
source mailboxes are returned in the results. If you don't specify mailboxes to search, all mailboxes in your Exchange
organization are searched.

New-MailboxSearch "Discovery-CaseId012" -StartDate "01/01/2009" -EndDate "12/31/2011" -SourceMailboxes "DG-

Finance" -TargetMailbox "Discovery Search Mailbox" -SearchQuery '"Contoso" AND "Project A"' -MessageTypes
Email -IncludeUnsearchableItems -LogLevel Full

NOTE
When using the StartDate and EndDate parameters, you have to use the date format of mm/dd/yyyy, even if your local
machine settings are configured to use a different date format, such as dd/mm/yyyy. For example, to search for messages
sent between April 1, 2013 and July 1, 2013, you would use 04/01/2013 and 07/01/2013 for the start and end dates.

This example creates an In-Place eDiscovery search named HRCase090116 that searches for email messages sent
by Alex Darrow to Sara Davis in 2015.

New-MailboxSearch "HRCase090116" -StartDate "01/01/2015" -EndDate "12/31/2015" -SourceMailboxes alexd,sarad -

SearchQuery 'From:[email protected] AND To:[email protected]' -MessageTypes Email -TargetMailbox "Discovery
Search Mailbox" -IncludeUnsearchableItems -LogLevel Full

After using the Shell to create an In-Place eDiscovery search, you have to start the search by using the Start-
MailboxSearch cmdlet to copy messages to the discovery mailbox specified in the TargetMailbox parameter. For
details, see Copy eDiscovery Search Results to a Discovery Mailbox.
For detailed syntax and parameter information, see New -MailboxSearch.

Use the EAC to estimate or preview search results

After you create an In-Place eDiscovery search, you can use the EAC to get an estimate and preview of the search
results. If you created a new search using the New-MailboxSearch cmdlet, you can use the Shell to start the
search to get an estimate of the search results. You can't use the Shell to preview messages returned in search
results.
1. Navigate to Compliance management > In-place eDiscovery & hold.
2. In the list view, select the In-Place eDiscovery search, and then do one of the following:
Click Search > Estimate search results to return an estimate of the total size and number of
items that will be returned by the search based on the criteria you specified. Selecting this option
restarts the search and performs an estimate.
Search Estimates are displayed in the details pane. Click Refresh to update the information
displayed in the details pane.
Click Preview search results in the details pane to preview the results after the search estimate is
completed. Selecting this option opens the eDiscovery search preview window. All messages returned
from the mailboxes that were searched are displayed.

NOTE
The mailboxes that were searched are listed in the right pane in the eDiscovery search preview window. For each
mailbox, the number of items returned and the total size of these items is also displayed. All items returned by the
search are listed in the right pane, and can be sorted by newest or oldest date. Items from each mailbox can't be
displayed in the right pane by clicking a mailbox in the left pane. To view the items returned from a specific mailbox,
you can copy the search results and view the items in the discovery mailbox.

Use the Shell to estimate search results

You can use the EstimateOnly switch to return only get an estimate of the search results and not copy the results
to a discovery mailbox. You have to start an estimate-only search with the Start-MailboxSearch cmdlet. Then
you can retrieve the estimated search results by using the Get-MailboxSearch cmdlet.
For example, you would run the following commands to create a new eDiscovery search and then display an
estimate of the search results:

New-MailboxSearch "FY13 Q2 Financial Results" -StartDate "04/01/2013" -EndDate "06/30/2013" -SourceMailboxes

"DG-Finance" -SearchQuery '"Financial" AND "Fabrikam"' -EstimateOnly -IncludeKeywordStatistics

Start-MailboxSearch "FY13 Q2 Financial Results"

Get-MailboxSearch "FY13 Q2 Financial Results"

To display specific information about the estimated search results from the previous example, you could run the
following command:

Get-MailboxSearch "FY13 Q2 Financial Results" | Format-List

Name,Status,LastRunBy,LastStartTime,LastEndTime,Sources,SearchQuery,ResultSizeEstimate,ResultNumberEstimate,Er
rors,KeywordHits

More information about eDiscovery searches

After you create a new eDiscovery search, you can copy search results to the discovery mailbox and export
those search results to a PST file. For more information, see:
Copy eDiscovery Search Results to a Discovery Mailbox
Export eDiscovery search results to a PST file
After you run an eDiscovery search estimate (that includes keywords in the search criteria), you can view
keyword statistics by clicking View keyword statistics in the details pane for the selected search. These
statistics show details about the number of items returned for each keyword used in the search query.
However, if more than 100 source mailboxes are included in the search, an error will be returned if you try
to view keyword statistics. To view keyword statistics, no more than 100 source mailboxes can be included
in the search.
 Copy eDiscovery search results to a discovery
mailbox
6/6/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

After you create an In-Place eDiscovery search, you can use the EAC to copy the results to a discovery mailbox.
You can also use the Shell to start an eDiscovery search that was created using the New-MailboxSearch cmdlet,
which will copy the results to the discovery mailbox that was specified when you created the search.

What do you need to know before you begin?

Estimated time to complete: 5 minutes or longer depending on the number of mailbox items returned in the
search results
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place eDiscovery" entry in the Messaging policy and compliance
permissions topic.
An eDiscovery search has to be created, by using the EAC or the Shell, before you can copy the search
results. For details, see Create an In-Place eDiscovery search.
Exchange 2013 Setup creates a discovery mailbox called Discovery Search Mailbox to copy search
results. You can create additional discovery mailboxes. For details, see Create a discovery mailbox.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to copy search results

1. In the EAC, go to Compliance management > In-place eDiscovery & hold.
2. In the list view, select an eDiscovery search.
3. Click Search , and then click Copy search results from the drop-down list.
4. In Copy Search Results, select from the following options:
Include unsearchable items: Select this check box to include mailbox items that couldn't be
searched (for example, messages with attachments of file types that couldn't be indexed by Exchange
Search). For more information, see Unsearchable items in Exchange eDiscovery.
Enable de-duplication: Select this check box to exclude duplicate messages. Only a single instance
of a message will be copied to the discovery mailbox.
Enable full logging: Select this check box to include a full log in search results.
Send me mail when the copy is completed: Select this check box to get an email notification
when the search is completed.
 Copy results to this discovery mailbox: Click Browse to select the discovery mailbox where you
want the search results copied to.

5. Click Copy to start the process to copy the search results to the specified discovery mailbox.
6. Click Refresh to update the information about the copying status that is displayed in the details pane.
7. When copying is complete, click Open to open the discovery mailbox to view the search results.

Use the Shell to copy search results

After using the New-MailboxSearch cmdlet to create an In-Place eDiscovery search, you must start the search to
copy messages to the discovery mailbox you specified in the TargetMailbox parameter. For information about
creating eDiscovery searches using the Shell, see:
Use the Shell to create an In-Place eDiscovery search
New -MailboxSearch
For example, you would run the following command to start an eDiscovery search named Fabrikam Investigation
to copy the search results to the specified discovery mailbox.

Start-MailboxSearch "Fabrikam Investigation"

If you used the EstimateOnly switch to get an estimate of the search results, you have to remove the switch before
you can copy the search results. You also have to specify a discovery mailbox to copy to search results to. For
example, say you created an estimate-only search by using the following command:

New-MailboxSearch "FY13 Q2 Financial Results" -StartDate "04/01/2013" -EndDate "06/30/2013" -SourceMailboxes

"DG-Finance" -SearchQuery '"Financial" AND "Fabrikam"' -EstimateOnly -IncludeUnsearchableItems

To copy the results of this search to a discovery mailbox, you would run the following commands:

Set-MailboxSearch "FY13 Q2 Financial Results" -EstimateOnly $false -TargetMailbox "Discovery Search Mailbox"

Start-MailboxSearch "FY13 Q2 Financial Results"

More information about copying search results

After you copy search results to the discovery mailbox, you can export those search results to a PST file. For
more information, see Export eDiscovery search results to a PST file.
For more information about unsearchable items, see Unsearchable items in Exchange eDiscovery.
If you're copying all mailbox content within a specific date range (by not specifying any keywords in the
search criteria), then all unsearchable items within that date range will be automatically included in the
search results. Therefore, don't select the Include unsearchable items checkbox when copying search
results. Otherwise, a duplicate copy of all unsearchable items will be copied to the discovery mailbox.
In addition to copying the search results to a discovery mailbox, you can also estimate or preview the search
results for a selected search.
Estimate search results: This option returns an estimate of the total size and number of items that
will be returned by the search based on the criteria you specified. Estimates are displayed in the
details pane in the EAC.
Preview search results: This option lets you preview the search results returned by the search
instead of having to copy them to a discovery mailbox to view. This lets you quickly determine
whether the search results are relevant. After you preview the results, you can revise your search
query to narrow the search results and rerun the search. Items in the preview page are read-only
versions of the actual search results, so you can't move, edit, delete or forward on the preview page.
For more information, see Estimate or preview search results.
 Export eDiscovery search results to a PST file in
Exchange 2013
5/30/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use the eDiscovery Export tool in the Exchange admin center (EAC ) to export the results of an In-Place
eDiscovery search to an Outlook Data File, which is also called a PST file. Administrators can distribute the results
of the search to other people within your organization, such as a human resources manager or records manager,
or to opposing counsel in a legal case. After search results are exported to a PST file, you or other users can open
them in Outlook to review or print messages returned in the search results. PST files can also be opened in third-
party eDiscovery and reporting applications. This topic shows you how to do this, as well as troubleshoot any
issues you might have.

What do you need to know before you begin?

Estimated time to complete: Time will vary based on the amount and size of the search results that will be
exported.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place eDiscovery" entry in the Messaging policy and compliance
permissions topic.
The computer you use to export search results to a PST file must meet the following system requirements:
32- or 64-bit versions of Windows 7 and later versions
Microsoft .NET Framework 4.7
A supported browser:
Internet Explorer 10 and later versions
OR
Mozilla Firefox or Google Chrome. If you use either of these browsers, be sure you install the
ClickOnce extension. To install the ClickOnce add-in, see Mozilla ClickOnce add-ons or ClickOnce
for Google Chrome.
You need an active mailbox attached to the account you wish to export.
Ensure that the local Intranet settings are setup correctly in Internet Explorer. Make sure that
https://*.outlook.com is added to the Local intranet zone.
Make sure the following URLS are not listed in the Trusted sites zone:
https://*.outlook.com
https://r4.res.outlook.com
https://*.res.outlook.com
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.
 TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Exchange admin center to export In-Place eDiscovery search

results to a PST
1. Go to Compliance management > In-place eDiscovery & hold.
2. In the list view, select the In-Place eDiscovery search you want to export the results of, and then click
Export to a PST file.

3. In the eDiscovery PST Export Tool window, do the following:

Click Browse to specify the location where you want to download the PST file.
Click the Enable deduplication checkbox to exclude duplicate messages. Only a single instance of
a message will be included in the PST file.
Click the Include unsearchable items checkbox to include mailbox items that couldn't be searched
(for example, messages with attachments of file types that couldn't be indexed by Exchange Search).
Unsearchable items are exported to a separate PST file.

IMPORTANT
Including unsearchable items when you export eDiscovery search results takes longer when mailboxes
contain a lot of unsearchable items. To reduce the time it takes to export search results and prevent large
PST export files, consider the following recommendations:
• Create multiple eDiscovery searches that each search a fewer number of source mailboxes.
• If you're exporting all mailbox content within a specific date range (by not specifying any keywords in the
search criteria), then all unsearchable items within that date range will be automatically included in the search
results. Therefore, don't select the Include unsearchable items checkbox.

4. Click Start to export the search results to a PST file.

A window is displayed that contains status information about the export process.

More information
You can reduce the size of the PST export file by exporting only the unsearchable items. To do this, create or
edit a search, specify a start date in the future, and then remove any keywords from the Keywords box.
This will result in no search results being returned. When you copy or export the search results and select
the Include unsearchable items checkbox, only the unsearchable items will be copied to the discovery
 mailbox or exported to a PST file.
If you enable de-duplication, all search results are exported in a single PST file. If you don't enable de-
duplication, a separate PST file is exported for each mailbox included in the search. And as previously
stated, unsearchable items are exported to a separate PST file.
In addition to the PST files that contain the search results, two other files are also exported:
A configuration file (.txt file format) that contains information about the PST export request, such as
the name of the eDiscovery search that was exported, the date and time of the export, whether de-
duplication and unsearchable items were enabled, the search query, and the source mailboxes that
were searched.
A search results log (.csv file format) that contains an entry for each message returned in the search
results. Each entry identifies the source mailbox where the message is located. If you've enabled de-
duplication, this helps you identify all mailboxes that contain a duplicate message.
The name of the search is the first part of the filename for each file that is exported. Also, the date and time
of the export request is appended to the filename of each PST file and the results log.
For more information about de-duplication and unsearchable items, see:
Estimate, preview, and copy search results
Unsearchable Items in Exchange eDiscovery
To export eDiscovery search results from the eDiscovery Center in SharePoint, see Export eDiscovery
content and create reports.

Troubleshooting
SYMPTOM POSSIBLE CAUSE

Cannot export to a PST file. There is no active mailbox attached to the account. To export
the PST, you must have an active account.
Your version of Internet Explorer is out of date. Try updating
IE to version 10 or later. Or try a different browser.
Search criteria entered in the Filter based on criteria query
is incorrect. For example, a username is entered instead of an
email address. For more information about how to filter based
on criteria, see Modify an In-Place eDiscovery search.

Unable to export search results on a specific machine. Export The wrong Windows credentials were saved in the Credential
works as expected on a different machine. Manager. Clear your credentials and log in again.

eDiscovery PST Export Tool won't start. Local intranet zone settings aren't set up correctly in Internet
Explorer. Make sure that *.outlook.com, *.office365.com,
*.sharepoint.com and *.onmicrosoft.com are added to the
Local intranet zone trusted sites.
To add these sites to the Trusted zone in IE, see Security
zones: adding or removing websites.
 Create a discovery mailbox in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 Setup creates a discovery mailbox by default. Discovery mailboxes are used as
target mailboxes for In-Place eDiscovery searches in the Exchange admin center (EAC ). You can create additional
discovery mailboxes as required. After you create a new discovery mailbox, you will have to assign Full Access
permissions to the appropriate users so they can access eDiscovery search results that are copied to the discovery
mailbox.
Cau t i on

After a discovery manager copies the results of an eDiscovery search to a discovery mailbox, the mailbox can
potentially contain sensitive information. You should control access to discovery mailboxes and make sure only
authorized users can access them.
For more information, see Discovery mailboxes.

What do you need to know before you begin?

Estimated time to complete: 3 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Creating discovery mailboxes" entry in Messaging policy and compliance
permissions topic.
Discovery mailboxes have a mailbox storage quota of 50 gigabytes (GB ). This storage quota can't be
increased.
You can't use the EAC to create a discovery mailbox or assign permissions to access it. You have to use the
Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Create a discovery mailbox

This example creates a discovery mailbox named SearchResults in the Shell.

New-Mailbox -Name SearchResults -Discovery

For detailed syntax and parameter information, see New -Mailbox.

To display a list of all discovery mailboxes in an Exchange organization, run the following command:

Get-Mailbox -Resultsize unlimited -Filter {RecipientTypeDetails -eq "DiscoveryMailbox"}

For detailed syntax and parameter information, see Get-Mailbox.

Step 2: Assign permissions to a discovery mailbox

You have to explicitly assign users or groups the necessary permissions to open a discovery mailbox that you've
created. Use the following syntax to assign a user or group permissions to open a discovery mailbox and view
search results:

Add-MailboxPermission <Name of the discovery mailbox> -User <Name of user or group> -AccessRights FullAccess -
InheritanceType all

For example, the following command assigns the Full Access permission to the Litigation Managers group, so
members of the group can open the Fabrikam Litigation discovery mailbox.

Add-MailboxPermission "Fabrikam Litigation" -User "Litigation Managers" -AccessRights FullAccess -

InheritanceType all

For detailed syntax and parameter information, see Add-MailboxPermission.

More information
By default, members of the Discovery Management role group only have Full Access permission to the
default Discovery Search Mailbox. You will have to explicitly assign the Full Access permission to the
Discovery Management role group if you want members to open a discovery mailbox that you've created.
Although visible in Exchange address lists, users can't send email to a discovery mailbox. Email delivery to
discovery mailboxes is prohibited with delivery restrictions. This preserves the integrity of search results
copied to a discovery mailbox.
A discovery mailbox can't be repurposed or converted to another type of mailbox.
You can remove a discovery mailbox as you would any other type of mailbox.
 Start or stop an In-Place eDiscovery search in
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can stop or restart an In-Place eDiscovery search at any time. For example, if you want to modify search
properties such as keywords or mailboxes searched, you must first stop a search. You can then restart the search
after making the required changes.
Cau t i on

If you restart an In-Place eDiscovery search, search results copied to the Discovery mailbox specified in the search
are removed.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place eDiscovery" entry in Messaging Policy and Compliance
Permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to start or stop an In-Place eDiscovery search

1. Navigate to Compliance management > In-place eDiscovery & hold.
2. To stop a search that's in progress, select the search, and then click Stop search.
3. To start a search that was stopped, select the search, and then click Resume search.

Use the Shell to start or stop an In-Place eDiscovery search

For an example of how to start an In-Place eDiscovery search, see "Example 1" in Start-MailboxSearch.
For an example of how to stop an In-Place eDiscovery search, see "Example 1" in Stop-MailboxSearch.
 Modify an In-Place eDiscovery search in Exchange
2013
6/26/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

After you create an In-Place eDiscovery search, you can modify it to change the search parameters. For example,
you can change the mailboxes to be searched, date ranges, key words, logging options, or you can specify a
different Discovery mailbox to store search results. Any changes you make to the search properties will be used
when you restart the search.
Cau t i on

If an In-Place eDiscovery search is running, you must stop it before modifying it. When you restart the search, the
results from the last time the search was run are removed from the Discovery mailbox. However, the logs from
previous searches are saved.

What do you need to know before you begin?

Estimated time to complete: 2-5 minutes.
An In-Place eDiscovery search has been created and isn't running.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place eDiscovery" entry in the Messaging Policy and Compliance
Permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

Use the EAC to modify an In-Place eDiscovery search

1. Navigate to Compliance management > In-place eDiscovery & hold.
2. In the list view, select the In-Place eDiscovery search you want to modify, and then click Edit .
3. In In-Place eDiscovery & Hold, you can modify the following settings:
On Name page, modify the name for the search and the optional description.
On the Mailboxes page, modify the mailboxes to search. You can search across all mailboxes or
select specific ones to search.

IMPORTANT
You can't use the Search all mailboxes option to place all mailboxes on Exchange 2013 Mailbox servers on
hold. To create an In-Place Hold, you must select Specify mailboxes to search. For more details, see Create
or remove an In-Place Hold.

On the Search query page, modify the following fields:

Include all user mailbox content Select this option to place all content in the selected mailboxes
on hold.
 Filter based on criteria Select this option to specify search criteria, including keywords, start and
end dates, sender and recipient addresses, and message types.
On the In-Place Hold page, select the Place content matching the search query in selected
mailboxes on hold check box, and then select one of the following options to place items on In-
Place Hold:
Hold indefinitely Select this option to place the returned items on an indefinite hold. Items on hold
will be preserved until you remove the mailbox from the search or remove the search.
Specify number of days to hold items relative to their received date Use this option to hold
items for a specific period. For example, you can use this option if your organization requires that all
messages be retained for at least seven years. You can use a time-based In-Place Hold along with a
retention policy to make sure items are deleted in seven years.

IMPORTANT
When placing mailboxes or items on In-Place Hold for legal purposes, it is generally recommended to hold
items indefinitely and remove the hold when the case or investigation is completed.

4. Click Save.

Use the Shell to modify an In-Place eDiscovery search

This example modifies the In-Place eDiscovery search Search-Project Contoso to search mailboxes belonging to
members of the DG -ProjectManagers distribution group.

Set-MailboxSearch -Identity "Search-Project Contoso" -SourceMailboxes "DG-ProjectManagers"

How do you know this worked?

To verify that you have successfully modified an In-Place eDiscovery search, do one of the following:
Use the EAC to check properties of the search.
Use the Get-MailboxSearch cmdlet from the Shell to check the properties of the search. For examples of
how to check the properties of a mailbox search, see the "Examples" section in Get-MailboxSearch.
 Create a custom management scope for In-Place
eDiscovery searches in Exchange 2013
5/30/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use a custom management scope to let specific people or groups use In-Place eDiscovery to search a
subset of mailboxes in your Exchange 2013 organization. For example, you might want to let a discovery manager
search only the mailboxes of users in a specific location or department. You can do this by creating a custom
management scope. This custom management scope uses a recipient filter to control which mailboxes can be
searched. Recipient filter scopes use filters to target specific recipients based on recipient type or other recipient
properties.
For In-Place eDiscovery, the only property on a user mailbox that you can use to create a recipient filter for a
custom scope is distribution group membership (the actual property name is MemberOfGroup). If you use other
properties, such as CustomAttributeN, Department, or PostalCode, the search fails when it's run by a member of
the role group that's assigned the custom scope.
To learn more about management scopes, see:
Understanding management role scopes
Understanding management role scope filters

What do you need to know before you begin?

Estimated time to complete: 15 minutes
As previously stated, you can only use group membership as the recipient filter to create a custom recipient
filter scope that is intended to be used for eDiscovery. Any other recipient properties can't be used to create
a custom scope for eDiscovery searches. Note that membership in a dynamic distribution group can't be
used either.
Perform steps 1 through 3 to let a discovery manager export the search results for an eDiscovery search
that uses a custom management scope.
If your discovery manager doesn't need to preview the search results, you can skip step 4.
If your discovery manager doesn't need to copy the search results, you can skip step 5.

Step 1: Organize users into distribution groups for eDiscovery

To search a subset of mailboxes in your organization or to narrow the scope of source mailboxes that a discovery
manager can search, you'll need to group the subset of mailboxes into one or more distribution groups. When you
create a custom management scope in step 2, you'll use these distribution groups as the recipient filter to create a
custom management scope. This allows a discovery manager to search only the mailboxes of the users who are
members of a specified group.
You might be able to use existing distribution groups for eDiscovery purposes, or you can create new ones. See the
More information section at the end of this topic for tips on how to create distribution groups that can be used to
scope eDiscovery searches.
Step 2: Create a custom management scope
Now you'll create a custom management scope that's defined by the membership of a distribution group (using
the MemberOfGroup recipient filter). When this scope is applied to a role group used for eDiscovery, members of
the role group can search the mailboxes of users who are members of the distribution group that was used to
create the custom management scope.
This procedure uses Exchange Management Shell commands to create a custom scope named Ottawa Users
eDiscovery Scope. It specifies the distribution group named Ottawa Users for the recipient filter of the custom
scope.
1. Run this command to get and save the properties of the Ottawa Users group to a variable, which is used in
the next command.

$DG = Get-DistributionGroup -Identity "Ottawa Users"

2. Run this command to create a custom management scope based on the membership of the Ottawa Users
distribution group.

New-ManagementScope "Ottawa Users eDiscovery Scope" -RecipientRestrictionFilter "MemberOfGroup -eq

'$($DG.DistinguishedName)'"

The distinguished name of the distribution group, which is contained in the variable $DG, is used to create
the recipient filter for the new management scope.

Step 3: Create a management role group

In this step, you create a new management role group and assign the custom scope that you created in step 2. Add
the Legal Hold and Mailbox Search roles so that role group members can perform In-Place eDiscovery searches
and place mailboxes on In-Place Hold or Litigation Hold. You can also add members to this role group so they can
search the mailboxes of the members of the distribution group used to create the custom scope in step 2.
In the following examples, the Ottawa Users eDiscovery Managers security group will be added as members this
role group. You can use either the Shell or the EAC for this step.
Use the Shell to create a management role group
Run this command to create a new role group that uses the custom scope created in step 2. The command also
adds the Legal Hold and Mailbox Search roles, and adds the Ottawa Users eDiscovery Managers security group as
members of the new role group.

New-RoleGroup "Ottawa Discovery Management" -Roles "Mailbox Search","Legal Hold" -CustomRecipientWriteScope

"Ottawa Users eDiscovery Scope" -Members "Ottawa Users eDiscovery Managers"

Use the EAC to create a management role group

1. In the EAC, go to Permissions > Admin roles, and then click New .
2. In New role group, provide the following information:
Name: Provide a descriptive name for the new role group. For this example, you'd use Ottawa
Discovery Management.
Write scope: Select the custom management scope that you created in step 2. This scope will be
applied to the new role group.
Roles: Click Add , and add the Legal Hold and Mailbox Search roles to the new role group.
 Members: Click Add , and select the users, security group, or role groups that you want add as
members of the new role group. For this example, the members of the Ottawa Users eDiscovery
Managers security group will be able to search only the mailboxes of users who are members of the
Ottawa Users distribution group.
3. Click Save to create the role group.
Here's an example of what the New role group window will look like when you're done.

(Optional) Step 4: Add discovery managers as members of the

distribution group used to create the custom management scope
You only need to perform this step if you want to let a discovery manager preview eDiscovery search results.
Run this command to add the Ottawa Users eDiscovery Managers security group as a member of the Ottawa
Users distribution group.

Add-DistributionGroupMember -Identity "Ottawa Users" -Member "Ottawa Users eDiscovery Managers"

You can also use the EAC to add members to a distribution group. For more information, see Create and manage
distribution groups.
(Optional) Step 5: Add a discovery mailbox as a member of the
distribution group used to create the custom management scope
You only need to perform this step if you want to let a discovery manager copy eDiscovery search results.
Run this command to add a discovery mailbox named Ottawa Discovery Mailbox as a member of the Ottawa
Users distribution group.

Add-DistributionGroupMember -Identity "Ottawa Users" -Member "Ottawa Discovery Mailbox"

NOTE
To open a discovery mailbox and view the search results, discovery managers must be assigned Full Access permissions for
the discovery mailbox. For more information, see Create a discovery mailbox.

How do you know this worked?

Here are some ways to verify if you've successfully implemented custom management scopes for eDiscovery.
When you verify, be sure that the user running the eDiscovery searches is a member of the role group that uses
the custom management scope.
Create an eDiscovery search, and select the distribution group that was used to create the custom
management scope as the source of mailboxes to be searched. All mailboxes should be successfully
searched.
Create an eDiscovery search, and search the mailboxes of any users who aren't members of the distribution
group that was used to create the custom management scope. The search should fail because the discovery
manager can only search mailboxes for users who are members of the distribution group that was used to
create the custom management scope. In this case, an error such as "Unable to search mailbox < name of
mailbox> because the current user does not have permissions to access the mailbox" will be returned.
Create an eDiscovery search, and search the mailboxes of users who are members of the distribution group
that was used to create the custom management scope. In the same search, include the mailboxes of users
who aren't members. The search should partially succeed. The mailboxes of members of the distribution
group used to create the custom management scope should be successfully searched. The search of
mailboxes for users who aren't members of the group should fail.

More information
Because distribution groups are used in this scenario to scope eDiscovery searches and not for message
delivery, consider the following when you create and configure distribution groups for eDiscovery:
Create distribution groups with a closed membership so that members can be added to or removed
from the group only by the group owners. If you're creating the group in the Shell, use the syntax
MemberJoinRestriction closed and MemberDepartRestriction closed .

Enable group moderation so that any message sent to the group is first sent to the group
moderators who can approve or reject the message accordingly. If you're creating the group in the
Shell, use the syntax ModerationEnabled $true . If you're using the EAC, you can enable moderation
after the group is created.
Hide the distribution group from the organization's shared address book. Use the EAC or the Set-
DistributionGroup cmdlet after the group is created. If you're using the Shell, use the syntax
HiddenFromAddressListsEnabled $true .
 In the following example, the first command creates a distribution group with closed membership
and moderation enabled. The second command hides the group from the shared address book.

New-DistributionGroup -Name "Vancouver Users eDiscovery Scope" -Alias VancouverUserseDiscovery -

MemberJoinRestriction closed -MemberDepartRestriction closed -ModerationEnabled $true

Set-DistributionGroup "Vancouver Users eDiscovery Scope" -HiddenFromAddressListsEnabled $true

For more information about creating and managing distribution groups, see Create and manage
distribution groups.
Though you can use only distribution group membership as the recipient filter for a custom management
scope used for eDiscovery, you can use other recipient properties to add users to that distribution group.
Here are some examples of using the Get-Mailbox and Get-Recipient cmdlets to return a specific group
of users based on common user or mailbox attributes.

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'Department -eq "HR"'

Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'CustomAttribute15 -eq

"VancouverSubsidiary"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'PostalCode -eq "98052"'

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'StateOrProvince -eq

"WA"'

Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited -OrganizationalUnit

"namsr01a002.sdf.exchangelabs.com/Microsoft Exchange Hosted Organizations/contoso.onmicrosoft.com"

You can then use the examples from the previous bullet to create a variable that can be used with the Add-
DistributionGroupMember cmdlet to add a group of users to a distribution group. In the following
example, the first command creates a variable that contains all user mailboxes that have the value
Vancouver for the Department property in their user account. The second command adds these users to
the Vancouver Users distribution group.

$members = Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'Department -

eq "Vancouver"'

$members | ForEach {Add-DistributionGroupMember "Ottawa Users" -Member $_.Name}

You can use the Add-RoleGroupMember cmdlet to add a member to an existing role group that's used to
scope eDiscovery searches. For example, the following command adds the user
[email protected] to the Ottawa Discovery Management role group.

Add-RoleGroupMember "Vancouver Discovery Management" -Member [email protected]

You can also use the EAC to add members to a role group. For more information, see the "Add members to
a role group" section in Manage Role Group Members.
 Remove an In-Place eDiscovery search in Exchange
2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can use In-Place eDiscovery to search mailbox content. You can remove
an In-Place eDiscovery search at any time. When you remove an In-Place eDiscovery search, search results are
removed from the Discovery mailbox.
Cau t i on

Deleting an In-Place eDiscovery search will remove any search results copied to a Discovery mailbox.

What do you need to know before you begin?

Estimated time to completion: 2-5 minutes.
To remove an In-Place eDiscovery search that has In-Place Hold enabled, you must first remove the In-
Place Hold from the search. For details, see Create or remove an In-Place Hold.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "In-Place eDiscovery" entry in the Messaging Policy and Compliance
Permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

Use the EAC to remove an In-Place eDiscovery search

1. Navigate to Compliance management > In-place eDiscovery & hold.
2. In the list view, select the In-Place eDiscovery search you want to remove, and then click Delete .

Use the Shell to remove an In-Place eDiscovery search

For an example of how to remove an In-Place eDiscovery search, see the "Examples" section in Remove-
MailboxSearch.

How do you know this worked?

To verify that you have successfully removed an In-Place eDiscovery search, do one of the following:
Use the EAC to verify that the search is no longer displayed in the list view of the In-place eDiscovery &
hold tab.
Use the Get-MailboxSearch cmdlet to retrieve In-Place eDiscovery searches. For an example of how to
retrieve In-Place eDiscovery searches, see the "Examples" section in Get-MailboxSearch.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
 Search for and delete messages in Exchange Server
2013
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Administrators can use the Search-Mailbox cmdlet to search user mailboxes and then delete messages from a
mailbox.
To search and delete messages in one step, run the Search-Mailbox cmdlet with the DeleteContent switch.
However, when you do this, you can't preview search results or generate a log of messages that will be returned by
the search, and you may inadvertently delete messages that you didn't intend to. To preview a log of the messages
found in the search before they're deleted, run the Search-Mailbox cmdlet with the LogOnly switch.
As an additional safeguard, you can first copy the messages to another mailbox by using the TargetMailbox and
TargetFolder parameters. By doing this, you retain a copy of the deleted messages in case you need to access them
again.

What do I need to know before I begin?

Estimated time to complete: 10 minutes. The actual time may vary depending on the size of the mailbox and
the search query.
You can't use the Exchange admin center (EAC ) to perform these procedures. You must use the Shell.
You need to be assigned both of the following management roles to search for and delete messages in
users' mailboxes:
Mailbox Search: This role allows you to search for messages across multiple mailboxes in your
organization. Administrators aren't assigned this role by default. To assign yourself this role so that
you can search mailboxes, add yourself as a member of the Discovery Management role group. See
Assign eDiscovery permissions in Exchange.
Mailbox Import Export: This role allows you to delete messages from a user's mailbox. By default,
this role isn't assigned to any role group. To delete messages from users' mailboxes, you can add the
Mailbox Import Export role to the Organization Management role group. For more information, see
the "Add a role to a role group" section in Manage Role Groups .
If the mailbox from which you want to delete messages has single item recovery enabled, you must first
disable the feature. For more information, see Enable or disable single item recovery for a mailbox.
If the mailbox from which you want to delete messages is placed on hold, we recommend that you check
with your records management or legal department before removing the hold and deleting the mailbox
content. After you obtain approval, follow the steps listed in the topic Clean Up the Recoverable Items
Folder.
You can search a maximum of 10,000 mailboxes using the Search-Mailbox cmdlet.
If you include a search query (by using the SearchQuery parameter), the Search-Mailbox cmdlet will
return a maximum of 10,000 items in the search results. Therefore if you include a search query, you might
have to run the Search-Mailbox command multiple times to delete more than 10,000 items.
The user's archive mailbox will also be searched when you run the Search-Mailbox cmdlet. Similarly,
 items in the primary archive mailbox will be deleted when you use the Search-Mailbox cmdlet with the
DeleteContent switch. To prevent this, you can include the DoNotIncludeArchive switch.

Search messages and log the search results

This example searches April Stewart's mailbox for messages that contain the phrase "Your bank statement" in the
Subject field and logs the search results in the SearchAndDeleteLog folder of the administrator's mailbox.
Messages aren't copied to or deleted from the target mailbox.

Search-Mailbox -Identity "April Stewart" -SearchQuery 'Subject:"Your bank statement"' -TargetMailbox

administrator -TargetFolder "SearchAndDeleteLog" -LogOnly -LogLevel Full

This example searches all mailboxes in the organization for messages that have any type of attached file that
contains the word "Trojan" in the filename and sends a log message to the administrator's mailbox.

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery attachment:trojan* -TargetMailbox

administrator -TargetFolder "SearchAndDeleteLog" -LogOnly -LogLevel Full

For detailed syntax and parameter information, see Search-Mailbox.

Search and delete messages

This example searches April Stewart's mailbox for messages that contain the phrase "Your bank statement" in the
Subject field and deletes the messages from the source mailbox without copying the search results to another
folder. As previously explained, you need to be assigned the Mailbox Import Export management role to delete
messages from a user's mailbox.

IMPORTANT
When you use the Search-Mailbox cmdlet with the DeleteContent switch, messages are permanently deleted from the
source mailbox. Before you permanently delete messages, we recommend that you either use the LogOnly switch to
generate a log of the messages found in the search before they're deleted or copy the messages to another mailbox before
deleting them from the source mailbox.

Search-Mailbox -Identity "April Stewart" -SearchQuery 'Subject:"Your bank statement"' -DeleteContent

This example searches April Stewart's mailbox for messages that contain the phrase "Your bank statement" in the
Subject field, copies the search results to the folder AprilStewart-DeletedMessages in the mailbox BackupMailbox,
and deletes the messages from April's mailbox.

Search-Mailbox -Identity "April Stewart" -SearchQuery 'Subject:"Your bank statement"' -TargetMailbox

"BackupMailbox" -TargetFolder "AprilStewart-DeletedMessages" -LogLevel Full -DeleteContent

This example searches all mailboxes in the organization for messages with the subject line "Download this file",
and then permanently deletes them.

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery 'Subject:"Download this file"' -DeleteContent

For detailed syntax and parameter information, see Search-Mailbox.

Using the -LogLevel Full parameter
In some of the previous examples, the LogLevel parameter, with the Full value is used to log detailed information
about the results returned by the Search-Mailbox cmdlet. When you included this parameter, an email message
is created and sent to the mailbox specified by the TargetMailbox parameter. The log file (which is a CSV -
formatted file named Search Results.csv) is attached to this email message, and will be located in the folder
specified by the TargetFolder parameter. The log file contains a row for each message that's included in the search
results when you run the Search-Mailbox cmdlet.
 Reduce the size of a discovery mailbox in Exchange
2013
6/26/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Have a discovery mailbox that's exceeded the 50 GB limit? You can fix this issue by creating new discovery
mailboxes and copying the search results from the large discovery mailbox to the new ones.

Why would I want to do this?

In Exchange Server 2013, the maximum size of discovery mailboxes, which are used to store In-Place eDiscovery
search results, is 50 GB. Prior to the current size limit, you were able to increase the storage quota to more than 50
GB, which resulted in having discovery mailboxes much larger than 50 GB. There are three issues with discovery
mailboxes that are larger than 50 GB:
They're not supported.
They can't be migrated to Office 365.
If they're discovery mailboxes in Exchange Server 2010, they can't be upgraded to Exchange Server 2013.

The process at a glance

Here's a quick look at what you'll need to do to reduce the size of a discovery mailbox that's exceeded the 50 GB
limit:
1. Step 1: Create discovery mailboxes additional discovery mailboxes to distribute the search results to.
2. Step 2: Copy search results to a discovery mailbox the search results from the existing discovery mailbox to
one or more of the new discovery mailboxes.
3. Step 3: Delete eDiscovery searches eDiscovery searches from the original discovery mailbox to reduce its
size.
The strategy presented here groups the search results from the original discovery mailbox into separate
eDiscovery searches that are based on date ranges. This is a quick way to copy many search results to a new
discovery mailbox. The following graphic illustrates this approach.
What do you need to know before you begin?
Estimated time to complete this task: Time will vary based on the amount and size of the search results that
will be copied to different discovery mailboxes.
Run the following command to determine the size of the discovery mailboxes in your organization.

Get-Mailbox -RecipientTypeDetails DiscoveryMailbox | Get-MailboxStatistics | Format-List

DisplayName,TotalItemSize

Determine if you need to keep some or all of the search results from the discovery mailbox that's exceeded
the 50 GB limit. Follow the steps in this topic to retain search results by copying them to a different
discovery mailbox. If you don't need to keep the results of a specific eDiscovery search, you can delete the
search, as explained in step 3. Deleting a search will delete the search results from the discovery mailbox.
If you don't need any of the search results from a discovery mailbox that's exceeded the 50 GB limit, you
can delete it. If this is the default discovery mailbox that was created when your Exchange organization was
provisioned, you can re-create it. For more information, see Delete and re-create the default discovery
mailbox in Exchange.
For current legal cases, you might want to export the results of selected eDiscovery searches to .pst files.
Doing this keeps the results from a specific search intact. In addition to the .pst files that contain the search
results, a search results log (.csv file format) that contains an entry for each message returned in the search
results is also exported. Each entry in this file identifies the source mailbox where the message is located.
For more information, see Export eDiscovery search results to a PST file.
After you export search results to .pst files, you'll need to use Outlook if you want to import them to a new
discovery mailbox.

Step 1: Create discovery mailboxes

The first step is to create additional discovery mailboxes so that you can copy the search results from the discovery
mailbox that's exceeded the size limit. Based on the 50 GB size limit for discovery mailboxes, determine how many
additional discovery mailboxes you'll need and create them. You'll then need to assign users or groups the
necessary permissions to open these new discovery mailboxes.
1. Run the following command to create a new discovery mailbox.

New-Mailbox -Name <discovery mailbox name> -Discovery

2. Run the following command to assign a user or group permissions to open the discovery mailbox and view
search results.

Add-MailboxPermission <discovery mailbox name> -User <name of user or group> -AccessRights FullAccess -
InheritanceType all

Step 2: Copy search results to a discovery mailbox

The next step is to use the New-MailboxSearch cmdlet to copy the search results from the existing discovery
mailbox to a new discovery mailbox that you created in the previous step. This procedure uses the StartDate and
EndDate parameters to scope the search results into batches that are no larger than 50 GB. This may require some
testing (by estimating the search results) to size the search results appropriately.
1. Run the following command to create a new eDiscovery search.

New-MailboxSearch -Name "Search results from 2010" -SourceMailboxes "Discovery Search Mailbox" -
StartDate "01/01/2010" -EndDate "12/31/2010" -TargetMailbox "Discovery Mailbox Backup 01" -EstimateOnly
-StatusMailRecipients [email protected]

This example uses the following parameters:

Name: This parameter specifies the name of the new eDiscovery search. Because the search is
scoped by sent and received dates, it's useful that the name of the search includes the date range.
SourceMailboxes: This parameter specifies the default discovery mailbox. You can also specify the
name of another discovery mailbox that's exceeded the size limit.
StartDate and EndDate: These parameters specify the date range of the search results in the default
discovery mailbox to include in the search results.

NOTE
For dates, use the short date format, mm/dd/yyyy, even if the Regional Options settings on the local
computer are configured with a different format, such as dd/mm/yyyy. For example, use 03/01/2014 to
specify March 1, 2014.

TargetMailbox: This parameter specifies that search results should be copied to the discovery
mailbox named "Discovery Mailbox Backup 01".
EstimateOnly: This switch specifies that only an estimate of the number of items that will be returned
is provided when the search is started. If you don't include this switch, messages are copied to the
target mailbox when the search is started. Using this switch lets you adjust the date ranges if
necessary to increase or decrease the number of search results.
StatusMailRecipients: This parameter specifies that the status message should be sent to the specified
 recipient.
2. After the search is created, start it by using the Shell or the Exchange admin center (EAC ).
Using the Shell: Run the following command to start the search created in the previous step.
Because the EstimateOnly switch was included when the search was created, the search results won't
be copied to the target discovery mailbox.

Start-MailboxSearch "Search results from 2010"

Using the EAC: Go to Compliance management > In-Place eDiscovery & hold. Select the
search created in the previous step, click Search , and then click Estimate search results.
3. If necessary, adjust the date range to increase or decrease the amount of search results that are returned. If
you change the date range, run the search again to get a new estimate of the results. Consider changing the
name of the search to reflect the new date range.
4. When you're finished testing the search, use the Shell or the EAC to copy the search results to the target
discovery mailbox.
Using the Shell: Run the following commands to copy the search results. You have to remove the
EstimateOnly switch before you can copy the search results.

Set-MailboxSearch "Search results from 2010" -EstimateOnly $false

Start-MailboxSearch "Search results from 2010"

Using the EAC: Go to Compliance management > In-Place eDiscovery & hold. Select the
search, click Search , and then click Copy search results.
For more information, see Copy eDiscovery Search Results to a Discovery Mailbox.
5. Repeat steps 1 through 4 to create new searches for additional date ranges. Include the date range in the
name of the new search to indicate the range of the results. To make sure none of the discovery mailboxes
exceeds the 50 GB limit, use different discovery mailboxes as the target mailbox.

Step 3: Delete eDiscovery searches

After you've copied search results from the original discovery mailbox to another discovery mailbox, you can
delete the original eDiscovery searches. Deleting an eDiscovery search will delete the search results from the
discovery mailbox where those search results are stored.
Before deleting a search, you can run the following command to identify the size of the search results that have
been copied to a discovery mailbox for all searches in your organization.

Get-MailboxSearch | Format-List Name,TargetMailbox,ResultSizeCopied

You can use the Shell or the EAC to delete an eDiscovery search.
Using the Shell: Run the following command.

Remove-MailboxSearch -Identity <name of search>

Using the EAC: Go to Compliance management > In-Place eDiscovery & hold. Select the search that
 you want to delete, and then click Delete .

How do you know this worked?

After you've deleted the eDiscovery searches to remove the results from the discovery mailbox where they were
stored, run the following command to display the size of a selected discovery mailbox.

Get-Mailbox <name of discovery mailbox> | Get-MailboxStatistics | Format-List TotalItemSize

 Delete and re-create the default discovery mailbox in
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use the Exchange Management Shell to delete the default discovery mailbox, re-create it, and then assign
permissions to it.

Why would I want to do this?

In Exchange Server 2013, the maximum size of the default discovery mailbox is 50 GB. It's used to store In-Place
eDiscovery search results. Before the size limit was changed, organizations could increase the storage quota to
more than 50 GB. As a result, discovery mailboxes could grow to more than 50 GB. There are three issues with a
default discovery mailbox that is larger than 50 GB:
It's not supported.
It can't be migrated to Office 365.
If it's the default discovery mailbox in Exchange Server 2010, it can't be upgraded to Exchange Server 2013.
How you resolve this depends on whether you want to save the search results from a default discovery mailbox
that's exceeded 50 GB.

DO YOU WANT TO SAVE THE SEARCH RESULTS? DO THIS

No Follow the steps in this topic to delete, and then re-create the
default discovery mailbox.

Yes Follow the steps in Reduce the size of a discovery mailbox in

Exchange.

Use the Exchange Management Shell to delete and re-create the

default discovery mailbox
NOTE
You can't use the Exchange admin center (EAC) because discovery mailboxes aren't displayed in the EAC.

1. Run the following command to delete the default discovery mailbox.

Remove-Mailbox "DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}"

2. In the message asking you to confirm that you want to delete the mailbox and the corresponding Active
Directory user object, type Y, and then press Enter.
A new user object is created in Active Directory when you create the discovery mailbox in the next step.
3. Run the following command to re-create the default discovery mailbox.
 New-Mailbox -Name "DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}" -Alias
"DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}" -DisplayName "Discovery Search Mailbox"
-Discovery

4. Run the following command to assign the Discovery Management role group permissions to open the
default discovery mailbox and view search results.

Add-MailboxPermission "DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}" -User "Discovery

Management" -AccessRights FullAccess -InheritanceType all
 Re-create the Discovery system mailbox
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In-Place eDiscovery uses a system mailbox to store In-Place eDiscovery search metadata. This Discovery system
mailbox has the display name SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}. Because system
mailboxes aren't visible in the Exchange admin center (EAC ) or in Exchange address lists, they are rarely deleted
inadvertently.
However, if the Discovery system mailbox is deleted accidentally, discovery managers will be unable to perform In-
Place eDiscovery searches or manage existing searches. In this case, to enable eDiscovery functionality, you must
re-create the Discovery system mailbox.

What you should know before you begin

Estimated time to complete: 10 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Recipient Provisioning Permissions" section in the Recipients Permissions
topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

Use the Shell to re-create the Discovery system mailbox

1. Delete the SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} user account from Active Directory,
if it exists. By default, Exchange Server 2013 Setup creates the mailbox in the Users container in Active
Directory. For details about how to delete a user account from Active Directory, see Delete a User Account.
2. Use the Shell to enable the Discovery system mailbox.

NOTE
You can't use the EAC to enable the Discovery system mailbox.
The following command must be run from the same directory where you extracted the Exchange installation media.

To re-create the Discovery system mailbox, run the following command:

.\Setup /preparead /IAcceptExchangeServerLicenseTerms

How do I know this worked?

To verify that you have successfully re-created the Discovery system mailbox, use the Get-Mailbox cmdlet with the
Arbitration switch to retrieve system mailboxes. View the results of the command to verify that the system mailbox
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} has been re-created.
TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
 Using OAuth authentication to support eDiscovery in
an Exchange hybrid deployment
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

To successfully perform cross-premises eDiscovery searches in an Exchange 2013 hybrid organization, you will
have to configure OAuth (Open Authorization) authentication between your Exchange on-premises and Exchange
Online organizations so that you can use In-Place eDiscovery to search on-premises and cloud-based mailboxes.
OAuth authentication supports the following eDiscovery scenarios in an Exchange hybrid deployment:
Search on-premises mailboxes that use Exchange Online Archiving for cloud-based archive mailboxes.
Search on-premises and cloud-based mailboxes in the same eDiscovery search.
For step-by-step instructions for configuring OAuth authentication to support eDiscovery, see Configure OAuth
authentication between Exchange and Exchange Online organizations.

What is OAuth authentication?

OAuth authentication is a server-to-server authentication protocol that allows applications to authenticate to each
other. With OAuth authentication, user credentials and passwords are not passed from one computer to another.
Instead, authentication and authorization is based on the exchange of security tokens, which grant access to a
specific set of resources for a specific amount of time.
OAuth authentication typically involves three parties: a single authorization server and the two realms that need to
communicate with one another. Security tokens are issued by the authorization server (also known as a security
token server) to the two realms that need to communicate; these tokens verify that communications originating
from one realm should be trusted by the other realm. When using OAuth authentication between an on-premises
Exchange organization and Exchange Online, the function of the authorization server is provided by Microsoft
Azure Active Directory Access Control Services (ACS ) in your Office 365 organization. For example, during a
cross-premises eDiscovery search, Azure ACS issues tokens that verify that an administrator or compliance officer
from the Exchange on-premises organization is able to access mailboxes in the Exchange Online organization, and
vice-versa.

eDiscovery scenarios in a hybrid deployment

The follow table identifies the eDiscovery scenarios in an Exchange hybrid deployment that require OAuth
authentication.

EDISCOVERY SCENARIO REQUIRES OAUTH AUTHENTICATION?

Search Exchange on-premises mailboxes and Exchange Yes

Online mailboxes in the same eDiscovery search initiated
from the Exchange on-premises organization. For
example, searching all mailboxes in the organization in a
single eDiscovery search.
 EDISCOVERY SCENARIO REQUIRES OAUTH AUTHENTICATION?

Search Exchange on-premises mailboxes that use Yes

Exchange Online Archiving for cloud-based archive
mailboxes. When you use In-Place eDiscovery, both the
primary and archive mailboxes are searched.

Search Exchange Online mailboxes from an eDiscovery Yes

search initiated from the Exchange on-premises
organization by an administrator or compliance officer.

Search on-premises mailboxes using an eDiscovery search No

initiated from the Exchange on-premises organization by
an administrator or compliance officer.
NOTE
As previously discussed, OAuth authentication would be
required if the on-premises mailboxes were configured
with cloud-based archive mailboxes.

Search Exchange Online mailboxes from an eDiscovery No

search initiated from Exchange Online or the eDiscovery
Center in SharePoint Online by an Office 365 tenant
administrator or a compliance officer signed in to an
Office 365 user account.

Configuring OAuth authentication to support eDiscovery

As previously stated, see Configure OAuth authentication between Exchange and Exchange Online organizations
for instructions to configure OAuth authentication to support eDiscovery in an Exchange hybrid deployment.
If OAuth isn't configured for your Exchange hybrid deployment, you can't use eDiscovery to search Exchange on-
premises and Exchange Online mailboxes in the same eDiscovery search. You will have to search on-premises
mailboxes from an eDiscovery search initiated from your on-premises organization. Similarly, you can only search
Exchange Online mailboxes from an eDiscovery search initiated from your Exchange Online organization or by
using the eDiscovery Center in SharePoint Online. Additionally, you won't be able to search primary on-premises
mailboxes if their corresponding archive mailbox resides in Exchange Online or in an Exchange Online Archiving
organization.

More information
You can also use OAuth authentication to allow other applications, such as SharePoint 2013 and Lync
Server 2013, to authenticate to Exchange 2013. For more information, see Configure OAuth authentication
with SharePoint 2013 and Lync 2013.
You can configure server-to-server authentication between Exchange 2013 and SharePoint 2013 so
administrators and compliance officers can use the eDiscovery Center in SharePoint 2013 to search
Exchange 2013 mailboxes. For more information, see Configure Exchange for SharePoint eDiscovery
Center.
You can configure an Exchange hybrid deployment using the Hybrid Configuration Wizard in Exchange
2013. For a customized, step-by-step hybrid deployment configuration checklist, see the Exchange Server
Deployment Assistant.
 Configure Exchange for SharePoint eDiscovery
Center
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 includes features that work with Microsoft SharePoint Server 2013 and
Microsoft Lync Server 2013, known as partner applications. To make sure these partner applications can access
each other's resources, you need to configure server-to-server authentication.
This topic shows you how to configure server-to-server authentication between Exchange 2013 and SharePoint
2013 so users can use the eDiscovery Center in SharePoint 2013 to search Exchange Server 2013 mailbox
content. To fully enable this functionality, you must complete additional steps in SharePoint 2013. For details, see
Configure eDiscovery in SharePoint 2013.

What do you need to know before you begin?

Estimated time to complete this task: 30 minutes.
Procedures in this topic require specific permissions. See each procedure for its permissions information.
It's supported to install Exchange 2013 and SharePoint 2013 in different domains or forests. A Windows
trust relationship between Exchange and SharePoint forests isn't required, because in that circumstance,
Exchange and SharePoint will rely on the OAuth 2.0 protocol to trust one another.
The SharePoint 2013 site must be configured to use Secure Sockets Layer (SSL ).
The Exchange Web Services Managed API must be installed on every server that is running SharePoint
2013. Reset Internet Information Server (IIS ) after installation.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Configure server-to-server authentication for Exchange 2013

on a server running SharePoint Server 2013
Run the following command to create Exchange 2013 as a trusted security token issuer in SharePoint 2013.

New-SPTrustedSecurityTokenIssuer -Name Exchange -MetadataEndPoint https://<Exchange Server Name or

FQDN>/autodiscover/metadata/json/1

Step 2: Configure server-to-server authentication for SharePoint 2013

on a server running Exchange 2013
Perform this step on an Exchange 2013 server. You need to be assigned permissions before you can perform this
procedure or procedures. To see what permissions you need, see the "Partner applications - configure" entry in the
Sharing and collaboration permissions topic.
Run this command to configure the SharePoint partner application.

cd c:\'Program Files'\Microsoft\'Exchange Server'\V15\Scripts

.\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl <path to SharePoint AuthMetadataUrl> -
ApplicationType SharePoint

Step 3: Add authorized users to the Discovery Management role group

Add users who need to perform an eDiscovery search using SharePoint 2013 to the Discovery Management role
group in Exchange 2013. For details, see Assign eDiscovery permissions in Exchange.

WARNING
Adding users to the Discovery Management role group allows them to use In-Place eDiscovery to search all Exchange 2013
mailboxes and access potentially sensitive email content in user mailboxes. By default, this permission isn't assigned to any
user, including members of the Organization Management role group. Check with your organization's legal or HR
departments before assigning this permission to any user.
 Unsearchable items in Exchange eDiscovery
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

In In-Place eDiscovery for Exchange Server 2013 and Exchange Online, unsearchable items are mailbox items that
can't be indexed by Exchange Search or that have been only partially indexed. An unsearchable item typically
contains a file, which can't be indexed, attached to an email message. Here are a few reasons why files can't be
indexed for search and are returned as an unsearchable item when attached to an email message:
The file type is unsupported for indexing because a search filter (also known as an IFilter) to index the file
format isn't installed.
The file type is disabled for indexing.
The file type is supported for indexing but an indexing error occurred for a specific file.
A file is encrypted with non-Microsoft technologies.
A file is password-protected.
For a successful eDiscovery search, your organization may be required to review unsearchable items. You can
specify whether to include unsearchable items when you copy eDiscovery search results to a discovery mailbox or
export results to a PST file.

File types not supported for search

Certain types of files, such as Bitmap or MP3 files, don't contain content that can be indexed. As a result, Exchange
Search doesn't perform full-text indexing on these types of files. These types of files are considered as
unsupported file types. There are also file types for which full-text indexing has been disabled, either by default or
by an administrator. Unsupported and disabled file types are considered unsearchable items in eDiscovery
searches. These types of files, which are typically attached to an email message, are included in the result set when
you include unsearchable items when copying or exporting search results. For a list of supported and disabled file
formats, see File formats indexed by Exchange Search. In Exchange Server 2013, administrators can disable
indexing for a supported file format by using the Set-SearchDocumentFormat cmdlet. This cmdlet isn't available
in Exchange Online.
To identify the unsearchable items in a specific mailbox, you can run the Get-FailedContentIndexDocuments
cmdlet to get a list of items that would be copied or exported when you choose to include unsearchable items with
the search results.

Messages with unsupported file types returned in search results

Not every message with an unsupported file attachment is automatically returned as an unsearchable item. That's
because other file properties, such as the filename, are indexed and available to be searched. For example, a
keyword search for "financial" will return a message with an unsupported file attachment if that keyword appears
in the file name. If the keyword only appears in the body of the attached file, the message would be returned as an
unsearchable item.
Similarly, messages with unsupported file attachments are included in search results when other properties of a
mailbox item, which are indexed and searchable, meet the search criteria. Message properties that are indexed for
search include sent and received dates, sender and recipient, the file name of an attachment, and text in the
message body. So even though a message attachment may be unsearchable, the message will be included in the
regular search results if the value of other message properties matches the search criteria. In fact, it's common that
messages with unsearchable attachments are included in the regular search results.
For a list of email message properties indexed for search, see Message properties indexed by Exchange Search.

Including unsearchable items in the search results

Your organization may be required to identify and perform additional processing on unsearchable items to
determine what they are, what they contain, and whether they're relevant. To include unsearchable items with the
eDiscovery search results, you can use the unsearchable items option when you copy or export search results. To
include unsearchable items when using In-Place eDiscovery in Exchange or Exchange Online, select the Include
unsearchable items option when copying search results to a discovery mailbox or exporting them to a PST file.
To include unsearchable items when using the eDiscovery Center in SharePoint or SharePoint Online, select the
Include items that are encrypted or have an unrecognized format option.
Keep the following in mind when copying or exporting unsearchable items:
When you copy unsearchable items to a discovery mailbox, any unsearchable items are copied to a
separate folder named Unsearchable, which is located under the folder that contains the search results.
When you export search results and include unsearchable items, the unsearchable items are exported to a
separate PST file.
When you include unsearchable items in the search results, all unsearchable items in the mailboxes that are
searched will be returned, regardless of the search criteria.
If you choose to include all mailbox items in the search results or if a search query doesn't specify any
keywords or only specifies a date range, unsearchable items may not be copied to the Unsearchable folder
if you select the option to include unsearchable items. This is because all items, including any unsearchable
items, will be automatically included in the regular search results.
As previously stated, because message properties and metadata are indexed, a keyword search may return
results if that keyword appears in the properties or metadata of a message with an unsearchable file
attached to it. In this case, two copies of the same mailbox item will also be included in the search results. To
prevent this type of duplication and only include one copy of the item in the regular search results, you can
select the Enable deduplication option when you copy or export the search results.
Including unsearchable items in the search results can also affect the estimated search results that are
displayed. If you include unsearchable items when copying search results, the total estimated item count
and the total estimated size will include the unsearchable items.
For more information about including unsearchable items in search results, see:
Create an In-Place eDiscovery search
Export eDiscovery search results to a PST file
SharePoint: Export eDiscovery content and create reports

More information about unsearchable items

Although a file type supported by Exchange Search and is full-text indexed, there can be indexing or search
errors that will cause a file to be returned as an unsearchable item. For example, searching a very large
Excel file might be partially successful, but will then fail as the size limit is exceeded. In this case, it's possible
that the same file is returned with the search results and as an unsearchable item.
Attached files encrypted with Microsoft technologies are indexed by Exchange Search and will be searched.
Files encrypted with non-Microsoft technologies are returned as unsearchable.
Email messages encrypted with S/MIME aren't indexed and are considered unsearchable items. This
includes encrypted messages with or without file attachments.
Messages protected using Information Rights Management (IRM ) are indexed by Exchange Search and
included in the search results if they match query parameters. For more information about IRM, see
Information Rights Management.
As previously stated, because message properties and metadata are indexed, a keyword search may return
results if that keyword appears in the indexed metadata. However, that same keyword search may not
return the same item if the keyword only appears in the content of an attached item with an unsupported
file type. In this case, the item would be returned only as an unsearchable item.
In eDiscovery in Exchange 2010, there is the concept of a safelist. These are file types that contain content
that isn't searchable and so aren't indexed by Exchange Search; for example, Windows Media Video (.wmv)
and Waveform Audio (.wav) files. Because these types of files don't contain searchable content, they aren't
considered unsearchable items in Exchange 2010. Mailbox items containing these file types weren't
returned as unsearchable items and weren't copied to a discovery mailbox.
There is no longer a safelist in Exchange 2013 or Exchange Online. File types are either enabled or disabled
for indexing or they are unsupported. Disabled and unsupported file types are considered unsearchable
items.
 Messaging records management in Exchange 2013
5/30/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Users send and receive email every day. If left unmanaged, the volume of email generated and received each day
can inundate users, impact user productivity, and expose your organization to risks. As a result, email lifecycle
management is a critical component for most organizations.
Messaging records management (MRM ) is the records management technology in Exchange Server that helps
organizations manage email lifecycle and reduce the legal risks associated with email. Deploying MRM can help
your organization in several ways:
Meet business requirements: Depending on your organization's messaging policies, you may need to
retain important email messages for a certain period. For example, a user's mailbox may contain critical
messages related to business strategy, transactions, product development, or customer interactions.
Meet legal and regulatory requirements: Many organizations have a legal or regulatory requirement to
store messages for a designated period and remove messages older than that period. Storing messages
longer than necessary may increase your organization's legal or financial risks.
Increase user productivity: If left unmanaged, the ever-increasing volume of email in your users'
mailboxes can also impact their productivity. For example, although newsletter subscriptions and automated
notifications may have informational value when they're received, users may not remove them after reading
(often they're never read). Many of these types of messages don't have a retention value beyond a few days.
Using MRM to remove such messages can help reduce information clutter in users' mailboxes, thereby
increasing productivity.
Improve storage management: Due to expectations driven by free consumer email services, many users
keep old messages for a long period or never remove them. Maintaining large mailboxes is increasingly
becoming a standard practice, and users shouldn't be forced to change their work habits based on restrictive
mailbox quotas. However, retaining messages beyond the period that's necessary for business, legal, or
regulatory reasons also increases storage costs.
MRM provides the flexibility to implement the records management policy that best meets your organization's
requirements. With a good understanding of MRM, In-Place Archiving, and In-Place Hold, you can help meet your
goals of managing mailbox storage and meeting regulatory retention requirements.
Looking for management tasks related to MRM? See Messaging Records Management Procedures.

MRM in Exchange Server 2013

In Exchange Server 2013, MRM is accomplished through the use of retention tags and retention policies. Retention
tags are used to apply retention settings to an entire mailbox and default mailbox folders such as Inbox and
Deleted Items. You can also create and deploy retention tags that Outlook 2010 and later and Outlook Web App
users can use to apply to folders or individual messages. After they're created, you add retention tags to a retention
policy and then apply the policy to users. The Managed Folder Assistant processes mailboxes and applies retention
settings in the user's retention policy. To learn more about retention policies, see Retention tags and retention
policies.
When a message reaches its retention age specified in the applicable retention tag, the Managed Folder Assistant
takes the retention action specified by the tag. Messages can then be deleted permanently or deleted with the
ability to recover them. If an archive has been provisioned for the user, you can also use retention tags to move
items to the user's In-Place Archive.

MRM strategies
You can use retention policies to enforce basic message retention for an entire mailbox or for specific default
folders. Although there are several strategies for deploying MRM, here are some of the most common:
Remove all messages after a specified period: In this strategy, you implement a single MRM policy that
removes all messages after a certain period. In this strategy, there's no classification of messages. You can
implement this policy by creating a single default policy tag (DPT) for the mailbox. However, this doesn't ensure
that messages are retained for the specified period. Users can still delete messages before retention period is
reached.
Move messages to archive mailboxes: In this strategy, you implement MRM policies that move items to the
user's archive mailbox. An archive mailbox provides additional storage for users to maintain old and infrequently
accessed content. Retention tags that move items are also known as archive policies. Within the same retention
policy, you can combine a DPT and personal tags to move items, and a DPT, RPTs, and personal tags to delete
items. To learn more about archiving policies, see:
Exchange Server:: In-Place Archiving

NOTE
In an Exchange hybrid deployment, you can enable a cloud-based archive mailbox for an on-premises primary mailbox. If you
assign an archive policy to an on-premises mailbox, items are moved to the cloud-based archive. If an item is moved to the
archive mailbox, a copy of it isn't retained in the on-premises mailbox. If the on-premises mailbox is placed on hold, an archive
policy will still move items to the cloud-based archive mailbox where they are preserved for the duration specified by the
hold.

Remove messages based on folder location: In this strategy, you implement MRM policies based on email
location. For example, you can specify that messages in the Inbox are retained for one year and messages in the
Junk Email folder are retained for 60 days. You can implement this policy by using a combination of retention
policy tags (RPTs) for each default folder you want to configure and a DPT for the entire mailbox. The DPT applies
to all custom folders and all default folders that don't have an RPT applied.

NOTE
In Exchange 2013, you can create RPTs for the Calendar and Tasks folders. If you don't want items in these folders or other
default folders to expire, you can create a disabled retention tag for that default folder.

Allow users to classify messages: In this strategy, you implement MRM policies that include a baseline retention
setting for all messages but allow users to classify messages based on business or regulatory requirements. In this
case, users become an important part of your records management strategy - often they have the best
understanding of a message's retention value.
Users can apply different retention settings to messages that need to be retained for a longer or shorter period.
You can implement this policy using a combination of the following:
A DPT for the mailbox
Personal tags that users can apply to custom folders or individual messages
(Optional) Additional RPTs to expire items in specific default folders

For example, you can use a retention policy with personal tags that have a shorter retention period (such as two
days, one week, or one month), as well as personal tags that have a longer retention period (such as one, two, or
five years). Users can apply personal tags with the shorter retention periods for items such as newsletter
subscriptions that may lose their value within days of receiving them, and apply the tags with longer periods to
preserve items that have a high business value. They can also automate the process by using Inbox rules in
Outlook to apply a personal tag to messages that match rule conditions.
Retain messages for eDiscovery purposes: In this strategy, you implement MRM policies that remove messages
from mailboxes after a specified period but also retain them in the Recoverable Items folder for In-Place
eDiscovery purposes, even if the messages were deleted by the user or another process.
You can meet this requirement by using a combination of retention policies and In-Place Hold and Litigation Hold
or Litigation Hold. Retention policies remove messages from the mailbox after the specified period. A time-based
In-Place Hold or Litigation Hold preserves messages that were deleted or modified before that period. For
example, to retain messages for seven years, you can create a retention policy with a DPT that deletes messages in
seven years and Litigation Hold to hold messages for seven years. Messages that aren't removed by users will be
deleted after seven years; messages deleted by users before the seven year period will be retained in the
Recoverable Items folder for seven years. To learn more about this folder, see Recoverable Items Folder.
Optionally, you can use RPTs and personal tags to allow users to clean up their mailboxes. However, In-Place Hold
and Litigation Hold continues to retain the deleted messages until the hold period expires.

NOTE
A time-based In-Place Hold or Litigation Hold is similar to what was informally referred to as a rolling legal hold in Exchange
2010. Rolling legal hold was implemented by configuring the deleted item retention period for a mailbox database or
individual mailbox. However, deleted item retention retains deleted and modified items based on the date deleted. In-Place
Hold and Litigation Hold preserves items based on the date they're received or created. This ensures that messages are
preserved for at least the specified period.

For more information

Messaging Records Management Terminology in Exchange 2013
Retention tags and retention policies
 Messaging records management terminology in
Exchange 2013
6/11/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic defines the core components associated with messaging records management (MRM ) in Microsoft
Exchange Server 2013. MRM is a records management technology in Exchange 2013 that helps organizations
reduce the risks associated with e-mail and other communications. MRM makes it easier to keep messages needed
to comply with company policy, government regulations, or legal needs, and to remove content that has no legal or
business value.
default policy tag (DPT): A DPT is a retention tag that applies to all items in a mailbox that don't already
have a retention tag applied. You can have only one DPT in a retention policy.
filer user or filer: A user who regularly files mailbox items into folders. Compare to piler user* or *piler.
journaling: The ability to record communications, including e-mail communications, in an organization for
use in the organization's e-mail retention or archival strategy. In MRM, journaling commonly refers to the
process of sending a journal report about messages in a managed folder to the specified SMTP address.
This process is performed by the Managed Folder Assistant.
managed content settings: The retention information created for managed folders, the MRM feature
available in Exchange Server 2007 and Exchange Server 2010. A managed folder can have multiple content
settings for different message types such as e-mail messages, voice mail, and calendar items. Message
retention settings defined in content settings for a managed folder apply to messages in that managed
folder.
managed folder: Used for the MRM functionality in Exchange Server 2007 and Exchange Server 2010, a
managed folder is an Active Directory object that represents a mailbox folder in order to apply managed
content settings to it. In a mailbox, a managed folder is a folder to which managed content settings have
been applied.
Managed Folder Assistant: One of the Microsoft Exchange Mailbox Assistants in Exchange 2013. The
Managed Folder Assistant is responsible for archiving, message expiration, and compliance. It processes
mailboxes and applies retention policies.
managed folder mailbox policy: A logical grouping of managed folders. In Exchange 2010 and Exchange
2007, when a managed folder mailbox policy is applied to a user's mailbox, all managed folders linked to the
policy are deployed in a single operation.
personal tag: A personal tag is a retention tag available to Outlook Web App and Outlook 2010 and later
users for applying retention settings to custom folders and individual items, such as e-mail messages.
piler user or piler: A user who doesn't file mailbox items regularly. Piler users tend to have a large Inbox
and rely on search to find messages. Compare to filer user or filer.
policy: See retention policy or managed folder mailbox policy.
retention policy tag (RPT): A RPT is a retention tag that's applied to default folders such as Inbox and
Deleted Items.
retention policy: A retention policy is logical grouping of retention tags. When a retention policy is applied
to a user's mailbox, all retention tags linked to the policy are deployed in a single operation.
retention tag: Retention tags are used to apply retention settings to messages and folders in user
mailboxes. There are three types of retention tags:
Default policy tags (DPTs)
Retention policy tags (RPTs)
Personal tags
 Retention tags and retention policies in Exchange
2013
6/14/2019 • 15 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server, Messaging records management (MRM ) helps organizations to manage email
lifecycle and reduce legal risks associated with e-mail and other communications. MRM makes it easier to keep
messages needed to comply with company policy, government regulations, or legal needs, and to remove content
that has no legal or business value.

Messaging Records Management strategy

MRM in Exchange 2013 is accomplished by using retention tags and retention policies. Before discussing the
details about each of these retention features, it's important to learn how the features are used in the overall
MRM strategy. This strategy is based on:
Assigning retention policy tags (RPTs) to default folders, such as the Inbox and Deleted Items.
Applying default policy tags (DPTs) to mailboxes to manage the retention of all untagged items.
Allowing the user to assign personal tags to custom folders and individual items.
Separating MRM functionality from users' Inbox management and filing habits. Users aren't required to
file messages in managed folders based on retention requirements. Individual messages can have a
different retention tag than the one applied to the folder in which they're located.
The following figure illustrates the tasks involved in implementing this strategy.
Retention tags
As illustrated in the preceding figure, retention tags are used to apply retention settings to folders and individual
items such as e-mail messages and voice mail. These settings specify how long a message remains in a mailbox
and the action to be taken when the message reaches the specified retention age. When a message reaches its
retention age, it's moved to the user's In-Place Archive or deleted.
Retention tags allow users to tag their own mailbox folders and individual items for retention. Users no longer
have to file items in managed folders provisioned by an administrator based on message retention requirements.
Types of retention tags
Retention tags are classified into the following three types based on who can apply them and where in a mailbox
they can be applied.

TYPE OF RETENTION
TAG APPLIED... APPLIED BY... AVAILABLE ACTIONS... DETAILS

Default policy tag Automatically to Administrator Move to archive Users can't change
(DPT) entire mailbox DPTs applied to a
Delete and allow mailbox.
A DPT applies to recovery
untagged items,
which are mailbox Permanently delete
items that don't have
a retention tag
applied directly or by
inheritance from the
folder.
 TYPE OF RETENTION
TAG APPLIED... APPLIED BY... AVAILABLE ACTIONS... DETAILS

Retention policy tag Automatically to a Administrator Delete and allow Users can't change
(RPT) default folder recovery the RPT applied to a
default folder.
Default folders are Permanently delete
folders created
automatically in all
mailboxes, for
example: Inbox,
Deleted Items, and
Sent Items. See the
list of supported
default folders in
Default folders that
support Retention
Policy Tags.

Personal tag Manually to items Users Move to archive Personal tags allow
and folders your users to
Delete and allow determine how long
Users can automate recovery an item should be
tagging by using retained. For example,
Inbox rules to either Permanently delete the mailbox can have
move a message to a a DPT to delete items
folder that has a in seven years, but a
particular tag or to user can create an
apply a personal tag exception for items
to the message. such as newsletters
and automated
notifications by
applying a personal
tag to delete them in
three days.

More about personal tags

Personal tags are available to Outlook 2010 and Outlook Web App users as part of their retention policy. In
Outlook 2010 and Outlook Web App, personal tags with the Move to Archive action appear as Archive Policy,
and personal tags with the Delete and Allow Recovery or Permanently Delete actions appear as Retention
Policy, as shown in the following figure.
Users can apply personal tags to folders they create or to individual items. Messages that have a personal tag
applied are always processed based on the personal tag's settings. Users can apply a personal tag to a message
so that it's moved or deleted sooner or later than the settings specified in the DPT or RPTs applied to that user's
mailbox. You can also create personal tags with retention disabled. This allows users to tag items so they're never
moved to an archive or never expire.

NOTE
Users can apply archive policies to default folders, user-created folders or subfolders, and individual items. Users can apply a
retention policy to user-created folders or subfolders and individual items (including subfolders and items in a default
folder), but not to default folders.

Users can also use the Exchange admin center (EAC ) to select additional personal tags that aren't linked to their
retention policy. The selected tags then become available in Outlook 2010 and Outlook Web App. To enable users
to select additional tags from the EAC, you must add the MyRetentionPolicies Role to the user's role assignment
policy. To learn more about role assignment policies for users, see Understanding Management Role Assignment
Policies. If you allow users to select additional personal tags, all personal tags in your Exchange organization
become available to them.

NOTE
Personal tags are a premium feature. Mailboxes with policies that contain these tags (or as a result of users adding the tags
to their mailbox) require an Exchange Enterprise client access license (CAL).

Retention age
When you enable a retention tag, you must specify a retention age for the tag. This age indicates the number of
days to retain a message after it arrives in the user's mailbox.
The retention age for non-recurring items (such as email messages) is calculated differently than items that have
an end date or recurring items (such as meetings and tasks). To learn how retention age is calculated for different
types of items, see How retention age is calculated.
You can also create retention tags with retention disabled or disable tags after they're created. Because messages
that have a disabled tag applied aren't processed, no retention action is taken. As a result, users can use a disabled
personal tag as a Never Move tag or a Never Delete tag to override a DPT or RPT that would otherwise apply
to the message.
Retention actions
When creating or configuring a retention tag, you can select one of the following retention actions to to be taken
when an item reaches its retention age:

RETENTION ACTION ACTION TAKEN... EXCEPT...

Move to Archive1 Moves the message to the user's If the user doesn't have an archive
archive mailbox mailbox, no action is taken.

Only available for DPTs and personal

tags

For details about archiving, see In-Place

Archiving

Delete and Allow Recovery Emulates the behavior when the user If you've set the deleted item retention
empties the Deleted Items folder. period to zero days, items are
permanently deleted.
Items are moved to the Recoverable
Items Folder in the mailbox and
preserved until the deleted item
retention period.

Provides the user a second chance to

recover the item using the Recover
Deleted Items dialog box in Outlook
or Outlook Web App

Permanently Delete Permanently deletes messages. If mailbox is placed on In-Place Hold

and Litigation Hold or Litigation Hold,
You can't recover messages after items are preserved in the Recoverable
they're permanently deleted. Items folder based on hold parameters.
In-Place eDiscovery will still return
these items in search results.

Mark as Past Retention Limit Marks a message as expired. In N. A.

Outlook 2010 or later, and Outlook
Web App, expired items are displayed
with the notification stating 'This item
has expired' and 'This item will expire in
0 days'. In Outlook 2007, items marked
as expired are displayed by using
strikethrough text.
 NOTE
1 In an Exchange hybrid deployment, you can enable a cloud-based archive mailbox for an on-premises primary mailbox. If

you assign an archive policy to an on-premises mailbox, items are moved to the cloud-based archive. If an item is moved to
the archive mailbox, a copy of it isn't retained in the on-premises mailbox. If the on-premises mailbox is placed on hold, an
archive policy will still move items to the cloud-based archive mailbox where they are preserved for the duration specified
by the hold.

For details about how to create retention tags, see Create a Retention Policy.

Retention policies
To apply one or more retention tags to a mailbox, you must add them to a retention policy and then apply the
policy to mailboxes. A mailbox can't have more than one retention policy. Retention tags can be linked to or
unlinked from a retention policy at any time, and the changes automatically take effect for all mailboxes that have
the policy applied.
A retention policy can have the following retention tags:

RETENTION TAG TYPE TAGS IN A POLICY

Default policy tag (DPT) One DPT with the Move to Archive action

One DPT with the Delete and Allow Recovery or

Permanently Delete actions

One DPT for voice mail messages with the Delete and Allow
Recovery or Permanently Delete action

Retention policy tags (RPTs) One RPT for each supported default folder
Note: You can't link more than one RPT for a particular
default folder (such as Deleted Items) to the same retention
policy.

Personal tags Any number of personal tags

Tip: Many personal tags in a policy can confuse users. We

recommend adding no more than 10 personal tags to a
retention policy.

NOTE
Although a retention policy doesn't need to have any retention tags linked to it, we don't recommend using this scenario. If
mailboxes with retention policies don't have retention tags linked to them, this may cause mailbox items to never expire.

A retention policy can contain both archive tags (tags that move items to the personal archive mailbox) and
deletion tags (tags that delete items). A mailbox item can also have both types of tags applied. Archive mailboxes
don't have a separate retention policy. The same retention policy is applied to the primary and archive mailbox.
When planning to create retention policies, you must consider whether they'll include both archive and deletion
tags. As mentioned earlier, a retention policy can have one DPT that uses the Move to Archive action and one
DPT that uses either the Delete and Allow Recovery or Permanently Delete action. The DPT with the Move
to Archive action must have a lower retention age than the DPT with a deletion action. For example, you can use
a DPT with the Move to Archive action to move items to the archive mailbox in two years, and a DPT with a
deletion action to remove items from the mailbox in seven years. Items in both primary and archive mailboxes
will be deleted after seven years.
For a list of management tasks related to retention policies, see Messaging Records Management Procedures.
Default retention policy
Exchange Setup creates the retention policy Default MRM Policy. In Exchange Server, the policy is applied
automatically if you create an archive for the new user and don't specify a retention policy.
You can modify tags included in the Default MRM Policy, for example by changing the retention age or retention
action, disable a tag or modify the policy by adding or removing tags from it. The updated policy is applied to
mailboxes the next time they're processed by the Managed Folder Assistant.
For more details, including a list of retention tags linked to the policy, see Default Retention Policy in Exchange
2013.

Managed Folder Assistant

The Managed Folder Assistant, a mailbox assistant that runs on Mailbox servers, processes mailboxes that have a
retention policy applied.
The Managed Folder Assistant applies the retention policy by inspecting items in the mailbox and determining
whether they're subject to retention. It then stamps items subject to retention with the appropriate retention tags
and takes the specified retention action on items past their retention age.
The Managed Folder Assistant is a throttle-based assistant. Throttle-based assistants are always running and
don't need to be scheduled. The system resources they can consume are throttled. You can configure the
Managed Folder Assistant to process all mailboxes on a Mailbox server within a certain period (known as a work
cycle). Additionally, at a specified interval (known as the work cycle checkpoint), the assistant refreshes the list of
mailboxes to be processed. During the refresh, the assistant adds newly created or moved mailboxes to the
queue. It also reprioritizes existing mailboxes that haven't been processed successfully due to failures and moves
them higher in the queue so they can be processed during the same work cycle.
You can also use the Start-ManagedFolderAssistant cmdlet to manually trigger the assistant to process a
specified mailbox. To learn more, see Configure the Managed Folder Assistant.

NOTE
The Managed Folder Assistant doesn't take any action on messages that aren't subject to retention, specified by disabling
the retention tag. You can also disable a retention tag to temporarily suspend items with that tag from being processed.

Moving items between folders

A mailbox item moved from one folder to another inherits any tags applied to the folder to which it's moved. If an
item is moved to a folder that doesn't have a tag assigned, the DPT is applied to it. If the item has a tag explicitly
assigned to it, the tag always takes precedence over any folder-level tags or the default tag.
Applying a retention tag to a folder in the archive
When the user applies a personal tag to a folder in the archive, if a folder with the same name exists in the
primary mailbox and has a different tag, the tag on that folder in the archive changes to match the one in the
primary mailbox. This is by design to avoid any confusion about items in a folder in the archive having a different
expiry behavior than the same folder in the user's primary mailbox. For example, the user has a folder named
Project Contoso in the primary mailbox with a Delete - 3 years tag and a Project Contoso folder also exists in the
archive mailbox. If the user applies a Delete - 1 year personal tag to delete items in the folder after 1 year. When
the mailbox is processed again, the folder reverts to the Delete - 3 Years tag.
Removing or deleting a retention tag from a retention policy
When a retention tag is removed from the retention policy applied to a mailbox, the tag is no longer available to
the user and can't be applied to items in the mailbox.
Existing items that have been stamped with that tag continue to be processed by the Managed Folder Assistant
based on those settings and any retention action specified in the tag is applied to those messages.
However, if you delete the tag, the tag definition stored in Active Directory is removed. This causes the Managed
Folder Assistant to process all items in a mailbox and restamp the ones that have the removed tag applied.
Depending on the number of mailboxes and messages, this process may significantly consume resources on all
Mailbox servers that contain mailboxes with retention policies that include the removed tag.

IMPORTANT
If a retention tag is removed from a retention policy, any existing mailbox items with the tag applied will continue to expire
based on the tag's settings. To prevent the tag's settings from being applied to any items, you should delete the tag.
Deleting a tag removes it from any retention policies in which it's included.

Disabling a retention tag

If you disable a retention tag, the Managed Folder Assistant ignores items that have that tag applied. Items that
have a retention tag for which retention is disabled are either never moved or never deleted, depending on the
specified retention action. Because these items are still considered tagged items, the DPT doesn't apply to them.
For example, if you want to troubleshoot retention tag settings, you can temporarily disable a retention tag to
stop the Managed Folder Assistant from processing messages with that tag.

NOTE
The retention period for a disabled retention tag is displayed to the user as Never. If a user tags an item believing it will
never be deleted, enabling the tag later may result in unintentional deletion of items the user didn't want to delete. The
same is true for tags with the Move to Archive action.

Retention hold
When users are temporarily away from work and don't have access to their e-mail, retention settings can be
applied to new messages before they return to work or access their e-mail. Depending on the retention policy,
messages may be deleted or moved to the user's personal archive. You can temporarily suspend retention policies
from processing a mailbox for a specified period by placing the mailbox on retention hold. When you place a
mailbox on retention hold, you can also specify a retention comment that informs the mailbox user (or another
user authorized to access the mailbox) about the retention hold, including when the hold is scheduled to begin
and end. Retention comments are displayed in supported Outlook clients. You can also localize the retention hold
comment in the user's preferred language.

NOTE
Placing a mailbox on retention hold doesn't affect how mailbox storage quotas are processed. Depending on the mailbox
usage and applicable mailbox quotas, consider temporarily increasing the mailbox storage quota for users when they're on
vacation or don't have access to e-mail for an extended period. For more information about mailbox storage quotas, see
Configure Storage Quotas for a Mailbox.

During long absences from work, users may accrue a large amount of e-mail. Depending on the volume of e-mail
and the length of absence, it may take these users several weeks to sort through their messages. In these cases,
consider the additional time it may take the users to catch up on their mail before removing them from retention
hold.
If your organization has never implemented MRM, and your users aren't familiar with its features, you can also
use retention holds during the initial warm up and training phase of your MRM deployment. You can create and
deploy retention policies and educate users about the policies without the risk of having items moved or deleted
before users can tag them. A few days before the warm up and training period ends, you should remind users of
the warm-up deadline. After the deadline, you can remove the retention hold from user mailboxes, allowing the
Managed Folder Assistant to process mailbox items and take the specified retention action.
For details about how to place a mailbox on retention hold, see Place a mailbox on retention hold.
 Default Retention Policy in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Exchange creates the retention policy Default MRM Policy in your Exchange organization. The policy is applied
when you create an archive for the mailbox. You can change the retention policy that's applied to a user at any time.
You can modify tags included in the Default MRM Policy, for example by changing the retention age or retention
actions, disable a tag, or modify the policy by adding or removing tags from it. The updated policy is applied to
mailboxes the next time they're processed by the Managed Folder Assistant

Retention tags linked to the Default MRM Policy

The following table lists the default retention tags linked to the Default MRM Policy.

NAME TYPE RETENTION AGE (DAYS) RETENTION ACTION

Default 2 years move to Default Policy Tag (DPT) 730 Move to Archive
archive

Recoverable Items 14 days Recoverable Items folder 14 Move to Archive

move to archive

Personal 1 year move to Personal tag 365 Move to Archive

archive

Personal 5 year move to Personal tag 1,825 Move to Archive

archive

Personal never move to Personal tag Not applicable Move to Archive

archive

1 Week Delete Personal tag 7 Delete and Allow Recovery

1 Month Delete Personal tag 30 Delete and Allow Recovery

6 Month Delete Personal tag 180 Delete and Allow Recovery

1 Year Delete Personal tag 365 Delete and Allow Recovery

5 Year Delete Personal tag 1,825 Delete and Allow Recovery

Never Delete Personal tag Not applicable Delete and Allow Recovery

What you can do with the Default MRM Policy

YOU CAN... IN EXCHANGE SERVER...
 YOU CAN... IN EXCHANGE SERVER...

Apply the Default MRM Policy automatically to new users Yes, applied by default if you also create an archive for the
new user.
If you create an archive for the user later, the policy is applied
automatically only if the user doesn't have an existing
Retention Policy.

Modify the retention age or retention action of a retention tag Yes

linked to the policy

Disable a retention tag linked to the policy Yes

Add a retention tag to the policy Yes

Remove a retention tag from the policy Yes

Set another policy as the default retention policy to be applied No

automatically to new users

More information
A Retention Tag can be linked to more than one Retention Policy. For details about managing Retention tags
and retention policies, see Messaging Records Management Procedures.
The Default MRM Policy doesn't include a DPT to automatically delete items (but it does contain personal
tags with the delete retention action that users can apply to mailbox items). If you want to automatically
delete items after a specified period, you can create a DPT with the required delete action and add it to the
policy. For details, see Create a Retention Policy and Add retention tags to or remove retention tags from a
retention policy.
Retention policies are applied to mailbox users. The same policy applies to the user's mailbox and archive.
 Default folders that support Retention Policy Tags in
Exchange 2013
5/30/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use Retention tags and retention policies to manage email lifecycle. Retention Policies contain Retention
Tags, which are settings you can use to specify when a message should be automatically moved to the archive or
when it should be deleted.
A Retention Policy Tag (RPT) is a type of retention tag that you can apply to default folders in a mailbox, such as
Inbox and Deleted Items.

Supported default folders

You can create RPTs for the default folders shown in the following table.
FOLDER NAME DETAILS

Calendar This default folder is used to store meetings and

appointments.

Clutter This folder contains email messages that are low priority.
Clutter looks at what you've done in the past to determine the
messages you're most likely to ignore. It then moves those
messages to the Clutter folder.

Conversation History This folder is created by Microsoft Lync (previously Microsoft

Office Communicator). Although not treated as a default
folder by Outlook, it's treated as a special folder by Exchange
and can have RPTs applied.

Deleted Items This default folder is used to store items deleted from other
folders in the mailbox. Outlook and Outlook Web App users
can manually empty this folder. Users can also configure
Outlook to empty the folder upon closing Outlook.

Drafts This default folder is used to store draft messages that haven't
been sent by the user. Outlook Web App also uses this folder
to save messages that were sent by the user but not
submitted to the Hub Transport server.

Inbox This default folder is used to store messages delivered to a

mailbox.

Journal This default folder contains actions selected by the user. These
actions are automatically recorded by Outlook and placed in a
timeline view.

Junk E-mail This default folder is used to save messages marked as junk e-
mail by the content filter on an Exchange server or by the
anti-spam filter in Outlook.

Notes This folder contains notes created by users in Outlook. These

notes are also visible in Outlook Web App.

Outbox This default folder is used to temporarily store messages sent

by the user until they're submitted to a Hub Transport server.
A copy of sent messages is saved in the Sent Items default
folder. Because messages usually remain in this folder for a
brief period, it isn't necessary to create an RPT for this folder.

RSS Feeds This default folder contains RSS feeds.

Recoverable Items This is a hidden folder in the Non-IPM sub-tree. It contains

the Deletions, Versions, Purges, DiscoveryHolds, and Audits
sub-folders. Retention tags for this folder move items from
the Recoverable Items folder in the user's primary mailbox to
the Recoverable Items folder in the user's archive mailbox. You
can assign only the Move To Archive retention action to tags
for this folder. To learn more, see Recoverable Items Folder.

Sent Items This default folder is used to store messages that have been
submitted to a Hub Transport server.
 FOLDER NAME DETAILS

Sync Issues This folder contains synchronization logs. To learn more, see
Synchronization error folders.

Tasks This default folder is used to store tasks. To create an RPT for
the Tasks folder, you have to use the Exchange Management
Shell. For more information, see New-RetentionPolicyTag. After
the RPT for the Tasks folder is created, you can manage it by
using the Exchange admin center.

More Info
RPTs are retention tags for default folders. You can only select a delete action for RPTs - either delete and
allow recovery or permanently delete.
You can't create an RPT to move messages to the archive. To move old items to archive, you can create a
Default Policy Tag (DPT), which applies to the entire mailbox, or Personal Tags, which are displayed in
Outlook and Outlook Web App (OWA) as Archive Policies. Your users can apply them to folders or
individual messages.
You can't apply RPTs to the Contacts folder.
You can only add one RPT for a particular default folder to a Retention Policy. For example, if a retention
policy has an Inbox tag, you can't add another RPT of type Inbox to that retention policy.
To learn how to create RPTs or other types of retention tags and add them to a retention policy, see Create a
Retention Policy.
A DPT also applies to the Calendar and Tasks default folders. This may result in items being deleted or
moved to the archive based on the DPT settings. To prevent the DPT settings from deleting items in these
folders, create RPTs with retention disabled. To prevent the DPT settings from moving items in a default
folder, you can create a disabled Personal Tag with the move to archive action, add it to the retention policy,
and then have users apply it to the default folder. For details, see Prevent archiving of items in a default
folder in Exchange 2010.
 How retention age is calculated in Exchange 2013
5/30/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Managed Folder Assistant (MFA) is one of many mailbox assistant processes that runs on mailbox servers. Its
job is to process mailboxes that have a Retention Policy applied, add the Retention Tags included in the policy to
the mailbox, and process items in the mailbox. If the items have a retention tag, the assistant tests the age of those
items. If an item has exceeded its retention age, it takes the specified retention action. Retention actions include
moving an item to the user's archive, deleting the item and allowing recovery, or deleting the item permanently.
See Retention tags and retention policies for more information.

Determining the age of different types of items

The retention age of mailbox items is calculated from the date of delivery or in the case of items like drafts that
aren't delivered but created by the user, the date an item was created. When the Managed Folder Assistant
processes items in a mailbox, it stamps a start date and an expiration date for all items that have retention tags
with the Delete and Allow Recovery or Permanently Delete retention action. Items that have an archive tag
are also stamped with a move date.
Items in the Deleted Items folder and items which may have a start and end date, such as calendar items (meetings
and appointments) and tasks, are handled differently as shown in this table.

THE RETENTION AGE IS CALCULATED

IF THE ITEM TYPE IS... AND THE ITEM IS... BASED ON...

Email message Not in the Deleted Items folder Delivery date or date of creation

Document

Fax

Journal item

Meeting request, response, or

cancellation

Missed call

Email message In the Deleted Items folder Date of delivery or creation unless the
item was deleted from a folder that
Document does not have an inherited or implicit
retention tag.
Fax
If an item is in a folder that doesn't have
Journal item an inherited or implicit retention tag
applied, the item isn't processed by the
Meeting request, response, or MFA and therefore doesn't have a start
cancellation date stamped by it. When the user
deletes such an item, and the MFA
Missed call processes it for the first time in the
Deleted Items folder, it stamps the
current date as the start date.
 THE RETENTION AGE IS CALCULATED
IF THE ITEM TYPE IS... AND THE ITEM IS... BASED ON...

Calendar Not in the Deleted Items folder Non-recurring calendar items expire
according to their end date.

Recurring calendar items expire

according to the end date of their last
occurrence. Recurring calendar items
with no end date don't expire.

Calendar In the Deleted Items folder A calendar item expires according to its
message-received date, if one exists. If a
calendar item doesn't have a message-
received date, it expires according to its
message-creation date. If a calendar
item has neither a message-received
date nor a message-creation date, it
doesn't expire.

Task Not in the Deleted Items folder Non-recurring tasks:

• A non-recurring task expires according
to its message-received date , if one
exists.
• If a non-recurring task doesn't have a
message-received date , it expires
according to its
message-creation date .
• If a non-recurring task has neither a
message-received date nor a
message-creation date , it doesn't
expire.

A recurring task expires according to

the end date of its last occurrence. If
a recurring task doesn't have an
end date , it doesn't expire.

A regenerating task (which is a recurring

task that regenerates a specified time
after the preceding instance of the task
is completed) doesn't expire.

Task In the Deleted Items folder A task expires according to its message-
received date, if one exists. If a task
doesn't have a message-received date,
it expires according to its message-
creation date. If a task has neither a
message-received date nor a message-
creation date, it doesn't expire.

Contact In any folder Contacts aren't stamped with a start

date or an expiration date, so they're
skipped by the Managed Folder
Assistant and don't expire.

Corrupted In any folder Corrupted items are skipped by the

Managed Folder Assistant and don't
expire.
Examples
IF THE USER... THE RETENTION TAGS ON FOLDER... THE MANAGED FOLDER ASSISTANT...

Receives a message in the Inbox on Inbox: Delete in 365 days Processes the message in the Inbox on
01/26/2013. 1/26/2013, stamps it with a start date
Deleted Items: Delete in 30 days of 01/26/2013 and an expiration date
Deletes the message on 2/27/2013. of 01/26/2014.

Processes the message again in the

Deleted Items folder on 2/27/2013. It
recalculates the expiration date based
on the same start date (01/26/2013).
Because the item is older than 30 days,
it is expired immediately.

Receives a message in the Inbox on Inbox: None (inherited or implicit) Processes the message in the Deleted
01/26/2013. Items folder on 02/27/2013 and
Deleted Items: Delete in 30 days determines the item doesn't have a
Deletes the message on 2/27/2013. start date. It stamps the current date as
the start date, and 03/27/2013 as the
expiration date. The item is expired on
3/27/2013, which is 30 days after the
user deleted or moved it to the Deleted
Items folder.

More Info
Items in mailboxes placed on Retention Hold aren't processed by the Managed Folder Assistant until the
Retention Hold is removed.
If a mailbox is placed on In-Place Hold or Litigation Hold, expiring items are removed from the Inbox but
preserved in the Recoverable Items folder until the mailbox is removed from In-Place Hold and Litigation
Hold.
In hybrid deployments, the same retention tags and retention policies must exist in your on-premises and
Exchange Online organizations in order to consistently move and expire items across both organizations.
See Export and Import Retention Tags for more information.
In Exchange Online, the Managed Folder Assistant processes a mailbox once in seven days. This might
result in items being expired up to seven days after the expiration date stamped on the item.
 Checklist: Deploying retention policies
5/21/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Use this checklist to deploy retention policies in your Microsoft Exchange Server 2013 organization. Before you
start working with this checklist, make sure you're familiar with the concepts in the following topics:
Messaging records management
Retention tags and retention policies

Checklist for deploying retention policies

DONE? TASKS RESOURCES

Assess messaging records Messaging records management

management (MRM) requirements
for different sets of users.

Determine which Microsoft Outlook Parse the RPC Client Access log files
client versions are in use. located at
%ExchangeInstallPath%Logging\RPC
Client Access
.

Create retention tags. Create a Retention Policy

Create retention policies. Create a Retention Policy

Add retention tags to retention Add retention tags to or remove

policies. retention tags from a retention
policy

Place mailboxes on retention hold. Place a mailbox on retention hold

Apply a retention policy to a single Apply a retention policy to

mailbox for testing purposes. mailboxes

Optional: Implement client blocking Configure Outlook Client Blocking

to block legacy Outlook clients. for Messaging Records
Management
DONE? TASKS RESOURCES

Begin user communication and Not applicable

training activities. Include a deadline
when retention policies will be
processed, and items moved or
deleted.

Apply retention policy to additional Apply a retention policy to

mailboxes. mailboxes

A few days in advance, remind users Not applicable

about the deadline.

At the deadline, remove the Place a mailbox on retention hold

retention hold from mailboxes.
 Messaging Records Management Procedures in
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Create a Retention Policy
Add retention tags to or remove retention tags from a retention policy
Apply a retention policy to mailboxes
Configure the Managed Folder Assistant
Place a mailbox on retention hold
 Create a Retention Policy in Exchange 2013
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Exchange Server 2013, you can use retention policies to manage email lifecycle. Retention policies are applied
by creating retention tags, adding them to a retention policy, and applying the policy to mailbox users.
For additional management tasks related to retention policies, see Messaging Records Management Procedures.

What do you need to know before you begin?

Estimated time to complete this task: 30 minutes.
Procedures in this topic require specific permissions. See each procedure for its permissions information.
Mailboxes to which you apply retention policies must reside on Exchange Server 2010 or later servers.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

Step 1: Create a retention tag

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and compliance
permissions topic.
Use the EAC to create a retention tag
1. Navigate to Compliance management > Retention tags, and then click Add
2. Select one of the following options:
Applied automatically to entire mailbox (default): Select this option to create a default policy
tag (DPT). You can use DPTs to create a default deletion policy and a default archive policy, which
applies to all items in the mailbox.

NOTE
You can't use the EAC to create a DPT to delete voice mail items. For details about how to create a DPT to
delete voice mail items, see the Shell example below.

Applied automatically to a specific folder: Select this option to create a retention policy tag
(RPT) for a default folder such as Inbox or Deleted Items.

NOTE
You can only create RPTs with the Delete and allow recovery or Permanently delete actions.

Applied by users to items and folders (Personal): Select this option to create personal tags.
These tags allow Outlook and Outlook Web App users to apply archive or deletion settings to a
message or folders that are different from the settings applied to the parent folder or the entire
mailbox.
3. The New retention tag page title and options will vary depending on the type of tag you selected.
Complete the following fields:
Name: Enter a name for the retention tag. The tag name is for display purposes and doesn't have
any impact on the folder or item a tag is applied to. Consider that the personal tags you provision
for users are available in Outlook and Outlook Web App.
Apply this tag to the following default folder: This option is available only if you selected
Applied automatically to a specific folder.
Retention action: Select one of the following actions to be taken after the item reaches its retention
period:
Delete and Allow Recovery: Select this action to delete items but allow users to recover them
using the Recover Deleted Items option in Outlook or Outlook Web App. Items are retained until
the deleted item retention period configured for the mailbox database or the mailbox user is
reached.
Permanently Delete: Select this option to permanently delete the item from the mailbox database.

IMPORTANT
Mailboxes or items subject to In-Place Hold or litigation hold will be retained and returned in In-Place
eDiscovery searches. To learn more, see In-Place Hold and Litigation Hold.

Move to Archive: This action is available only if you're creating a DPT or a personal tag. Select this
action to move items to the user's In-Place Archive.
Retention period: Select one of the following options:
Never: Select this option to specify that items should never be deleted or moved to the archive.
When the item reaches the following age (in days): Select this option and specify the number
of days to retain items before they're moved or deleted. The retention age for all supported items
except Calendar and Tasks is calculated from the date an item is received or created. Retention age
for Calendar and Tasks items is calculated from the end date.
Comment: User this optional field to enter any administrative notes or comments. The field isn't
displayed to users.
Use the Shell to create a retention tag
Use the New-RetentionPolicyTag cmdlet to create a retention tag. Different options available in the cmdlet
allow you to create different types of retention tags. Use the Type parameter to create a DPT ( All ), RPT (specify
a default folder type, such as Inbox ) or a personal tag ( Personal ).
This example creates a DPT to delete all messages in the mailbox after 7 years (2,556 days).

New-RetentionPolicyTag -Name "DPT-Corp-Delete" -Type All -AgeLimitForRetention 2556 -RetentionAction

DeleteAndAllowRecovery

This example creates a DPT to move all messages to the In-Place Archive in 2 years (730 days).

New-RetentionPolicyTag -Name "DPT-Corp-Move" -Type All -AgeLimitForRetention 730 -RetentionAction

MoveToArchive

This example creates a DPT to delete voice mail messages after 20 days.
 New-RetentionPolicyTag -Name "DPT-Corp-Voicemail" -Type All -MessageClass Voicemail -AgeLimitForRetention 20 -
RetentionAction DeleteAndAllowRecovery

This example creates a RPT to permanently delete messages in the Junk EMail folder after 30 days.

New-RetentionPolicyTag -Name "RPT-Corp-JunkMail" -Type JunkEmail -AgeLimitForRetention 30 -RetentionAction

PermanentlyDelete

This example creates a personal tag to never delete a message.

New-RetentionPolicyTag -Name "Never Delete" -Type Personal -RetentionAction DeleteAndAllowRecovery -

RetentionEnabled $false

Step 2: Create a retention policy

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and compliance
permissions topic.
Use the EAC to create a retention policy
1. Navigate to Compliance management > Retention policies, and then click Add
2. In New Retention Policy, complete the following fields:
Name: Enter a name for the retention policy.
Retention tags: Click Add to select the tags you want to add to this retention policy.
A retention policy can contain the following tags:
One DPT with the Move to Archive action
One DPT with the Delete and Allow Recovery or Permanently Delete actions
One DPT for voice mail messages with the Delete and Allow Recovery or Permanently Delete
actions
One RPT per default folder such as Inbox to delete items
Any number of personal tags

NOTE
Although you can add any number of personal tags to a retention policy, having many personal tags with
different retention settings can confuse users. We recommend linking no more than ten personal tags to a
retention policy.

You can create a retention policy without adding any retention tags to it, but items in the mailbox to
which the policy is applied won't be moved or deleted. You can also add and remove retention tags
from a retention policy after it's created.
Use the Shell to create a retention policy
This example creates the retention policy RetentionPolicy-Corp and uses the RetentionPolicyTagLinks parameter
to associate five tags to the policy.
 New-RetentionPolicy "RetentionPolicy-Corp" -RetentionPolicyTagLinks "DPT-Corp-Delete","DPT-Corp-Move","DPT-
Corp-Voicemail","RPT-Corp-JunkMail","Never Delete"

For detailed syntax and parameter information, see New -RetentionPolicy.

Step 3: Apply a retention policy to mailbox users

After you create a retention policy, you must apply it to mailbox users. You can apply different retention policies to
different set of users. For detailed instructions, see Apply a retention policy to mailboxes.

How do you know this task worked?

After you create retention tags, add them to a retention policy, and apply the policy to a mailbox user, the next time
the MRM mailbox assistant processes the mailbox, messages are moved or deleted based on settings you
configured in the retention tags.
To verify that you have applied the retention policy, do the following:
1. Run the following Shell command to run the MRM assistant manually against a single mailbox.

Start-ManagedFolderAssistant -Identity <mailbox identity>

2. Log on to the mailbox using Outlook or Outlook Web App and verify that messages are deleted or moved
to an archive in accordance with the policy configuration.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
 Add retention tags to or remove retention tags from
a retention policy in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can add retention tags to a retention policy when the policy is created or any time thereafter. For details about
how to create a retention policy, including how to simultaneously add retention tags, see Create a Retention Policy.
A retention policy can contain the following retention tags:
One or more retention policy tags (RPTs) for supported default folders
One default policy tag (DPT) with the Move to Archive action
One DPT with the Delete and Allow Recovery or the Permanently Delete action
One DPT for voice mail
Any number of personal tags
For more information about retention tags, see Retention tags and retention policies.

What do you need to know before you begin?

Estimated time to completion: 10 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Mailbox Permissions topic.
Retention tags aren't applied to a mailbox until they're linked to a retention policy and the Managed Folder
Assistant processes the mailbox. To start the Managed Folder Assistant so that it processes a mailbox, see
Configure and run the Managed Folder Assistant in Exchange 2016.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to add or remove retention tags

1. Go to Compliance management > Retention policies.
2. In the list view, select the retention policy to which you want to add retention tags and then click Edit .
3. In Retention Policy, use the following settings:
Add : Click this button to add a retention tag to the policy.
Remove : Select a tag from the list, and then click this button to remove the tag from the policy.
Use the Shell to add or remove retention tags
This example adds the retention tags VPs-Default, VPs-Inbox, and VPs-DeletedItems to the retention policy
RetPolicy-VPs, which doesn't already have retention tags linked to it.
Cau t i on

If the policy has retention tags linked to it, this command replaces the existing tags.

Set-RetentionPolicy -Identity "RetPolicy-VPs" -RetentionPolicyTagLinks "VPs-Default","VPs-Inbox","VPs-

DeletedItems"

This example adds the retention tag VPs-DeletedItems to the retention policy RetPolicy-VPs, which already has
other retention tags linked to it.

$TagList = (Get-RetentionPolicy "RetPolicy-VPs").RetentionPolicyTagLinks

$TagList.Add((Get-RetentionPolicyTag 'VPs-DeletedItems').DistinguishedName)
Set-RetentionPolicy "RetPolicy-VPs" -RetentionPolicyTagLinks $TagList

This example removes the retention tag VPs-Inbox from the retention policy RetPolicy-VPs.

$TagList = (Get-RetentionPolicy "RetPolicy-VPs").RetentionPolicyTagLinks

$TagList.Remove((Get-RetentionPolicyTag 'VPs-Inbox').DistinguishedName)
Set-RetentionPolicy "RetPolicy-VPs" -RetentionPolicyTagLinks $TagList

For detailed syntax and parameter information, see Set-RetentionPolicy and Get-RetentionPolicy.

How do you know this worked?

To verify that you have successfully added or removed a retention tag from a retention policy, use the Get-
RetentionPolicy cmdlet to verify the RetentionPolicyTagLinks property.
This example use the Get-RetentionPolicy cmdlet to retrieve retention tags added to the Default MRM Policy
and pipes them to the Format-Table cmdlet to output only the name property of each tag.

(Get-RetentionPolicy "Default MRM Policy").RetentionPolicyTagLinks | Format-Table name

 Apply a retention policy to mailboxes in Exchange
2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use retention policies to group one or more retention tags and apply them to mailboxes to enforce
message retention settings. A mailbox can't have more than one retention policy.
Cau t i on

Messages are expired based on settings defined in the retention tags linked to the policy. These settings include
actions such moving messages to the archive or permanently deleting them. Before applying a retention policy to
one or more mailboxes, we recommended that you test the policy and inspect each retention tag associated with it.
For additional management tasks related to messaging records management (MRM ), see Messaging Records
Management Procedures.

What do you need to know before you begin?

Estimated time to complete: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Applying retention policies" entry in the Messaging Policy and Compliance
Permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to apply a retention policy to a single mailbox

1. Navigate to Recipients > Mailboxes.
2. In the list view, select the mailbox to which you want to apply the retention policy, and then click Edit .
3. In User Mailbox, click Mailbox features.
4. In the Retention policy list, select the policy you want to apply to the mailbox, and then click Save.

Use the EAC to apply a retention policy to multiple mailboxes

1. Navigate to Recipients > Mailboxes.
2. In the list view, use the Shift or Ctrl keys to select multiple mailboxes.
3. In the details pane, click More options.
4. Under Retention Policy, click Update.
5. In Bulk Assign Retention Policy, select the retention policy you want to apply to the mailboxes, and then
 click Save.

Use the Shell to apply a retention policy to a single mailbox

This example applies the retention policy RP -Finance to Morris's mailbox.

Set-Mailbox "Morris" -RetentionPolicy "RP-Finance"

For detailed syntax and parameter information, see Set-Mailbox.

Use the Shell to apply a retention policy to multiple mailboxes

This example applies the new retention policy New -Retention-Policy to all mailboxes that have the old policy Old-
Retention-Policy.

$OldPolicy={Get-RetentionPolicy "Old-Retention-Policy"}.distinguishedName
Get-Mailbox -Filter {RetentionPolicy -eq $OldPolicy} -Resultsize Unlimited | Set-Mailbox -RetentionPolicy
"New-Retention-Policy"

This example applies the retention policy RetentionPolicy-Corp to all mailboxes in the Exchange organization.

Get-Mailbox -ResultSize unlimited | Set-Mailbox -RetentionPolicy "RetentionPolicy-Corp"

This example applies the retention policy RetentionPolicy-Finance to all mailboxes in the Finance organizational
unit.

Get-Mailbox -OrganizationalUnit "Finance" -ResultSize Unlimited | Set-Mailbox -RetentionPolicy

"RetentionPolicy-Finance"

For detailed syntax and parameter information, see Get-Mailbox and Set-Mailbox.

How do you know this worked?

To verify that you have applied the retention policy, run the Get-Mailbox cmdlet to retrieve the retention policy for
the mailbox or mailboxes.
This example retrieves the retention policy for Morris's mailbox.

Get-Mailbox Morris | Select RetentionPolicy

This command retrieves all mailboxes that have the retention policy RP -Finance applied.

Get-Mailbox -ResultSize unlimited | Where-Object {$_.RetentionPolicy -eq "RP-Finance"} | Format-Table

Name,RetentionPolicy -Auto
 Configure the Managed Folder Assistant
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Managed Folder Assistant is a Microsoft Exchange Mailbox Assistant that applies message retention settings
configured in retention policies.
For additional management tasks related to messaging records management (MRM ), see Messaging Records
Management Procedures.

What do you need to know before you begin?

Time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and
compliance permissions topic.
You can't use the Exchange admin center (EAC ) to configure the Managed Folder Assistant. You must use
the Shell
In Exchange 2013, the Managed Folder Assistant is a throttle-based assistant. Throttle-based assistants are
always running and don't need to be scheduled. The system resources they can consume are throttled. You
can configure the Managed Folder Assistant to process all mailboxes on a Mailbox server within a certain
period (known as a work cycle). The work cycle is set to one day by default.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure the Managed Folder Assistant

This example configures the Managed Folder Assistant to process all mailboxes within one day.

Set-MailboxServer MyMailboxServer -ManagedFolderWorkCycle 1

For detailed syntax and parameter information, see Set-MailboxServer.

How do I know this worked?

To verify that you have successfully configured the Managed Folder Assistant, use the Get-MailboxServer cmdlet to
check the ManagedFolderWorkCycle parameter.
This command retrieves all Mailbox servers in the organization and outputs the Managed Folder Assistant's
workcycle properties from each server in a table format. The Auto switch is used to automatically fit column width.
 Get-MailboxServer | Format-Table Name,ManagedFolderWorkCycle* -Auto

Use the Shell to start the Managed Folder Assistant

This example triggers the Managed Folder Assistant to immediately process Morris Cornejo's mailbox.

Start-ManagedFolderAssistant -Identity [email protected]

For detailed syntax and parameter information, see Start-ManagedFolderAssistant.

 Place a mailbox on retention hold in Exchange 2013
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Placing a mailbox on retention hold suspends the processing of a retention policy or managed folder mailbox
policy for that mailbox. Retention hold is designed for situations such as a user being on vacation or away
temporarily.
During retention hold, users can log on to their mailbox and change or delete items. When you perform a mailbox
search, deleted items that are past the deleted item retention period aren't returned in search results. To make sure
items changed or deleted by users are preserved in legal hold scenarios, you must place a mailbox on legal hold.
For more information, see Create or remove an In-Place Hold.
You can also include retention comments for mailboxes you place on retention hold. The comments are displayed
in supported versions of Microsoft Outlook.
For additional management tasks related to messaging records management (MRM ), see Messaging Records
Management Procedures.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging Policy and
Compliance Permissions topic.
You can't use the Exchange admin center (EAC ) to place a mailbox on retention hold. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to place a mailbox on retention hold

This example places Michael Allen's mailbox on retention hold.

Set-Mailbox "Michael Allen" -RetentionHoldEnabled $true

For detailed syntax and parameter information, see Set-Mailbox.

Use the Shell to remove retention hold for a mailbox

This example removes the retention hold from Michael Allen's mailbox.

Set-Mailbox "Michael Allen" -RetentionHoldEnabled $false

For detailed syntax and parameter information, see Set-Mailbox.

How do you know this worked?

To verify that you have successfully placed a mailbox on retention hold, use the Get-Mailbox cmdlet to retrieve the
RetentionHoldEnabled property of the mailbox.
This command retrieves the RetentionHoldEnabled property for Michael Allen's mailbox.

Get-Mailbox "Michael Allen" | Select RetentionHoldEnabled

This command retrieves all mailboxes in the Exchange organization, filters the mailboxes that are placed on
retention hold, and lists them along with the retention policy applied to each.

IMPORTANT
Because RetentionHoldEnabled isn't a filterable property in Exchange 2013, you can't use the Filter parameter with the Get-
Mailbox cmdlet to filter mailboxes that are placed on retention hold on the server-side. This command retrieves a list of all
mailboxes and filters on the client running the Shell session. In large environments with thousands of mailboxes, this
command may take a long time to complete.

Get-Mailbox -ResultSize unlimited | Where-Object {$_.RetentionHoldEnabled -eq $true} | Format-Table

Name,RetentionPolicy,RetentionHoldEnabled -Auto
 Export and import retention tags
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

There are several scenarios in which you may want to export or import retention tags, including:
Applying the same retention policies across all servers in a multi-forest Exchange organization
Applying the same retention policies in a hybrid deployment where some mailboxes reside in your on-
premises Exchange organization and some reside in Exchange Online.
Applying retention policies in an Exchange Archiving scenario, where users with on-premises Exchange
2010 or later mailboxes have a cloud-based archive.
In these scenarios, the Managed Folder Assistant can correctly process an item that has a retention tag applied
after the item or the mailbox is moved to another organization.

WARNING
To keep retention tags and retention policies synchronized between two organizations, every time you make changes to a
retention tag or policy in the source organization, you must perform this procedure to export retention tags and policies
from the source organization and import them in the destination organization.
You can't select specific retention tags or policies to export. The Export-RetentionTags.ps1 script exports all retention tags and
policies from an organization.

For additional management tasks related to Messaging Records Management, see Messaging Records
Management Procedures.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging Records Management" entry in the Messaging policy and
compliance permissions topic.
The procedures in this topic depend on these three files in the %ExchangeInstallPath%Scripts folder on
yourExchange server:
Export-RetentionTags.ps1
Import-RetentionTags.ps1
MigrateRetentionTags.strings.psd1
You can't select specific retention tags or policies to export or import. The Export-RetentionTags.ps1 script
exports all retention tags and policies from an organization. The Import-RetentionTags.ps1 script imports all
retention tags and policies in the XML file being imported, replacing all existing retention tags and policies
in an Exchange organization.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
 TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Export retention tags from an on-premises Exchange

organization
1. Run this Exchange Management Shell command to change directory to the Scripts subdirectory in your
Exchange installation path.

Cd $Env:ExchangeInstallPath\Scripts

2. Run the Export-RetentionTags.ps1 script to export retention tags to an XML file.

IMPORTANT
If you're importing or exporting retention tags and retention policies to Exchange Online, you must connect your
Windows PowerShell session to Exchange Online. For details, see Connect to Exchange Online using remote
PowerShell.

.\Export-RetentionTags.ps1 "c:\docs\ExportedRetentionTags.xml"

How do you know this worked?

To verify that you have successfully exported retention tags and retention policies, do the following:
1. Navigate to the path you specified in the command to export and verify that the XML file with the name you
specified has been created.
2. Optionally, you can open the XML file in a text editor to review its contents.

Step 2: Import retention tags to an Exchange organization

1. Run this Exchange Management Shell command to change the directory to the Scripts subdirectory in your
Exchange installation path.

Cd $Env:ExchangeInstallPath\Scripts

2. Run the Import-RetentionTags.ps1 script to import retention tags from a previously exported XML file.

IMPORTANT
If you're importing or exporting retention tags and retention policies to Exchange Online, you must connect your
Windows PowerShell session to Exchange Online. For details, see Connect to Exchange Online using remote
PowerShell.
/
When running this script against Exchange Online, you may be prompted to confirm that you want to run software
from an untrusted publisher. Verify that the name of the publisher appears as
CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=Washington, C=US , and then
click R to allow the script to be run once or A to always run.
 .\Import-RetentionTags.ps1 "c:\docs\ExportedRetentionTags.xml"

How do you know this worked?

To verify that you have successfully imported retention tags and retention policies, do the following:
1. In the EAC, navigate to Compliance Management > Retention tags, and verify that the retention tags
have been imported successfully. Navigate to Compliance Management > Retention policies, and verify
that the retention policies have been imported successfully.
2. Use the Get-RetentionPolicy and Get-RetentionPolicyTag cmdlets to verify that the tags and policies
have been created. For an example about how to retrieve retention tags and retention policies, see Examples
in Get-RetentionPolicyTag and Get-RetentionPolicy.
 Configure Outlook client blocking
6/6/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Exchange Server 2013, you can use retention policies or managed folders for messaging records management
(MRM ). Only users running Microsoft Outlook 2010 and later have access to all client features for retention
policies. However, retention policies are applied on the Mailbox server by the Managed Folder Assistant,
regardless of the Outlook client version used by the user. Older Outlook clients do not expose the MRM
functionality of these features. For example, because Outlook 2007 does not support retention policies, users can't
apply personal tags to items or folders.
You can block users who are running older versions of Outlook from accessing their Exchange mailboxes. You can
also block access on a per-mailbox or on a per-Client Access server basis.
For other management tasks related to MRM, see Messaging Records Management Procedures.

MRM Feature Availability by Client Application and Version

The following table lists the MRM features available in various client applications and versions.
MRM features
CLIENT APPLICATION AVAILABLE MRM CLIENT FEATURES

Outlook 2013 and Outlook 2010 All

Outlook 2007 Managed folders

Outlook 2003 and older Not supported

Other e-mail client software None

The following table shows version numbers for Outlook.

Outlook versions
OUTLOOK VERSION VERSION NUMBER

Outlook 2013 15

Outlook 2010 14

Outlook 2007 12

Outlook 2003 11
 OUTLOOK VERSION VERSION NUMBER

Outlook 2002 10

Outlook 2000 9

Outlook 98 8.5

Outlook 97 8

NOTE
Before making any changes, note that hotfixes and service pack releases may affect the client version string. Be careful when
you restrict client access because server-side Exchange components must also use MAPI to log on. Some components report
their client version as the component name (such as SMTP or OLE DB), while others report the Exchange build number (such
as 6.0.4712.0). For this reason, avoid restricting clients that have version numbers that start with 6.<x.x.>. For example, to
prevent MAPI access completely, instead of specifying 0.0.0-6.5535.65535.65535, specify the two ranges so that the server
components can log on. For example, specify the following: 0.0.0-5.9.9; 7.0.0-.

After you perform these procedures, be aware that when users are blocked from accessing their mailboxes, they
will receive the following warning message.

Your Exchange Server administrator has blocked the version of Outlook that you are using. Contact your administrator for
assistance.

To bypass the warning that MRM features aren't supported for e-mail clients running versions of Outlook earlier
than Outlook 2010, you can use the ManagedFolderMailboxPolicyAllowed parameter of the New-Mailbox,
Enable-Mailbox, and Set-Mailbox cmdlets in the Shell. When a managed folder mailbox policy is assigned to a
mailbox by using the ManagedFolderMailboxPolicy parameter, the warning appears by default unless you use the
ManagedFolderMailboxPolicyAllowed parameter.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You can't use the Exchange admin center (EAC ) to perform these procedures. You must use the Shell.
Procedures in this topic require specific permissions. See each procedure for its permissions information.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Block versions of Outlook on a per-mailbox basis

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "User mailboxes" entry in the Recipients Permissions topic.
This example blocks all Outlook versions earlier than 11.8010.8036.
 Set-CASMailbox -Identity [email protected] -MAPIBlockOutlookVersions "-11.8010.8036"

This example restores access to a mailbox that's blocked by a version of Outlook.

Set-CASMailbox -Identity [email protected] -MAPIBlockOutlookVersions $null

For detailed syntax and parameter information, see Set-CASMailbox.

Block Outlook versions on a Client Access server

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "RPC Client Access settings" entry in the Clients and mobile devices permissions
topic.
This example blocks Outlook clients prior to version 12.0.0 from accessing the mailbox on an Exchange 2010 or
later Client Access server.

IMPORTANT
The values used with the BlockedClientVersions parameter are examples. You can determine the correct client software
versions by parsing the RPC Client Access log files located at %ExchangeInstallPath%Logging\RPC Client Access .

Set-RpcClientAccess -Server CAS01 -BlockedClientVersions "0.0.0-5.65535.65535;7.0.0;8.02.4-11.65535.65535"

For detailed syntax and parameter definition, see Set-RpcClientAccess.

 Migrate from managed folders
6/14/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, messaging records management (MRM ) is performed by using retention tags
and retention policies. A retention policy is a group of retention tags that can be applied to a mailbox. For more
details, see Retention tags and retention policies. Managed folders, the MRM technology introduced in Exchange
Server 2007, aren't supported.
A mailbox that has a managed folder mailbox policy applied can be migrated to use a retention policy. To do so, you
must create retention tags that are equivalent to the managed folders linked to the user's managed folder mailbox
policy.

IMPORTANT
Before you migrate from managed folders to retention policies in your production environment, we recommend that you test
the process in a test environment.

TIP
You can place mailboxes on retention hold to halt processing of retention policies or managed folder mailbox policies. Placing
mailboxes on retention hold can be helpful in migration scenarios to avoid deleting messages or moving them to archive until
new policy settings have been tested on test mailboxes or a small number of production mailboxes. For details, see Place a
mailbox on retention hold.

For other management tasks related to MRM, see Messaging Records Management Procedures.

Comparing retention tags to managed folders

Unlike managed folders, which require users to move items to a managed folder based on retention settings,
retention tags can be applied to a folder or an individual item in the mailbox. This process has minimal impact on
the user's workflow and email organization methods. When a folder has retention tags applied, all items in that
folder inherit the retention settings. Users can further specify retention settings by applying different retention tags
to individual items in that folder.
Managed folders support different managed content settings for a folder, each with a different message class (such
as email items or calendar items). Retention tags don't require a separate managed content settings object because
the retention settings are specified in the tag's properties. It isn't supported to create retention tags for particular
message classes, with the exception of a default policy tag (DPT) for voicemail messages. Retention tags also don't
allow you to use journaling performed by the Managed Folder Assistant.

NOTE
Journal rules, which are used to send copies of messages with a journal report to a journaling mailbox, are enforced in the
transport pipeline by the Journaling agent and are independent of MRM. For more details, see Journaling.

The following table compares the MRM functionality available when using retention tags or managed folders.
Retention tags vs. managed folders
 FUNCTIONALITY RETENTION TAGS MANAGED FOLDERS

Specify retention settings for default Use retention policy tags (RPTs) Use managed default folders
folders (such as Inbox)

Specify retention settings for entire Use a default policy tag (DPT) Use managed default folders
mailbox

Use retention settings for custom Use personal tags Using managed custom folders
folders

Require managed content settings No (retention settings included in a Yes

retention tag)

Use retention settings for different No Yes

message classes (such as e-mail
messages, voice mail, or calendar
items)

Support the Move To Archive Yes No

action, which moves items to the
user's archive mailbox

Support the Move To Managed No Yes

Folder action

Allow journaling using the Managed No Yes

Folder Assistant

Policy applied to user Retention policy Managed folder mailbox policy

Maximum number of policies that 1 1

can be applied to a mailbox user

Processed by the Managed Folder Yes Yes

Assistant

Client support Microsoft Outlook 2010 and Outlook 2010, Office Outlook 2007,
Office Outlook Web App and Outlook Web App

What do you need to know before you begin?

Estimated time to complete: 20 minutes.
Procedures in this topic require specific permissions. See each procedure for its permissions information.
You can't use the Exchange admin center (EAC ) to create retention tags based on retention policies.
 For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Migrate mailbox users from managed folders

The following are general steps for migrating users from this managed folder mailbox policy to a retention policy.
Each step is detailed later in this topic:
1. Gather information about managed folder mailbox policies applied to all Exchange 2010 and Exchange 2007
mailboxes, managed folders in each policy and managed content settings for each managed folder. You can
use the EMC or the Shell on an Exchange 2010 or Exchange 2007 server to obtain this information.
2. Create retention tags for the migration.
3. Create a retention policy and link the newly created retention tags to the policy.
4. Remove the managed folder mailbox policy and then apply the retention policy to user mailboxes.

IMPORTANT
After you apply the retention policy to a user and the Managed Folder Assistant runs, the managed folders in the
user's mailbox become unmanaged.

For the following procedures, Contoso mailboxes have a managed folder mailbox policy applied containing the
following managed folders.
Managed folders for Contoso
MANAGED CONTENT
MANAGED FOLDER SETTINGS RETENTION ENABLED RETENTION AGE RETENTION ACTION

Corp- CS-Corp- Yes 30 days Delete and Allow

DeletedItems DeletedItems Recovery

Corp-SentItems CS-Corp- Yes 1,825 days Move to Deleted

SentItems Items

Corp-JunkMail CS-Corp-JunkMail Yes 30 days Permanently

Delete

Corp- CS-Corp- Yes 365 days Move to Deleted

EntireMailbox EntireMailbox Items

30 Days CS-30Days Yes 30 days Move to Deleted

Items

5 Years CS-5Years Yes 1,825 days Move to Deleted

Items

Never Expire CS-NeverExpire No 365 days Not applicable

Step 1: Create retention tags for the migration
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and compliance
permissions topic.
There are two methods you can use for this step:
Create retention tags based on the managed folders and their corresponding managed content
settings: With this method, you use the New-RetentionPolicyTag cmdlet with the
ManagedFolderToUpgrade parameter. When you specify this parameter, the corresponding retention tag is
automatically applied to the managed folder.

IMPORTANT
If the managed folder you want to port has multiple managed content settings for different message classes, only
one retention tag is created, and the highest retention age of all the managed content settings is used as the
retention age for the ported tag, irrespective of the message class of the managed content settings.
For example, review the following managed content settings for the managed folder Corp-DeletedItems.

Create retention tags by manually specifying the retention settings: With this method, you use the
New-RetentionPolicyTag cmdlet without the ManagedFolderToUpgrade parameter. When you don't
specify this parameter, any retention policy tags you add to the policy are applied to the default folders, and
the default policy tag is applied to the entire mailbox. However, any personal tags you add to the policy
aren't automatically applied to the managed folders.

NOTE
If you are in a mixed environment with Exchange 2013 and Exchange 2010 servers, you can use the Port Managed Folder
wizard in the Exchange Management Console (EMC) on an Exchange 2010 server to easily port managed folder and
corresponding managed content setting to retention tags.

Create retention tags based on managed folders

This example creates retention tags based on the corresponding managed content settings shown in the Contoso
managed folder mailbox policy.

New-RetentionPolicyTag Corp-DeletedItems -ManagedFolderToUpgrade Corp-DeletedItems

New-RetentionPolicyTag Corp-SentItems -ManagedFolderToUpgrade Corp-SentItems
New-RetentionPolicyTag Corp-JunkMail -ManagedFolderToUpgrade Corp-JunkMail
New-RetentionPolicyTag Corp-EntireMailbox -ManagedFolderToUpgrade Corp-EntireMailbox
New-RetentionPolicyTag 30Days -ManagedFolderToUpgrade 30Days
New-RetentionPolicyTag 5Years -ManagedFolderToUpgrade 5Years
New-RetentionPolicyTag NeverExpire -ManagedFolderToUpgrade NeverExpire

For detailed syntax and parameter information, see New -RetentionPolicyTag.

Create retention tags manually

NOTE
You can also use the EAC to create retention tags manually (not based on settings in managed folders). For details, see
Create a Retention Policy.

This example creates retention tags based on the managed folders and corresponding managed content settings
shown in the Contoso managed folder mailbox policy. The retention settings are specified manually without using
the ManagedFolderToUpgrade parameter.

New-RetentionPolicyTag Corp-DeletedItems -Type DeletedItems -RetentionEnabled $true -AgeLimitForRetention 30 -

RetentionAction DeleteAndAllowRecovery
New-RetentionPolicyTag Corp-SentItems -Type SentItems -RetentionEnabled $true -AgeLimitforRetention 1825 -
RetentionAction MoveToDeletedItems
New-RetentionPolicyTag Corp-JunkMail -Type JunkMail -RetentionEnabled $true -AgeLimitforRetention 30 -
RetentionAction PermanentlyDelete
New-RetentionPolicyTag Corp-EntireMailbox -Type All -RetentionEnabled $true -AgeLimitForRetention 365 -
RetentionAction MoveToDeletedItems
New-RetentionPolicyTag 30Days -Type Personal -RetentionEnabled $true -AgeLimitForRetention 30 -RetentionAction
MoveToDeletedItems
New-RetentionPolicyTag 5Years -Type Personal -RetentionEnabled $true -AgeLimitForRetention 1825 -
RetentionAction MoveToDeletedItems
New-RetentionPolicyTag NeverExpire -Type Personal -RetentionEnabled $false

For detailed syntax and parameter information, see New -RetentionPolicyTag.

Step 2: Create a retention policy

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and compliance
permissions topic.

NOTE
You can also use the EAC to create a retention policy and add retention tags to the policy. For details, see Create a Retention
Policy.

This example creates the retention policy RP -Corp and links the newly created retention tags to the policy.

New-RetentionPolicy RP-Corp -RetentionPolicyTagLinks Corp-DeletedItems,Corp-SentItems,Corp-JunkMail,Corp-

EntireMailbox,30Days,NeverExpire

For detailed syntax and parameter information, see New -RetentionPolicy.

Step 3: Remove the managed folder mailbox policy from user mailboxes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Applying retention policies" entry in the Messaging policy and compliance
permissions topic.
This example removes the managed folder mailbox policy and any managed folders from Ken Kwok's mailbox.
Managed folders that have any messages are not removed.

Set-Mailbox -Identity Kwok -RemoveManagedFolderAndPolicy RP-Corp

Step 4: Apply the retention policy to user mailboxes

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Applying retention policies" entry in the Messaging policy and compliance
permissions topic.
 NOTE
You can also use the EAC to apply a retention policy to users. For details, see Apply a retention policy to mailboxes.

This example applies the newly created retention policy RP -Corp to the mailbox user Ken Kwok.

Set-Mailbox -Identity Kwok -RetentionPolicy RP-Corp

For detailed syntax and parameter information, see Set-Mailbox.

How do you know this task worked?

To verify that you have migrated from managed folders to retention policies, do the following:
Generate a report of all user mailboxes and the retention policy applied to them.
This command retrieves the retention policy applied to all mailboxes in an organization, and their retention
hold status.

Get-Mailbox -ResultSize unlimited -Filter {Name -NotLike "DiscoverySearch*"} | Format-Table

Name,RetentionPolicy,RetentionHoldEnabled -Auto

After the Managed Folder Assistant has processed a mailbox with a retention policy, use the Get-
RetentionPolicyTag cmdlet to retrieve the retention tags provisioned in the user mailbox.
This command retrieves the retention tags actually applied to April Stewart's mailbox.

Get-RetentionPolicyTag -Mailbox astewart

 Turn off or suspend messaging records management
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

To meet individual, IT, or business requirements, you may need to turn off or temporarily suspend messaging
records management (MRM ) for an individual user or for a Mailbox server. Reasons you may need to turn off or
suspend MRM include:
If a mailbox user is away from the office or is otherwise unable to access e-mail, you can temporarily disable
MRM for the mailbox by placing it on retention hold. When a mailbox is on retention hold, it's no longer
processed by the Managed Folder Assistant. When the mailbox user returns or is able to access the mailbox
again, you can remove the retention hold from the mailbox.
If you need to test or troubleshoot performance issues, you can temporarily turn off MRM on that server by
clearing the schedule for the Managed Folder Assistant.
If you need to remove a retention tag from mailboxes (which have a retention policy with that tag applied),
you can remove the tag from the policy.
If you want a retention policy or a managed folder mailbox policy to no longer apply to a mailbox, you can
remove the policy from the mailbox.
If your organization decides not to use MRM features, you can turn off MRM permanently for the entire
organization. If you later decide to deploy MRM, you have the ability to do so.

What do you need to know before you begin?

Estimated time to complete: 1 minute
Procedures in this topic require specific permissions. See each procedure for its permissions information.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Place mailboxes on retention hold

You can place mailboxes on retention hold to turn off MRM temporarily (for example when users are on vacation).
This suspends the processing of retention policies for the mailbox until retention hold is disabled. This is different
from placing mailboxes on In-Place Hold or litigation hold.
For details about how to place a mailbox on retention hold, see Place a mailbox on retention hold.
To learn more about In-Place Hold and litigation hold, see In-Place Hold and Litigation Hold.

Remove retention tags from mailboxes

To remove a retention tag from a mailbox, you unlink the tag from the retention policy. When you unlink a
retention policy tag (RPT) for a default folder, the default mailbox tag applies to all items in that folder. When you
unlink a personal tag, it's no longer available to the user. Tags applied to existing messages will continue to be
processed unless you remove the tag from the Exchange organization.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and compliance
permissions topic.
This Shell example unlinks the retention tag Delete - 3 Days from the retention policy Corp-Users.

$tags = (Get-RetentionPolicy "Corp-Users").RetentionPolicyTagLinks

$tags -= "Deleted Items - 3 Days"
Set-RetentionPolicy "Corp-Users" -RetentionPolicyTagLinks $tags

For detailed syntax and parameter information, see Get-RetentionPolicy and Set-RetentionPolicy.

Remove retention policies from mailboxes

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Apply retention policies" entry in the Messaging policy and compliance
permissions topic.
You can stop a retention policy from applying to a mailbox by removing the policy from the mailbox user's
properties.
This Shell example removes the retention policy from the mailbox jpeoples.

Set-Mailbox jpeoples -RetentionPolicy $null.

This Shell example removes the retention policy from all mailboxes in the Exchange organization.

Get-Mailbox -ResultSize unlimited -Filter {RetentionPolicy -ne $null} | Set-Mailbox -RetentionPolicy $null

This Shell example removes the retention policy Corp-Finance from all mailbox users who have the policy applied.

Get-Mailbox -ResultSize unlimited -Filter {RetentionPolicy -eq "Corp-Finance"} | Set-Mailbox -RetentionPolicy

$null

For detailed syntax and parameter information, see Set-Mailbox and Get-Mailbox.

Turn off MRM permanently for an entire organization

To turn off MRM for an organization, delete all retention tags and retention policies except for the
ArbitrationMailbox policy, which is created by Exchange Setup. After this is complete, retention policies aren't
enforced.

WARNING
Retention policies also include Move to Archive tags, which move messages to the user's archive mailbox. If you remove a
retention policy that has a Move to Archive tag, users who had the policy applied will no longer have messages moved to the
archive by the Managed Folder Assistant.
To avoid this, remove only the Delete and Allow Recovery and Permanently Delete tags from your organization and keep the
policies that have the Move to Archive tags applied. Alternatively, users who have and archive enabled could manually move
items to their archive mailbox using Outlook or Outlook Web App.
Before removing retention tags or retention policies, we recommend that you check the settings of the tags being removed.
Don't delete tags with the Move to Archive retention action.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Messaging records management" entry in the Messaging policy and compliance
permissions topic.

NOTE
Include the WhatIf switch in the following commands to simulate the action taken by a command.

This example removes all delete tags from an Exchange organization except the Never Delete tag, which is used in
the ArbitrationMailbox policy created by Exchange Setup.

Get-RetentionPolicyTag | ? {$_.RetentionAction -ne "MoveToArchive" -and $_.Name -ne "Never Delete"} | Remove-
RetentionPolicyTag

This example removes all retention tags except the Never Delete tag.

Get-RetentionPolicyTag | ? {$_.Name -ne "Never Delete"} | Remove-RetentionPolicyTag

This command removes the Corp-Users retention policy from an Exchange organization.

Remove-RetentionPolicy Corp-Users

For detailed syntax and parameter information, see the following topics:
Get-RetentionPolicyTag
Remove-RetentionPolicyTag
Remove-RetentionPolicy
 Monitoring messaging records management
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

View performance counters for messaging records management
Performance counters for messaging records management
Messaging records management errors and events
 View performance counters for messaging records
management
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use Windows Reliability and Performance Monitor (Perfmon.exe) to select and view performance counters
for messaging records management (MRM ). By using performance counters, you can monitor the Managed Folder
Assistant while it runs resource-intensive MRM processes.
For a list of performance counters for MRM, see Performance counters for messaging records management.
Looking for other tasks related to monitoring MRM? Check out Monitoring messaging records management.

Use Windows Reliability and Performance Monitor to view performance

counters for MRM
To perform this procedure, the account you use must be delegated membership in the local Administrators group.
1. To start Windows Reliability and Performance Monitor, click Start, click Run, and then type perfmon.
2. In the console tree, navigate to Monitoring Tools > Performance Monitor.
3. Click the plus sign (+) button on the toolbar. The Add Counters dialog box appears.
4. From the Select counter from computer list, select one of the following options:
If you are performing this procedure on a local computer, select <Local computer>. This is the
default selection.
If you are performing this procedure remotely, select the server you want to monitor.
5. In the list of performance counters, expand MSExchange Assistants - Per Database or the MSExchange
Managed Folder Assistant.
6. Select the performance counters you want to monitor.
7. For performance counters under MSExchange Assistants - Per Database, to view the counters for all
mailbox databases, in Instances of selected object, click All instances. Or, to specify one or more mailbox
databases, select instances from the list.
8. To add the selected counters so that the counters appear in Windows Reliability and Performance Monitor,
and to begin collecting performance data, click Add.
 Performance counters for messaging records
management
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

The performance counters in this topic monitor the Managed Folder Assistant as it implements messaging records
management (MRM ) for Microsoft Exchange Server 2010. Because running the Managed Folder Assistant is a
resource-intensive process, you should run it only when your server can tolerate the additional load. You should
also monitor server performance when the Managed Folder Assistant is running. In addition to the performance
counters listed in this topic, you may also want to monitor additional performance counters that monitor items
such as disk performance and CPU usage.
For more information about monitoring computers running MRM, see Monitoring messaging records
management.

Performance Counters for MRM

The following table describes performance counters for MRM.
Performance counters, performance objects, and description
PERFORMANCE COUNTER PERFORMANCE OBJECT DESCRIPTION

Average Mailbox Processing Time In MSExchange Assistants Counts the average processing time
Seconds of mailboxes for time-based
assistants.

Mailboxes Processed MSExchange Assistants Counts the number of mailboxes

processed by time-based assistants
since the service started.

Mailboxes processed/sec MSExchange Assistants Determines the rate of mailboxes

processed by time-based assistants
per second.

Items Deleted but Recoverable MSExchange Managed Folder Counts the number of items
Assistant deleted by the Managed Folder
Assistant since the start of the most
recent schedule interval. (The items
are still recoverable through the
Recoverable Items folder.) The
number includes items in the
mailboxes scheduled for processing
during the schedule interval and
items in any mailboxes that you
specified for processing. This
counter is reset to zero at the start
of each schedule interval.
PERFORMANCE COUNTER PERFORMANCE OBJECT DESCRIPTION

Items Journaled MSExchange Managed Folder Counts the number of items

Assistant journaled by the Managed Folder
Assistant since the start of the most
recent schedule interval. The
number includes items in the
mailboxes scheduled for processing
during the current work cycle and
items in any mailboxes you specified
for processing. This counter is reset
to zero at the start of each work
cycle.

Items Marked as Past Retention MSExchange Managed Folder Counts the number of items
Date Assistant marked as past their retention date
by the Managed Folder Assistant
since the start of the most recent
schedule interval. The number
includes items in mailboxes
scheduled for processing during the
schedule interval and items in any
mailboxes you specified for
processing. This counter is reset to
zero at the start of each schedule
interval.

Items Moved MSExchange Managed Folder Counts the number of items moved
Assistant by the Managed Folder Assistant
since the start of the most recent
schedule interval. The number
includes items in the mailboxes
scheduled for processing during the
schedule interval and items in any
mailboxes you specified for
processing. This counter is reset to
zero at the start of each schedule
interval.

Items Permanently Deleted MSExchange Managed Folder Counts the number of items
Assistant permanently deleted by the
Managed Folder Assistant since the
beginning of the most recent
schedule interval. The number
includes items in the mailboxes
scheduled for processing during the
schedule interval and items in any
mailboxes you specified for
processing. This counter is reset to
zero at the beginning of each
schedule interval.
PERFORMANCE COUNTER PERFORMANCE OBJECT DESCRIPTION

Items Subject to Retention Policy MSExchange Managed Folder Counts the number of items subject
Assistant to retention policy by the Managed
Folder Assistant since the start of
the most recent schedule interval.
The number includes items in the
mailboxes scheduled for processing
during the schedule interval and
items in any mailboxes you specified
for processing. This counter is reset
to zero at the start of each schedule
interval. This counter is the sum of
the following four expiration-related
counters:
Items Journaled
Items Marked as Past
Retention Date
Items Moved
Items Permanently Deleted

TotalSizeItemsExpired - Size of Items MSExchange Managed Folder Indicates the total size of items
subject to Retention Policy (In Assistant expired by the Managed Folder
Bytes) Assistant (SoftDelete, HardDelete,
MoveToArchive).
The following items are included:
Messages subject to
deletion or move to a
managed custom folder by a
managed folder mailbox
policy
Messages subject to
deletion or move to archive
by the user's retention policy
Messages expired by
dumpster policy
Messages cleaned up by
system cleanup tags
This counter is reset to zero at
every work cycle checkpoint of the
Managed Folder Assistant work
cycle.
PERFORMANCE COUNTER PERFORMANCE OBJECT DESCRIPTION

TotalSizeItemsSoftDeleted - Size of MSExchange Managed Folder Indicates the total size of items soft
Items Deleted but Recoverable (In Assistant deleted by the Managed Folder
Bytes) Assistant.
The following items are included:
Messages soft deleted by a
managed folder mailbox
policy
Messages soft deleted by a
retention policy
This counter is reset to zero at
every work cycle checkpoint of the
Managed Folder Assistant work
cycle.

TotalSizeItemsPermanentlyDeleted - MSExchange Managed Folder Indicates the total size of items soft
Size of Items Permanently Deleted Assistant deleted by the Managed Folder
(In Bytes) Assistant.
The following items are included:
Messages hard deleted by a
managed folder mailbox
policy
Messages hard deleted by a
retention policy
Messages hard deleted by
the Recoverable Items policy
This counter is reset to zero at
every work cycle checkpoint of the
Managed Folder Assistant work
cycle.

TotalSizeItemsMoved - Size of Items MSExchange Managed Folder Indicates the total size of items
Moved due to an Archive policy tag Assistant moved to a folder or moved to
(In Bytes) archive by the Managed Folder
Assistant.
The following items are included:
Messages moved to a
managed custom folder by a
managed folder mailbox
policy
Messages moved to the
personal archive by a
retention policy
This counter is reset to zero at
every work cycle checkpoint of the
Managed Folder Assistant work
cycle.
PERFORMANCE COUNTER PERFORMANCE OBJECT DESCRIPTION

TotalItemsWithPersonalTag - Items MSExchange Managed Folder Indicates the number of times a

stamped with Personal Tag (Expiry Assistant user tags items with a personal tag.
or Archive)
This includes both Deletion and
Archive tags.
For example:
An item is tagged with a
personal tag.
An item with a personal tag
is retagged with another
personal tag.
If a folder is tagged with a personal
tag, the counter is incremented by
the total number of items in the
folder.

TotalItemsWithDefaultTag - Items MSExchange Managed Folder Indicates the number of items

stamped with Default Tag (Expiry or Assistant assigned a default policy tag (DPT)
Archive) based on a user action, for example,
when a user selects a message with
a personal tag and selects Use
folder policy.
If a new user is assigned a retention
policy with a DPT, the counter is
incremented by the number of
items that will be assigned the DPT
due to the retention policy.

NOTE
If a user has a retention policy
with a DPT, new messages that
arrive through transport get a
default tag, and this isn't tracked
by this counter.

TotalItemsWithSystemCleanupTag - MSExchange Managed Folder Indicates the number of items

Items stamped with System Assistant tagged with the system cleanup
Cleanup Tag tag. This includes mailbox metadata
items that aren't visible to users.

TotalItemsExpiredByDefaultExpiryTa MSExchange Managed Folder Indicates the number of items

g - Items expired due to a default Assistant expired (soft or hard deleted) by the
Expiry Tag Managed Folder Assistant due to
any non-personal (default or
system) tag in a retention policy.
This doesn't include the items
expired by Recoverable Items clean
up or system clean up.
PERFORMANCE COUNTER PERFORMANCE OBJECT DESCRIPTION

TotalItemsExpiredByPersonalExpiryT MSExchange Managed Folder Indicates the number of items

ag - Items expired due to a Assistant expired (soft or hard deleted) by the
personal Expiry Tag Managed Folder Assistant due to a
personal tag in the retention policy.

TotalItemsMovedByDefaultArchiveT MSExchange Managed Folder Indicates the number of items

ag - Items moved due to a default Assistant moved to the archive by the
Archive Tag Managed Folder Assistant due to
any non-personal (default or
system) archive tag in a retention
policy.
This doesn't include the items
moved to the Recoverable Items
folder in archive by Recoverable
Items cleanup.

TotalItemsMovedByPersonalArchive MSExchange Managed Folder Indicates the number of items

Tag - Items Moved due to an Assistant moved to the archive by the
Archive Tag Managed Folder Assistant due to a
personal archive tag in a retention
policy.

TotalMovedDumpsterItems - MSExchange Managed Folder Indicates the number of items

Mailbox Dumpsters Moved Items Assistant moved to the Recoverable Items
folder in the archive by Recoverable
Items cleanup.
 Messaging records management errors and events
5/28/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Messaging records management (MRM ) generates events that you can view in Event Viewer. This allows you to
troubleshoot and verify the performance of the Managed Folder Assistant. Event Viewer tracks the following kinds
of events in the following order, based on importance:
1. Error events
2. Warning events
3. Informational events

MRM Errors and Events

The following tables provide lists of events that you can use to troubleshoot MRM. The logging types include the
following:
Events labeled as LogAlways are always logged individually.
Events labeled as LogPeriodic are logged only once in any five-minute period, not every time they occur.
This helps to prevent excessive log entries.
MRM events in the Managed Folder Assistant category
VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

10003 Managed Folder Error LogPeriodic Could not get the

Assistant server
configuration
object from Active
Directory.
<Exception
details>. Check
for domain
controller
network
connectivity
issues or incorrect
DNS
configuration.
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

10004 Managed Folder Error LogAlways The retention

Assistant policy for folder
<folder> in
mailbox
<mailbox> will
not be applied.
The managed
folder assistant is
unable to process
managed content
setting <content
setting> for the
managed folder
<managed
folder>. The
RetentionAction is
MoveToFolder
but a destination
folder was not
specified. Please
specify a
destination folder.

10005 Managed Folder Error LogAlways Retention policy

Assistant will not be applied
to folder
<folder> in
mailbox
<mailbox>.
Unable to process
Managed
Content Setting
<content
setting> for the
Managed Folder
<managed
folder>. The
RetentionAction is
MoveToFolder
but the
destination folder
<folder> is the
same as the
source folder
<folder>. Please
specify a
destination folder
that is different
from the source
folder.
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

10009 Managed Folder Error LogAlways The managed

Assistant folder assistant
skipped
processing all
databases on the
local server
because it could
not read the audit
log parameters
from Active
Directory. It will
try again later in
the schedule
window. Current
database:
<database>

10010 Managed Folder Error LogAlways The managed

Assistant folder assistant
skipped
processing all
databases on the
local server
because the audit
log is enabled but
the path to the
audit log is
missing in Active
Directory. It will
try again later in
the schedule
window. Current
database:
<database>

10011 Managed Folder Error LogAlways The managed

Assistant folder assistant
could not
configure the
audit log. It will
stop processing
the current
database: '%1'. It
will try again later
in the schedule
window. Exception
details: <details>
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

10012 Managed Folder Error LogAlways The managed

Assistant folder assistant
did not write to
the audit log. It
will stop
processing the
current database:
<database>. It
will try to write to
the audit log
again later in the
schedule window.
Exception details:
<details>

10017 Managed Folder Error LogAlways An exception

Assistant occurred in the
Managed Folder
Assistant while it
was processing
Mailbox:
<mailbox>
Folder: Name:
<folder name>
Id: <folder ID>
Item: Ids: <IDs>.
Exception:
<exception>.

MRM events in the Assistants category

VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

9004 Assistants Warning LogAlways Service <service>.

<service> failed
to process
mailbox
<mailbox>. The
following
exception caused
the failure:
<exception>

9014 Assistants Warning LogAlways Service <service>.

Unable to process
schedule changes.
The following
exception caused
the failure:
<exception>
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

9017 Assistants Information LogAlways Service <service>.

<service> for
database
<database> is
entering a
scheduled time
window. There are
<number>
mailboxes to
process.

9018 Assistants Information LogAlways Service <service>.

<service> for
database
<database> is
exiting a
scheduled time
window.
<number> out of
<number>
mailboxes were
successfully
processed.
<number>
mailboxes were
skipped due to
errors. <number>
mailboxes were
processed
separately.
<number>
mailboxes were
not processed
due to insufficient
time.

NOTE
The Managed
Folder
Assistant will
resume where
it left off the
next time it
runs.
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

9019 Assistants Warning LogPeriodic Service <service>.

Unable to save
progress for
<service> on
database
<database>. (The
assistant was
unable to save
where it stopped
so that it could
resume there
when it restarts.)
The following
exception caused
the failure:
<exception>

9020 Assistants Warning LogAlways Service <service>.

<assistant
name> failed to
start for database
<database>. The
following
exception caused
the failure:
<exception>

9021 Assistants Information LogAlways Service <service>.

<service> for
database
<database> is
processing an on-
demand request.
There are
<number>
mailboxes to
process.

9022 Assistants Information LogAlways Service <service>.

<service> for
database
<database> has
finished an on-
demand request.
<number> out of
<number>
mailboxes were
successfully
processed.
<number>
mailboxes were
skipped due to
errors.
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

9023 Assistants Warning LogAlways Service <service>.

<service> failed
to start time
window
processing on
database
<database>. The
following
exception caused
the failure:
<exception>

9025 Assistants Information LogAlways Service <service>.

<service>
skipped
<number>
mailboxes on
database
<database>.
Mailboxes:
<mailboxes>

9026 Assistants Warning LogAlways Service <service>.

<service> failed
to start on-
demand
processing on
database
<database>. The
following
exception caused
the failure:
<exception>

9027 Assistants Error LogAlways Service <service>.

<service> caused
the process to
terminate
<number> times
while processing
mailbox
<mailbox> on
database
<database>. This
mailbox will no
longer be
processed in the
requested time
window or on-
demand request.
The following
exception caused
the failure:
<exception>
 VALUE OR
EVENT ID CATEGORY EVENT TYPE LOGGING DESCRIPTION

9028 Assistants Warning LogAlways Service <service>.

<service> caused
the process to
terminate
<number> times
while processing
mailbox
<mailbox> on
database
<database>. The
following
exception caused
the failure:
<exception>

9033 Assistants Warning LogAlways Service <service>.

<service> for
database
<database>
received an on-
demand request.
However, there
are no mailboxes
to process.

9034 Assistants Information LogAlways Service <service>

halted time based
operations for
managed folder
assistant on
database
<database>.

9035 Assistants Warning LogAlways Service <service>.

<assistant
name> was
unable to process
<number>
mailboxes
because
insufficient time.

9037 Assistants Error LogAlways Service <service>.

An exception was
encountered
while processing a
RPC. Method:
<method>,
Exception:
<exception>
 Journaling
6/14/2019 • 12 minutes to read • Edit Online

Applies to: Exchange Server 2013

Journaling can help your organization respond to legal, regulatory, and organizational compliance requirements
by recording inbound and outbound email communications. When planning for messaging retention and
compliance, it's important to understand journaling, how it fits in your organization's compliance policies, and how
Microsoft Exchange Server 2013 helps you secure journaled messages.

Why journaling is important

First, it's important to understand the difference between journaling and a data archiving strategy:
Journaling is the ability to record all communications, including email communications, in an organization
for use in the organization's email retention or archival strategy. To meet an increasing number of
regulatory and compliance requirements, many organizations must maintain records of communications
that occur when employees perform daily business tasks.
Data archiving refers to backing up the data, removing it from its native environment, and storing it
elsewhere, therefore reducing the strain of data storage. You can use Exchange journaling as a tool in your
email retention or archival strategy.
Although journaling may not be required by a specific regulation, compliance may be achieved through journaling
under certain regulations. For example, corporate officers in some financial sectors may be held liable for the
claims made by their employees to their customers. To verify that the claims are accurate, a corporate officer may
set up a system where managers review some part of employee-to-client communications regularly. Every
quarter, the managers verify compliance and approve their employees' conduct. After all managers report
approval to the corporate officer, the corporate officer reports compliance, on behalf of the company, to the
regulating body. In this example, email messages might be one type of the employee-to-client communications
that managers must review; therefore, journaling can be used to collect all email messages sent by client-facing
employees. Other client communication mechanisms may include faxes and telephone conversations, which may
also be subject to regulation. The ability to journal all classes of data in an enterprise is a valuable functionality of
the IT architecture.
The following list shows some of the more well-known U.S. and international regulations where journaling may
help form part of your compliance strategies:
Sarbanes-Oxley Act of 2002 (SOX)
Security Exchange Commission Rule 17a-4 (SEC Rule 17 A-4)
National Association of Securities Dealers 3010 & 3110 (NASD 3010 & 3110)
Gramm-Leach-Bliley Act (Financial Modernization Act)
Financial Institution Privacy Protection Act of 2001
Financial Institution Privacy Protection Act of 2003
Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct
Terrorism Act of 2001 (Patriot Act)
 European Union Data Protection Directive (EUDPD )
Japan's Personal Information Protection Act

Journaling agent
In an Exchange 2013 organization, all email traffic is routed by Mailbox servers. All messages traverse at least one
server running the Transport service in their lifetime. The Journaling agent is a compliance-focused transport
agent that processes messages on Mailbox servers. It fires on the OnSubmittedMessage and
OnRoutedMessage transport events.

NOTE
In Exchange 2013, the Journaling agent is a built-in agent. Built-in agents aren't included in the list of agents returned by
the Get-TransportAgent cmdlet. For more details, see Transport agents.

Exchange 2013 provides the following journaling options:

Standard journaling: Standard journaling is configured on a mailbox database. It enables the Journaling
agent to journal all messages sent to and from mailboxes located on a specific mailbox database. To journal
all messages to and from all recipients and senders, you must configure journaling on all mailbox databases
on all Mailbox servers in the organization.
Premium journaling: Premium journaling enables the Journaling agent to perform more granular
journaling by using journal rules. Instead of journaling all mailboxes residing on a mailbox database, you
can configure journal rules to match your organization's needs by journaling individual recipients or
members of distribution groups. You must have an Exchange Enterprise client access license (CAL ) to use
premium journaling.
When you enable standard journaling on a mailbox database, this information is saved in Active Directory and is
read by the Journaling agent. Similarly, journal rules configured with premium journaling are also saved in Active
Directory and applied by the Journaling agent. For more information about how to configure standard and
premium journaling, see Manage journaling.

Journal rules
The following are key aspects of journal rules:
Journal rule scope: Defines which messages are journaled by the Journaling agent.
Journal recipient: Specifies the SMTP address of the recipient you want to journal.
Journaling mailbox: Specifies one or more mailboxes used for collecting journal reports.

Journal rule scope

You can use a journal rule to journal only internal messages, only external messages, or both. The following list
describes these scopes:
Internal messages only: Journal rules with the scope set to journal internal messages sent between the
recipients inside your Exchange organization.
External messages only: Journal rules with the scope set to journal external messages sent to recipients
or received from senders outside your Exchange organization.
All messages: Journal rules with the scope set to journal all messages that pass through your organization
regardless of origin or destination. These include messages that may have already been processed by
 journal rules in the Internal and External scopes.

Journal recipient
You can implement targeted journaling rules by specifying the SMTP address of the recipient you want to journal.
The recipient can be an Exchange mailbox, distribution group, mail user, or contact. These recipients may be
subject to regulatory requirements, or they may be involved in legal proceedings where email messages or other
communications are collected as evidence. By targeting specific recipients or groups of recipients, you can easily
configure a journaling environment that matches your organization's processes and meets regulatory and legal
requirements. Targeting only the specific recipients that need to be journaled also minimizes storage and other
costs associated with retention of large amounts of data.
All messages sent to or from the journaling recipients you specify in a journaling rule are journaled. If you specify
a distribution group as the journaling recipient, all messages sent to or from members of the distribution group
are journaled. If you don't specify a journaling recipient, all messages sent to or from recipients that match the
journal rule scope are journaled.
Unified Messaging-enabled journal recipients
Many organizations that implement journaling may also use Unified Messaging (UM ) to consolidate their email,
voice mail, and fax infrastructure. However, you may not want the journaling process to generate journal reports
for messages generated by Unified Messaging. In these cases, you can decide whether to journal voice mail
messages and missed call notification messages handled by an Exchange server running the Unified Messaging
service or to skip such messages. If your organization doesn't require journaling of such messages, you can reduce
the amount of hard disk storage space required to store journal reports by skipping these messages.

NOTE
Messages that contain faxes generated by a the Unified Messaging service are always journaled, even if you disable the
journaling of Unified Messaging voice mail and missed call notification messages.

For more information about how to enable or disable voice mail and missed call notification messages, see
Disable or enable journaling of voice mail and missed call notifications.

Journaling mailbox
The journaling mailbox is used to collect journal reports. How you configure the journaling mailbox depends on
your organization's policies, regulatory requirements, and legal requirements. You can specify one journaling
mailbox to collect messages for all the journal rules configured in the organization, or you can use different
journaling mailboxes for different journal rules or sets of journal rules.

IMPORTANT
You can't designate an Office 365 mailbox as a journaling mailbox. You can deliver journal reports to an on-premises
archiving system or a third-party archiving service. If you're running a hybrid deployment with your mailboxes split between
on-premises servers and Office 365, you can designate an on-premises mailbox as the journaling mailbox for your Office
365 and on-premises mailboxes.
 IMPORTANT
Journaling mailboxes contain very sensitive information. You must secure journaling mailboxes because they collect
messages that are sent to and from recipients in your organization. These messages may be part of legal proceedings or
may be subject to regulatory requirements. Various laws require that messages remain tamper-free before they're submitted
to an investigatory authority. We recommend that you create policies that govern who can access the journaling mailboxes
in your organization, limiting access to only those individuals who have a direct need to access them. Speak with your legal
representatives to make sure that your journaling solution complies with all the laws and regulations that apply to your
organization.

IMPORTANT
Journaling mailboxes should accept messages up to a size equal to or greater than the maximum message size you have set
in your organization. If you have configured exceptions to the MaxSendSize and MaxReceiveSize on an individual user's
mailbox that are bigger than the general setting in TransportConfig, you should set the journaling mailbox's MaxSendSize
and MaxReceiveSize accordingly to ensure that messages sent to journaling are accepted and not queued or rejected.
Messages rejected by the journaling mailbox will be retried periodically, causing unnecessary database growth and waste of
resources. In addition, we recommend that you set up an alternate journaling mailbox to prevent other non-deliverable
situations from occurring.

Alternate journaling mailbox

When the journaling mailbox is unavailable, you may not want the undeliverable journal reports to collect in mail
queues on Mailbox servers. Instead, you can configure an alternate journaling mailbox to store those journal
reports. The alternate journaling mailbox receives the journal reports as attachments in the non-delivery reports
(NDRs) generated when the journaling mailbox or the server on which it's located refuses delivery of the journal
report or becomes unavailable.
When the journaling mailbox becomes available again, you can use the Send Again feature of OfficeOutlook to
submit journal reports for delivery to the journaling mailbox.
When you configure an alternate journaling mailbox, all the journal reports that are rejected or can't be delivered
across your entire Exchange organization are delivered to the alternate journaling mailbox. Therefore, it's
important to make sure that the alternate journaling mailbox and the Mailbox server where it's located can
support many journal reports.

WARNING
If you configure an alternate journaling mailbox, you must monitor the mailbox to make sure that it doesn't become
unavailable at the same time as the journal mailboxes. If the alternate journaling mailbox also becomes unavailable or rejects
journal reports at the same time, the rejected journal reports are lost and can't be retrieved.

Because the alternate journaling mailbox collects all the rejected journal reports for the entire Exchange
organization, you must make sure that this doesn't violate any laws or regulations that apply to your organization.
If laws or regulations prohibit your organization from allowing journal reports sent to different journaling
mailboxes from being stored in the same alternate journaling mailbox, you may be unable to configure an
alternate journaling mailbox. Discuss this with your legal representatives to determine whether you can use an
alternate journaling mailbox.
When you configure an alternate journaling mailbox, you should use the same criteria that you used when you
configured the journaling mailbox.
 IMPORTANT
The alternate journaling mailbox should be treated as a special dedicated mailbox. Any messages addressed directly to the
alternate journaling mailbox aren't journaled.

Journal rule replication

Journal rules are stored in Active Directory and applied by all Mailbox servers in the Exchange 2013 organization.
When you create, modify, or remove a journal rule, the change is replicated to all Active Directory servers in the
organization. All Mailbox servers in the organization then retrieve the updated journal rule configuration from the
Active Directory servers and apply the new or modified journal rules.
By replicating all the journal rules across the organization, Exchange 2013 enables you to provide a consistent set
of journal rules across the organization. All messages that pass through your Exchange 2013 organization are
subject to the same journal rules.

IMPORTANT
Replication of journal rules across an organization is dependant on Active Directory replication. Replication time between
Active Directory domain controllers varies depending on the number of sites in the organization and the speed of links and
other factors outside the control of Microsoft Exchange. Consider replication delays when you implement journal rules in
your organization. For more information about Active Directory replication, see Introduction to Active Directory Replication
and Topology Management Using Windows PowerShell.

IMPORTANT
Each Mailbox server caches distribution group membership to avoid repeated round trips to Active Directory. The expanded
groups cache reduces the number of requests that each Mailbox server must make to an Active Directory domain controller.
By default, entries in the expanded groups cache expire in four hours. Therefore, if you specify a distribution group as the
journal recipient, changes to distribution group membership may not be applied to journal rules until the expanded groups
cache is updated. To force an immediate update of the recipient cache, you must stop and start the Microsoft Exchange
Transport service. You must do this for each Mailbox server where you want to forcibly update the recipient cache.

Journal reports
A journal report is the message that the Journaling agent generates when a message matches a journal rule and is
to be submitted to the journaling mailbox. The original message that matches the journal rule is included
unaltered as an attachment to the journal report. The body of a journal report contains information from the
original message such as the sender email address, message subject, message-ID, and recipient email addresses.
This is also referred to as envelope journaling, and is the only journaling method supported by Exchange 2013.

Journal reports and IRM-protected messages

When implementing journaling in an Exchange 2013 environment, you must consider journaling reports and
IRM -protected messages. IRM -protected messages will affect the search and discovery capabilities of third-party
archiving systems that don't have RMS support built-in. In Exchange 2013, you can configure Journal Report
Decryption to save a clear-text copy of the message in a journal report.

Interoperability with Exchange 2007

There isn't much difference between journaling functionality in Exchange 2013, Exchange 2010, and Exchange
2007. However, in Exchange 2010 and later, Setup creates a separate container in Active Directory to store journal
rules. When you set up the first Exchange 2010 or later server in an Exchange 2007 organization, Setup creates a
copy of the existing journal rules in Exchange 2007 and stores them in the new container. When Setup completes,
the journal rules in both versions of Exchange are consistent.
After Setup, if you change the journal rule configuration on Exchange 2010 (or later), you must make the same
change on Exchange 2007 servers to make sure they're consistent. Similarly, changes made to Journal rules on
Exchange 2007 must be also be made in Exchange 2010 or later. You can also export journal rules from Exchange
2007 and import them to Exchange 2013.

Troubleshooting
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server. If you're having
trouble with the JournalingReportDNRTo mailbox, see Transport and Mailbox Rules in Exchange Online don't
work as expected.
 Manage journaling in Exchange 2013
6/18/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Journaling can help your organization respond to legal, regulatory, and organizational compliance requirements by
recording inbound and outbound email communications. This topic shows you how to perform basic tasks related
to managing journaling in Exchange 2013.
Standard journaling is configured on a mailbox database. It enables the Journaling agent to journal all messages
sent to and from mailboxes located on a specific mailbox database. You can also use premium journaling enables
the Journaling agent to perform more granular journaling by using journal rules. Instead of journaling all
mailboxes residing on a mailbox database, you can configure journal rules to match your organization's needs by
journaling individual recipients or members of distribution groups. You must have an Exchange Enterprise client
access license (CAL ) to use premium journaling.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Journaling" entry in the Messaging policy and compliance permissions topic.
A journaling mailbox has been created, or an existing mailbox is available for use as the journaling mailbox.
You can't designate an Exchange Online mailbox as a journaling mailbox. You can deliver journal reports to
an on-premises archiving system or a third-party archiving service. If you're running a hybrid deployment
with your mailboxes split between on-premises servers and Exchange Online, you can designate an on-
premises mailbox as the journaling mailbox for your Exchange Online and on-premises mailboxes.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Create a journal rule

Use the EAC to create a journal rule
1. In the EAC, go to Compliance management > Journal rules, and then click Add .
2. In Journal rule, provide a name for the journal rule and then compete the following fields:
If the message is sent to or received from Specify the recipient that the rule will target. You can
either select a specific recipient or apply the rule to all messages.
Journal the following messages Specify the scope of the journal rule. You can journal only the
internal messages, only the external messages, or all messages regardless of origin or destination.
Send journal reports to Type the address of the journaling mailbox that will receive all the journal
reports.
 NOTE
You can also type the display name or alias of a mail user or a mail contact as the journal mailbox. In this case,
journal reports will be sent to the external email address of the mail user or mail contact. But as previously
explained, the external email address of a mail user or mail contact can't be the address of an Exchange Online
mailbox.

3. Click Save to create the journal rule.

Use the Shell to create a journal rule
This example creates the journal rule Discovery Journal Recipients to journal all messages sent from and received
by the recipient [email protected].

New-JournalRule -Name "Discovery Journal Recipients" -Recipient [email protected] -JournalEmailAddress "Journal

Mailbox" -Scope Global -Enabled $True

How do you know this worked?

To verify that you have successfully created the journal rule, do one of the following:
From the EAC, verify that the new journal rule you created is listed on the Journal rules tab.
From the Shell, verify that the new journal rule exists by running the following command (the example
below verifies the rule created in the Shell example above):

Get-JournalRule "Discovery Journal Recipients"

View or modify a journal rule

Use the EAC to view or modify a journal rule
1. In the EAC, go to Compliance management > Journal rules.
2. In the list view, you'll see all the journal rules in your organization.
3. Double-click the rule you want to view or modify.
4. In Journal Rule, modify the settings you want. For more information about the settings in this dialog box,
see the procedure Use the EAC to create a journal rule earlier in this topic.
Use the Shell to view or modify a journal rule
This example displays a summary list of all journal rules in the Exchange organization:

Get-JournalRule

This example retrieves the journal rule Brokerage Journal Rule, and pipes the output to the Format-List command
to display rule properties in a list format:

Get-JournalRule "Brokerage Journal Rule" | Format-List

If you want to modify the properties of a specific rule, you need to use the Set-JournalRule cmdlet. This example
changes the name of the journal rule JR-Sales to TraderVault . The following rule settings are also changed:
Recipient
 JournalEmailAddress
Scope

Set-JournalRule JR-Sales -Name TraderVault -Recipient [email protected] -JournalEmailAddress

[email protected] -Scope Internal

How do you know this worked?

To verify that you have successfully modified a journal rule, do one of the following:
From the EAC, navigate to Compliance management, > Journal rules. Double-click the rule you
modified and verify your changes were saved.
From the Shell, verify that you modified the journal rule successfully by running the following command.
This command will list the properties you modified along with the name of the rule (the example below
verifies the rule modified in the Shell example above):

Get-TransportRule "TraderVault" | Format-List Name,Recipient,JournalEmailAddress,Scope

Enable or disable a journal rule

IMPORTANT
When you disable a journal rule, the journaling agent will stop journaling messages targeted by that rule. While a journal rule
is disabled, any messages that would have normally been journaled by the rule aren't journaled. Make sure that you don't
compromise the regulatory or compliance requirements of your organization by disabling a journaling rule.

Use the EAC to enable or disable a journal rule

1. In the EAC, go to Compliance management > Journal rules.
2. In the list view, in the On column next to the rule's name, select the check box to enable the rule or clear it to
disable the rule.
Use the Shell to enable or disable a journal rule
This example enables the rule Contoso.

Enable-JournalRule "Contoso Journal Rule"

This example disables the rule Contoso.

Disable-JournalRule "Contoso Journal Rule"

How do you know this worked?

To verify that you have successfully enabled or disabled a journal rule, do one of the following:
From the EAC, view the list of journal rules check the status of the check box in the On column.
From the Shell, run the following command to return a list of all journal rules in your organization along,
including their status:

Get-JournalRule | Format-Table Name,Enabled

Remove a journal rule
Use the EAC to remove a journal rule
1. In the EAC, go to Compliance management > Journal rules.
2. In the list view, select the rule you want to remove, and then click Delete .
Use the Shell to remove a journal rule
This example removes the rule Brokerage Journal Rule.

Remove-JournalRule "Brokerage Journal Rule"

How do you know this worked?

To verify that you have successfully removed the journal rule, do one of the following:
From the EAC, verify that the rule you removed is no longer listed on the Journal rules tab.
From the Shell, run the following command to verify that the rule you remove is no longer listed:

Get-JournalRule

Enable or disable per-mailbox database journaling

Cau t i on

Disabling message journaling on a mailbox database may result in your organization being out of compliance with
any applicable messaging retention policies. When you disable message journaling on a mailbox database, journal
receipts are no longer sent for messages sent or received by mailboxes on that mailbox database.
Use the EAC enable or disable per-mailbox database journaling
1. In the EAC, go to Servers > Databases.
2. In the list view, double-click the mailbox database for which you want to enable journaling.
3. Click Maintenance, and then click Browse next to the Journal recipient box to select the journaling
mailbox. Specifying a journal recipient enables journaling for the database.
To disable journaling, remove the journal recipient by clicking Remove X.
Use the Shell to enable or disable per-mailbox database journaling
This example enables journaling for the mailbox database Sales Database and sets Sales Database journal mailbox
as the journal recipient.

Set-MailboxDatabase "Sales Database" -JournalRecipient "Sales Database Journal Mailbox"

This example disables per-mailbox database journaling on the Sales Database mailbox database.

Set-MailboxDatabase "Sales Database" -JournalRecipient $Null

This example disables per-mailbox database journaling on all mailbox databases in the Exchange organization. The
Get-MailboxDatabase cmdlet is used to retrieve all mailbox databases in the Exchange organization, and results
from the cmdlet are piped to the Set-MailboxDatabase cmdlet.
 Get-MailboxDatabase | Set-MailboxDatabase -JournalRecipient $Null

How do you know this worked?

To verify that you have successfully enabled or disabled per-mailbox database journaling, do one of the following:
1. In the EAC, go to Servers > Databases.
2. Double click the database you want to verify, and then select the Maintenance tab.
3. If the correct journaling recipient is listed in the Journal recipient box, you have successfully enabled
journaling for the mailbox database. If there is no journaling recipient listed, journaling is disabled for the
database.
From the Shell, run the following command to return a list of all mailbox databases in your organization, including
the journal recipients associated with them. Journaling is enabled for databases that have a journal recipient listed,
otherwise it's disabled.

Get-MailboxDatabase | Format-Table Name,JournalRecipient

For more information

Disable or Enable Journaling of Voice Mail and Missed Call Notifications
New -JournalRule
Get-JournalRule
Set-JournalRule
Enable-JournalRule
Disable-JournalRule
Remove-JournalRule
Set-MailboxDatabase
 Disable or enable journaling of voice mail and missed
call notifications
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, when you create a journal rule to journal email messages sent to or from
recipients or senders in an Exchange organization, voice mail and missed call notifications generated by the Unified
Messaging (UM ) service are included. Use the procedures in this topic to turn this feature on or off for your entire
organization.
Looking for other management tasks related to journaling? Check out Manage journaling.

What do you need to know before you begin?

Estimated time to complete: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Journaling" entry in the Messaging policy and compliance permissions
topic.
You can only use the Shell to perform this procedure.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to disable or enable journaling of voice mail and missed
call notifications
This example disables journaling of voice mail and missed call notifications by setting the
VoicemailJournalingEnabled parameter to $false .

Set-TransportConfig -VoicemailJournalingEnabled $false

This example enables the journaling of voice mail and missed call notifications by setting the same parameter to
$true .

Set-TransportConfig -VoicemailJournalingEnabled $true

For detailed syntax and parameter information, see Set-TransportConfig.

For More Information

Journaling
Manage journaling
 Transport rules in Exchange 2013
5/30/2019 • 13 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use transport rules to identify and take action on messages that flow through your Exchange 2013
organization. Transport rules are similar to the Inbox rules that are available in Outlook and Outlook Web App.
The main difference is transport rules take action on messages while they're in transit, and not after the
message is delivered to the mailbox. Transport rules contain a richer set of conditions, exceptions, and actions,
which provides you with the flexibility to implement many types of messaging policies.
This article explains the components of transport rules, and how they work.
You can use the Exchange admin center (EAC ) or the Exchange Management Shell to manage transport rules.
For instructions on how to manage transport rules, see Manage transport rules in Exchange 2013.
For each rule, you have the option of enforcing it, testing it, or testing it and notifying the sender. To learn more
about the testing options, see Test a transport rule and Policy Tips.
To implement specific messaging policies by using transport rules, see these topics:
Use transport rules to inspect message attachments in Exchange 2013
Common attachment blocking scenarios for transport rules
Organization-wide disclaimers, signatures, footers, or headers in Exchange 2013
Use transport rules so messages can bypass Clutter
Use transport rules to route email based on a list of words, phrases, or patterns
Common message approval scenarios

Transport rule components

A transport rule is made of conditions, exceptions, actions, and properties:
Conditions: Identify the messages that you want to apply the actions to. Some conditions examine
message header fields (for example, the To, From, or Cc fields). Other conditions examine message
properties (for example, the message subject, body, attachments, message size, or message classification).
Most conditions require you to specify a comparison operator (for example, equals, doesn't equal, or
contains) and a value to match. If there are no conditions or exceptions, the rule is applied to all
messages.
For more information about transport rule conditions in Exchange 2013, see Transport rule conditions
and exceptions (predicates) in Exchange 2013.
Exceptions: Optionally identify the messages that the actions shouldn't apply to. The same message
identifiers that are available in conditions are also available in exceptions. Exceptions override conditions
and prevent the rule actions from being applied to a message, even if the message matches all of the
configured conditions.
Actions: Specify what to do to messages that match the conditions in the rule, and don't match any of
the exceptions. There are many actions available, such as rejecting, deleting, or redirecting messages,
adding additional recipients, adding prefixes in the message subject, or inserting disclaimers in the
 message body.
For more information about transport rule actions in Exchange 2013, see Transport rule actions in
Exchange 2013.
Properties: Specify other rules settings that aren't conditions, exceptions or actions. For example, when
the rule should be applied, whether to enforce or test the rule, and the time period when the rule is active.
For more information, see the Transport rule properties section in this topic.

Multiple conditions, exceptions, and actions

The following table shows how multiple conditions, condition values, exceptions, and actions are handled in a
rule.

COMPONENT LOGIC COMMENTS

Multiple conditions AND A message must match all the

conditions in the rule. If you need
to match one condition or another,
use separate rules for each
condition. For example, if you want
to add the same disclaimer to
messages with attachments and
messages that contain specific text,
create one rule for each condition.
In the EAC, you can easily copy a
rule.

One condition with multiple values OR Some conditions allow you to

specify more than one value. The
message must match any one (not
all) of the specified values. For
example, if an email message has
the subject Stock price
information, and the The subject
includes any of these words
condition is configured to match
the words Contoso or stock, the
condition is satisfied because the
subject contains at least one of the
specified values.

Multiple exceptions OR If a message matches any one of

the exceptions, the actions are not
applied to the message. The
message doesn't have to match all
the exceptions.
 COMPONENT LOGIC COMMENTS

Multiple actions AND Messages that match a rule's

conditions get all the actions that
are specified in the rule. For
example, if the actions Prepend
the subject of the message with
and Add recipients to the Bcc
box are selected, both actions are
applied to the message.
Keep in mind that some actions,
such as the Delete the message
without notifying anyone action,
prevent subsequent rules from
being applied to a message. Other
actions such as Forward the
message do not allow additional
actions.
You can also set an action on a
rule so that when that rule is
applied, subsequent rules are not
applied to the message.

Transport rule properties

The following table describes the rule properties that are available in transport rules.

PROPERTY NAME IN THE EAC PARAMETER NAME IN POWERSHELL DESCRIPTION

Priority Priority Indicates the order that the rules

are applied to messages. The
default priority is based on when
the rule is created (older rules have
a higher priority than newer rules,
and higher priority rules are
processed before lower priority
rules).
You change the rule priority in the
EAC by moving the rule up or
down in the list of rules. In the
PowerShell, you set the priority
number (0 is the highest priority).
For example, if you have one rule
to reject messages that include a
credit card number, and another
one requiring approval, you'll want
the reject rule to happen first, and
stop applying other rules.
For more information, see [Set the
priority of a transport rule]
(manage-transport-rules-
exchange-2013-help.md#set-the-
priority-of-a-transport-rule).
PROPERTY NAME IN THE EAC PARAMETER NAME IN POWERSHELL DESCRIPTION

Mode Mode You can specify whether you want

the rule to start processing
messages immediately, or whether
you want to test rules without
affecting the delivery of the
message (with or without Data
Loss Prevention or DLP Policy
Tips).
Policy Tips present a brief note in
Outlook or Outlook on the web
that provides information about
possible policy violations to the
person that's creating the
message. For more information,
see Policy Tips.
For more information about the
modes, see Test a transport rule.

Activate this rule on the ActivationDate Specifies the date range when the
following date rule is active.
ExpiryDate
Deactivate this rule on the
following date

On check box selected or not New rules: Enabled parameter on You can create a disabled rule, and
selected the New-TransportRule cmdlet. enable it when you're ready to test
it. Or, you can disable a rule
Existing rules: Use the Enable- without deleting it to preserve the
TransportRule or Disable- settings.
TransportRule cmdlets.
The value is displayed in the State
property of the rule.

Defer the message if rule RuleErrorAction You can specify how the message
processing doesn't complete should be handled if the rule
processing can't be completed. By
default, the rule will be ignored,
but you can choose to resubmit
the message for processing.

Match sender address in SenderAddressLocation If the rule uses conditions or

message exceptions that examine the
sender's email address, you can
look for the value in the message
header, the message envelope, or
both.

Stop processing more rules SenderAddressLocation This is an action for the rule, but it
looks like a property in the EAC.
You can choose to stop applying
additional rules to a message after
a rule processes a message.
 PROPERTY NAME IN THE EAC PARAMETER NAME IN POWERSHELL DESCRIPTION

Comments Comments You can enter descriptive

comments about the rule.

How transport rules are applied to messages

UNRESOLVED_TOKENBLOCK_VAL (GENL_TransportRules_HowApplied)

Differences in processing based on message type

There are several types of messages that pass through an organization. The following table shows which
messages types can be processed by transport rules.

TYPE OF MESSAGE CAN A RULE BE APPLIED?

Regular messages Messages that contain a single rich Yes

text format (RTF), HTML, or plain text message body or a
multipart or alternative set of message bodies.

Office 365 Message Encryption Messages encrypted Rules can always access envelope headers and process
by Office 365 Message Encryption in Office 365. For messages based on conditions that inspect those
more information, see Office 365 Message Encryption. headers.
For a rule to inspect or modify the contents of an
encrypted message, you need to verify that transport
decryption is enabled (Mandatory or Optional; the
default is Optional). For more information, see Enable or
disable transport decryption.
You can also create a rule that automatically decrypts
encrypted messages. For more information, see Define
rules to encrypt or decrypt email messages.

S/MIME encrypted messages Rules can only access envelope headers and process
messages based on conditions that inspect those
headers.
Rules with conditions that require inspection of the
message's content, or actions that modify the message's
content can't be processed.

RMS protected messages Messages that had an Rules can always access envelope headers and process
Active Directory Rights Management Services (AD RMS) messages based on conditions that inspect those
or Azure Rights Management (RMS) policy applied. headers.
For a rule to inspect or modify the contents of an RMS
protected message, you need to verify that transport
decryption is enabled (Mandatory or Optional; the
default is Optional). For more information, see Enable or
disable transport decryption.

Clear-signed messages Messages that have been Yes

signed but not encrypted.
 TYPE OF MESSAGE CAN A RULE BE APPLIED?

UM messages Messages that are created or processed Yes

by the Unified Messaging service, such as voice mail, fax,
missed call notifications, and messages created or
forwarded by using Microsoft Outlook Voice Access.

Anonymous messages Messages sent by anonymous Yes

senders.

Read reports Reports that are generated in response Yes

to read receipt requests by senders. Read reports have a
message class of IPM.Note*.MdnRead or
IPM.Note*.MdnNotRead .

Transport rules and group membership

When you define a transport rule using a condition that expands membership of a distribution group, the
resulting list of recipients is cached by the Transport service on the Mailbox server that applies the rule. This is
known as the Expanded Groups Cache and is also used by the Journaling agent for evaluating group
membership for journal rules. By default, the Expanded Groups Cache stores group membership for four hours.
Recipients returned by the recipient filter of a dynamic distribution group are also stored. The Expanded Groups
Cache makes repeated round-trips to Active Directory and the resulting network traffic from resolving group
memberships unnecessary.
In Exchange 2013, this interval and other parameters related to the Expanded Groups Cache are configurable.
You can lower the cache expiration interval, or disable caching altogether, to ensure group memberships are
refreshed more frequently. You must plan for the corresponding increase in load on your Active Directory
domain controllers for distribution group expansion queries. You can also clear the cache on a Mailbox server by
restarting the Microsoft Exchange Transport service on that server. You must do this on each Mailbox server
where you want to clear the cache. When creating, testing, and troubleshooting transport rules that use
conditions based on distribution group membership, you must also consider the impact of Expanded Groups
Cache.

Rule storage and replication

Transport rules that you create and configure on Mailbox servers are stored in Active Directory, and they're read
and applied by the Transport service on all Mailbox servers in the organization. When you create, modify, or
remove a transport rule, the change is replicated between the domain controllers in your organization. This
allows Exchange to provide a consistent set of transport rules across the organization.
Notes:
Replication between domain controllers depends on factors that aren't controlled by Exchange (for
example, the number of Active Directory sites, and the speed of network links). Therefore, you need to
consider replication delays when you implement transport rules in your organization. For more
information about Active Directory replication, see Introduction to Active Directory Replication and
Topology Management Using Windows PowerShell.
Each Mailbox server caches expanded distribution groups to avoid repeated Active Directory queries to
determine a group's membership. By default, entries in the expanded groups cache expire every four
hours. Therefore, changes to the group's membership aren't detected by transport rules until the
expanded groups cache is updated. To force an immediate update of the cache on a Mailbox server,
 restart the Microsoft Exchange Transport service. You need to restart the service on each Mailbox server
where you want to forcibly update the cache.
Transport rules that you create and configure on Edge Transport servers are stored in the local instance of
AD LDS on the server. No automated replication of transport rules occurs on Edge Transport servers. Rules on
the Edge Transport server apply only to messages that flow through the local server. If you need to apply the
same set of transport rules on multiple Edge Transport servers, you can clone the Edge Transport server
configuration, or export and import the transport rules. For more information, see Edge Transport server cloned
configuration and Import or export a transport rule collection .
Whenever the Transport service on a Mailbox server or Edge Transport server detects a modified transport rule,
an event is logged in the Application log in the Event Viewer (Event ID 4002 on Mailbox servers, and Event ID
16028 on Edge Transport servers).

Rule replication and storage in mixed environments

There are two mixed environment scenarios that are common in Exchange 2013:
Hybrid deployments where part of your organization resides in Office 365
In a hybrid environment, there's no replication of rules between your on-premises Exchange organization
and Office 365. Therefore, when you create a rule in Exchange, you need to create a matching rule in
Office 365. Rules you create in Office 365 are stored in the cloud, whereas the rules you create in your
on-premises organization are stored locally in Active Directory. When you manage rules in a hybrid
environment, you need to keep the two sets of rules synchronized by making the change in both places,
or making the change in one environment and then exporting the rules and importing them in the other
environment.

IMPORTANT
Even though there is a substantial overlap between the conditions and actions that are available in Office 365 and
Exchange Server, there are differences. If you plan on creating the same rule in both locations, make sure that all
conditions and actions you plan to use are available. To see the list of available conditions and actions that are
available in Office 365, see the following topics:
Transport rule conditions and exceptions (predicates) in Exchange Online
Transport rule actions in Exchange Online

Coexistence with Exchange 2010 or Exchange 2007

When you coexist with Exchange 2010 or Exchange 2007, all transport rules are stored in Active
Directory and replicated across your organization, regardless of the Exchange Server version you used to
create the rules. However, all transport rules are associated with the Exchange Server server version that
was used to create them, and are stored in a version-specific container in Active Directory. When you first
deploy Exchange 2013 in your organization, any existing rules are imported to Exchange 2013 as part of
the setup process. However, any changes afterwards would need to be made with both versions. For
example, if you change an existing rule in Exchange 2013 (Exchange Management Shell or the EAC ), you
need to make the same change in Exchange 2010 (Exchange Management Shell or the
UNRESOLVED_TOKEN_VAL (exEMC )). Or, you can export the rules from Exchange 2013 and import
them into Exchange 2010.
Exchange 2010 can't process rules that have the Version or RuleVersion value 15.n.n.n. To be sure all
your rules can be processed, only use rules that have the value 14.n.n.n.

For more information

Manage transport rules in Exchange 2013
Transport rule conditions and exceptions (predicates) in Exchange 2013
Transport rule actions in Exchange 2013
Transport agents
 Transport rule conditions and exceptions (predicates) in
Exchange 2013
5/30/2019 • 28 minutes to read • Edit Online

Applies to: Exchange Server 2013

Conditions and exceptions in transport rules identify the messages that the rule is applied to or not applied to. For example, if the rule
adds a disclaimer to messages, you can configure the rule to only apply to messages that contain specific words, messages sent by
specific users, or to all messages except those sent by the members of a specific group. Collectively, the conditions and exceptions in
transport rules are also known as predicates, because for every condition, there's a corresponding exception that uses the exact same
settings and syntax. The only difference is conditions specify messages to include, while exceptions specify messages to exclude.
Most conditions and exceptions have one property that requires one or more values. For example, the The sender is condition requires
the sender of the message. Some conditions have two properties. For example, the A message header includes any of these words
condition requires one property to specify the message header field, and a second property to specify the text to look for in the header
field. Some conditions or exceptions don't have any properties. For example, the Any attachment has executable content condition
simply looks for attachments in messages that have executable content.
For more information about transport rules in Exchange Server 2013, see Transport rules in Exchange 2013.
For more information about conditions and exceptions in transport rules in Exchange Online Protection or Exchange Online, see
Transport rule conditions and exceptions (predicates) in Exchange Online or Transport rule conditions and exceptions (predicates) in
Exchange Online Protection.

Conditions and exceptions for transport rules on Mailbox servers

The tables in the following sections describe the conditions and exceptions that are available in transport rules on Mailbox servers. The
properties types are described in the Property types section.
Senders
Recipients
Message subject or body
Attachments
Any recipients
Message sensitive information types, To and Cc values, size, and character sets
Sender and recipient
Message properties
Message headers
Notes:
After you select a condition or exception in the Exchange admin center (EAC ), the value that's ultimately shown in the Apply this
rule if or Except if field is often different (shorter) than the click path value you selected. Also, when you create new rules based
on a template (a filtered list of scenarios), you can often select a short condition name instead of following the complete click path.
The short names and full click path values are shown in the EAC column in the tables.
If you select [Apply to all messages] in the EAC, you can't specify any other conditions. The equivalent in the Exchange
Management Shell is to create a rule without specifying any condition parameters.
The settings and properties are the same in conditions and exceptions, so the output of the Get-TransportRulePredicate cmdlet
doesn't list exceptions separately. Also, the names of some of the predicates that are returned by this cmdlet are different than the
corresponding parameter names, and a predicate might require multiple parameters.

Senders
For conditions and exceptions that examine the sender's address, you can specify where rule looks for the sender's address.
In the EAC, in the Properties of this rule section, click Match sender address in message. Note that you might need to click More
options to see this setting. In the Exchange Management Shell, the parameter is SenderAddressLocation. The available values are:
Header: Only examine senders in the message headers (for example, the From, Sender, or Reply-To fields). This is the default
value, and is the way transport rules worked before Exchange 2013 Cumulative Update 1 (CU1).
Envelope: Only examine senders from the message envelope (the MAIL FROM value that was used in the SMTP transmission,
which is typically stored in the Return-Path field). Note that message envelope searching is only available for the following
conditions (and the corresponding exceptions):
The sender is (From)
The sender is a member of (FromMemberOf)
The sender address includes (FromAddressContainsWords)
The sender address matches (FromAddressMatchesPatterns)
The sender's domain is (SenderDomainIs)
Header or envelope ( HeaderOrEnvelope ) Examine senders in the message header and the message envelope.

CONDITION AND EXCEPTION

PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The sender is From Addresses Messages that are Exchange 2007 or

sent by the specified later
The sender > is this ExceptIfFrom mailboxes, mail users,
person or mail contacts in the
Exchange organization.

The sender is located FromScope UserScopeFrom Messages that are Exchange 2007 or
sent by either internal later
The sender > is ExceptIfFromScope senders or external
external/internal senders.

The sender is a FromMemberOf Addresses Messages that are Exchange 2007 or

member of sent by a member of later
ExceptIfFromMemberO the specified group.
The sender > is a f
member of this
group

The sender address FromAddressContains Words Messages that contain Exchange 2007 or
includes Words the specified words in later
the sender's email
The sender > ExceptIfFromAddressC address.
address includes any ontainsWords
of these words

The sender address FromAddressMatchesP Patterns Messages where the Exchange 2007 or
matches atterns sender's email address later
contains text patterns
The sender > ExceptIfFromAddressM that match the
address matches any atchesPatterns specified regular
of these text expressions.
patterns
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The sender's SenderADAttributeCo First property: Messages where the Exchange 2010 or
specified properties ntainsWords ADAttribute specified Active later
include any of these Directory attribute of
words ExceptIfSenderADAttri Second property: the sender contains
buteContainsWords Words any of the specified
The sender > has words.
specific properties
including any of Note that the Country
these words attribute requires the
two-letter country
code value (for
example, DE for
Germany).

The sender's SenderADAttributeMat First property: Messages where the Exchange 2010 or
specified properties chesPatterns ADAttribute specified Active later
match these text Directory attribute of
patterns ExceptIfSenderADAttri Second property: the sender contains
buteMatchesPatterns Patterns text patterns that
The sender > has match the specified
specific properties regular expressions.
matching these text
patterns

The sender has HasSenderOverride n/a Messages where the Exchange 2013 or
overridden the sender has chosen to later
Policy Tip ExceptIfHasSenderOve override a data loss
rride prevention (DLP)
The sender > has policy. For more
overridden the information about DLP
Policy Tip policies, see Data loss
prevention.

Sender's IP address SenderIPRanges IPAddressRanges Messages where the Exchange 2013 or

is in the range sender's IP address later
ExceptIfSenderIPRange matches the specified
The sender > IP s IP address, or falls
address is in any of within the specified IP
these ranges or address range.
exactly matches

The sender's domain SenderDomainIs DomainName Messages where the Exchange 2013 or
is domain of the sender's later
ExceptIfSenderDomain email address matches
The sender > Is the specified value.
domain is
If you need to find
sender domains that
contain the specified
domain (for example,
any subdomain of a
domain), use The
sender address
matches
(FromAddressMatches
Patterns) condition
and specify the
domain by using the
syntax:
'@domain\.com$' .

Recipients
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The recipient is SentTo Addresses Messages where one Exchange 2007 or

of the recipients is the later
The recipient > is ExceptIfSentTo specified mailbox, mail
this person user, or mail contact in
the Exchange
organization. The
recipients can be in the
To, Cc, or Bcc fields of
the message.
Note: You can't specify
distribution groups or
mail-enabled security
groups. If you need to
take action on
messages that are sent
to a group, use the To
box contains
(AnyOfToHeader)
condition instead.

The recipient is SentToScope UserScopeTo Messages that are Exchange 2007 or

located sent to internal later
ExceptIfSentToScope recipients, external
The recipient > is recipients, external
external/external recipients in partner
organizations, or
external recipients in
non-partner
organizations.

The recipient is a SentToMemberOf Addresses Messages that contain Exchange 2007 or

member of recipients who are later
ExceptIfSentToMember members of the
The recipient > is a Of specified group. The
member of this group can be in the
group To, Cc, or Bcc fields of
the message.

The recipient RecipientAddressCont Words Messages that contain Exchange 2010 or

address includes ainsWords the specified words in later
the recipient's email
The recipient > ExceptIfRecipientAddre address.
address includes any ssContainsWords
of these words Note: This condition
doesn't consider
messages that are sent
to recipient proxy
addresses. It only
matches messages
that are sent to the
recipient's primary
email address.
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The recipient RecipientAddressMatc Patterns Messages where a Exchange 2010 or

address matches hesPatterns recipient's email later
address contains text
The recipient > ExceptIfRecipientAddre patterns that match
address matches any ssMatchesPatterns the specified regular
of these text expressions.
patterns
Note: This condition
doesn't consider
messages that are sent
to recipient proxy
addresses. It only
matches messages
that are sent to the
recipient's primary
email address.

The recipient's RecipientADAttributeC First property: Messages where the Exchange 2010 or
specified properties ontainsWords ADAttribute specified Active later
include any of these Directory attribute of a
words ExceptIfRecipientADAt Second property: recipient contains any
tributeContainsWords Words of the specified words.
The recipient > has
specific properties Note that the Country
including any of attribute requires the
these words two-letter country
code value (for
example, DE for
Germany).

The recipient's RecipientADAttribute First property: Messages where the Exchange 2010 or
specified properties MatchesPatterns ADAttribute specified Active later
match these text Directory attribute of a
patterns ExceptIfRecipientADAt Second property: recipient contains text
tributeMatchesPattern Patterns patterns that match
The recipient > has s the specified regular
specific properties expressions.
matching these text
patterns

A recipient's domain RecipientDomainIs DomainName Messages where the Exchange 2013 or

is domain of a recipient's later
ExceptIfRecipientDom email address matches
The recipient > ainIs the specified value.
domain is
If you need to find
recipient domains that
contain the specified
domain (for example,
any subdomain of a
domain), use The
recipient address
matches
(RecipientAddressMatc
hesPatterns) condition,
and specify the
domain by using the
syntax
'@domain\.com$' .

Message subject or body

 NOTE
The search for words or text patterns in the subject or other header fields in the message occurs after the message has been decoded from the MIME
content transfer encoding method that was used to transmit the binary message between SMTP servers in ASCII text. You can't use conditions or
exceptions to search for the raw (typically, Base64) encoded values of the subject or other header fields in messages.

CONDITION AND EXCEPTION

PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The subject or body SubjectOrBodyContain Words Messages that have Exchange 2007 or
includes sWords the specified words in later
the Subject field or
The subject or body ExceptIfSubjectOrBody message body.
> subject or body ContainsWords
includes any of these
words

The subject or body SubjectOrBodyMatche Patterns Messages where the Exchange 2007 or
matches sPatterns Subject field or later
message body contain
The subject or body ExceptIfSubjectOrBody text patterns that
> subject or body MatchesPatterns match the specified
matches these text regular expressions.
patterns

The subject includes SubjectContainsWords Words Messages that have Exchange 2007 or
the specified words in later
The subject or body ExceptIfSubjectContain the Subject field.
> subject includes sWords
any of these words

The subject matches SubjectMatchesPattern Patterns Messages where the Exchange 2007 or
s Subject field contains later
The subject or body text patterns that
> subject matches ExceptIfSubjectMatche match the specified
these text patterns sPatterns regular expressions.

Attachments
For more information about how transport rules inspect message attachments, see Use transport rules to inspect message attachments
in Exchange 2013.

CONDITION AND EXCEPTION

PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

Any attachment's AttachmentContains Words Messages where an Exchange 2010 or

content includes Words attachment contains later
the specified words.
Any attachment > ExceptIfAttachmentCo
content includes any ntainsWords
of these words

Any attachments AttachmentMatchesPa Patterns Messages where an Exchange 2010 or

content matches tterns attachment contains later
text patterns that
Any attachment > ExceptIfAttachmentMa match the specified
content matches tchesPatterns regular expressions.
these text patterns
Note: Only the first
150 kilobytes (KB) of
the attachments are
scanned.
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

Any attachment's AttachmentIsUnsuppo n/a Messages where an Exchange 2010 or

content can't be rted attachment isn't later
inspected natively recognized by
ExceptIfAttachmentIsU Exchange, and the
Any attachment > nsupported required IFilter isn't
content can't be installed on the
inspected Mailbox server. For
more information, see
Register Filter Pack
IFilters with Exchange
2013.

Any attachment's file AttachmentNameMatc Patterns Messages where an Exchange 2010 or

name matches hesPatterns attachment's file name later
contains text patterns
Any attachment > ExceptIfAttachmentNa that match the
file name matches meMatchesPatterns specified regular
these text patterns expressions.

Any attachment's file AttachmentExtension Words Messages where an Exchange 2013 or

extension matches MatchesWords attachment's file later
extension matches any
Any attachment > ExceptIfAttachmentExt of the specified words.
file extension ensionMatchesWords
includes these words

Any attachment is AttachmentSizeOver Size Messages where any Exchange 2007 or

greater than or attachment is greater later
equal to ExceptIfAttachmentSiz than or equal to the
eOver specified value.
Any attachment >
size is greater than In the EAC, you can
or equal to only specify the size in
kilobytes (KB).

The message didn't AttachmentProcessing n/a Messages where the Exchange 2013 or
complete scanning LimitExceeded rules engine couldn't later
complete the scanning
Any attachment > ExceptIfAttachmentPro of the attachments.
didn't complete cessingLimitExceeded You can use this
scanning condition to create
rules that work
together to identify
and process messages
where the content
couldn't be fully
scanned.

Any attachment has AttachmentHasExecut n/a Messages where an Exchange 2013 or

executable content ableContent attachment is an later
executable file. The
Any attachment > ExceptIfAttachmentHa system inspects the
has executable sExecutableContent file's properties rather
content than relying on the
file's extension.

Any attachment is AttachmentIsPasswor n/a Messages where an Exchange 2013 or

password protected dProtected attachment is later
password protected
Any attachment > is ExceptIfAttachmentIsP (and therefore can't be
password protected asswordProtected scanned). Password
detection only works
for Office documents
and .zip files.
Any recipients
The conditions and exceptions in this section provide a unique capability that affects all recipients when the message contains at least
one of the specified recipients. For example, let's say you have a rule that rejects messages. If you use a recipient condition from the
Recipients section, the message is only rejected for those specified recipients. For example, if the rule finds the specified recipient in a
message, but the message contains five other recipients. The message is rejected for that one recipient, and is delivered to the five other
recipients.
If you add a recipient condition from this section, that same message is rejected for the detected recipient and the five other recipients.
Conversely, a recipient exception from this section prevents the rule action from being applied to all recipients of the message, not just
for the detected recipients.
Note: This condition doesn't consider messages that are sent to recipient proxy addresses. It only matches messages that are sent to the
recipient's primary email address.

CONDITION AND EXCEPTION

PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

Any recipient AnyOfRecipientAddres Words Messages that contain Exchange 2013 or

address includes sContainsWords the specified words in later
the To, Cc, or Bcc
Any recipient > ExceptIfAnyOfRecipien fields of the message.
address includes any tAddressContainsWor
of these words ds

Any recipient AnyOfRecipientAddres Patterns Messages where the Exchange 2013 or

address matches sMatchesPatterns To, Cc, or Bcc fields later
contain text patterns
Any recipient > ExceptIfAnyOfRecipien that match the
address matches any tAddressMatchesPatte specified regular
of these text rns expressions.
patterns

Message sensitive information types, To and Cc values, size, and character sets
The conditions in this section that look for values in the To and Cc fields behave like the conditions in the Any recipients section (all
recipients of the message are affected by the rule, not just the detected recipients).
Note: This condition doesn't consider messages that are sent to recipient proxy addresses. It only matches messages that are sent to the
recipient's primary email address.

CONDITION AND EXCEPTION

PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The message MessageContainsData SensitiveInformationTypes Messages that contain Exchange 2013 or

contains sensitive Classifications sensitive information later
information as defined by data loss
ExceptIfMessageConta prevention (DLP)
The message > insDataClassifications policies.
contains any of these
types of sensitive This condition is
information required for rules that
use the Notify the
sender with a Policy
Tip (NotifySender)
action.

The To box contains AnyOfToHeader Addresses Messages where the Exchange 2007 or
To field includes any of later
The message > To ExceptIfAnyOfToHeade the specified recipients.
box contains this r
person
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The To box contains AnyOfToHeaderMemb Addresses Messages where the Exchange 2007 or
a member of erOf To field contains a later
recipient who is a
The message > To ExceptIfAnyOfToHeade member of the
box contains a rMemberOf specified group.
member of this
group

The Cc box contains AnyOfCcHeader Addresses Messages where the Exchange 2007 or
Cc field includes any of later
The message > Cc ExceptIfAnyOfCcHeade the specified recipients.
box contains this r
person

The Cc box contains AnyOfCcHeaderMemb Addresses Messages where the Exchange 2007 or
a member of erOf Cc field contains a later
recipient who is a
The message > ExceptIfAnyOfCcHeade member of the
contains a member rMemberOf specified group.
of this group

The To or Cc box AnyOfToCcHeader Addresses Messages where the Exchange 2007 or

contains To or Cc fields contain later
ExceptIfAnyOfToCcHea any of the specified
The message > To or der recipients.
Cc box contains this
person

The To or Cc box AnyOfToCcHeaderMe Addresses Messages where the Exchange 2007 or

contains a member mberOf To or Cc fields contain later
of a recipient who is a
ExceptIfAnyOfToCcHea member of the
The message > To or derMemberOf specified group.
Cc box contains a
member of this
group

The message size is MessageSizeOver Size Messages where the Exchange 2013 or
greater than or total size (message later
equal to ExceptIfMessageSizeO plus attachments) is
ver greater than or equal
The message > size to the specified value.
is greater than or
equal to In the EAC, you can
only specify the size in
kilobytes (KB).
Note: Message size
limits on mailboxes are
evaluated before
transport rules. A
message that's too
large for a mailbox will
be rejected before a
rule with this condition
is able to act on the
message.

The message ContentCharacterSetC CharacterSets Messages that have Exchange 2013 or

character set name ontainsWords any of the specified later
includes any of these character set names.
words ExceptIfContentCharac
terSetContainsWords
The message >
character set name
includes any of these
words
Sender and recipient
CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The sender is one of SenderManagementRe ManagementRelationship Messages where the Exchange 2010 or
the recipient's lationship either sender is the later
manager of a recipient,
The sender and the ExceptIfSenderManage or the sender is
recipient > the mentRelationship managed by a
sender's relationship recipient.
to a recipient is

The message is BetweenMemberOf1 Addresses Messages that are Exchange 2007 or

between members and sent between later
of these groups BetweenMemberOf2 members of the
specified groups.
The sender and the ExceptIfBetweenMemb
recipient > the erOf1 and
message is between ExceptIfBetweenMemb
members of these erOf2
groups

The manager of the ManagerForEvaluated First property: Messages where either Exchange 2010 or
sender or recipient is User and EvaluatedUser a specified user is the later
ManagerAddress manager of the sender,
The sender and the Second property: or a specified user is
recipient > the ExceptIfManagerForEv Addresses the manager of a
manager of the aluatedUser and recipient.
sender or recipient is ExceptIfManagerAddre
this person ss

The sender's and any ADAttributeComparis First property: Messages where the Exchange 2010 or
recipient's property onAttribute and ADAttribute specified Active later
compares as ADComparisonOperat Directory attribute for
or Second property: the sender and
The sender and the Evaluation recipient either match
recipient > the ExceptIfADAttributeCo or don't match.
sender and recipient mparisonAttribute
property compares and
as ExceptIfADCompariso
nOperator

Message properties
CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The message type is MessageTypeMatches MessageType Messages of the Exchange 2010 or

specified type. later
The message ExceptIfMessageTypeM
properties > include atches
the message type NOTE
When Outlook or
Outlook Web App
is configured to
forward a
message, the
ForwardingSmtpA
ddress property is
added to the
message. The
message type isn't
changed to
AutoForward .
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

The message is HasClassification MessageClassification Messages that have Exchange 2007 or

classified as the specified message later
ExceptIfHasClassificati classification. This is a
The message on custom message
properties > include classification that you
this classification can create in your
organization by using
the New-
MessageClassificatio
n cmdlet.

The message isn't HasNoClassification n/a Messages that don't Exchange 2010 or
marked with any have a message later
classifications ExceptIfHasNoClassific classification.
ation
The message
properties > don't
include any
classification

The message has an SCLOver SCLValue Messages that are Exchange 2007 or
SCL greater than or assigned a spam later
equal to ExceptIfSCLOver confidence level (SCL)
that's greater than or
The message equal to the specified
properties > include value.
an SCL greater than
or equal to

The message WithImportance Importance Messages that are Exchange 2007 or

importance is set to marked with the later
ExceptIfWithImportanc specified Importance
The message e level.
properties > include
the importance level

Message headers
NOTE
The search for words or text patterns in the subject or other header fields in the message occurs after the message has been decoded from the MIME
content transfer encoding method that was used to transmit the binary message between SMTP servers in ASCII text. You can't use conditions or
exceptions to search for the raw (typically, Base64) encoded values of the subject or other header fields in messages.

CONDITION AND EXCEPTION

PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

A message header HeaderContainsMessa First property: Messages that contain Exchange 2007 or
includes geHeader and MessageHeaderField the specified header later
HeaderContainsWords field, and the value of
A message header > Second property: that header field
includes any of these ExceptIfHeaderContai Words contains the specified
words nsMessageHeader and words.
ExceptIfHeaderContai
nsWords The name of the
header field and the
value of the header
field are always used
together.
 CONDITION AND EXCEPTION
PARAMETERS IN THE
CONDITION OR EXCEPTION EXCHANGE MANAGEMENT
IN THE EAC SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

A message header HeaderMatchesMessa First property: Messages that contain Exchange 2007 or
matches geHeader and MessageHeaderField the specified header later
HeaderMatchesPatter field, and the value of
A message header > ns Second property: that header field
matches these text Patterns contains the specified
patterns ExceptIfHeaderMatche regular expressions.
sMessageHeader and
ExceptIfHeaderMatche The name of the
sPatterns header field and the
value of the header
field are always used
together.

Conditions and exceptions for transport rules on Edge Transport servers

The conditions and exceptions that are available in transport rules on Edge Transport servers are a small subset of what's available on
Mailbox servers. There's no EAC on Edge Transport servers, so you can only manage transport rules in the Exchange Management Shell
on the local Edge Transport server. The conditions and exceptions are described in the following table. The properties types are
described in the Property types section.

CONDITION AND EXCEPTION

PARAMETERS IN THE EXCHANGE
MANAGEMENT SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

AnyOfRecipientAddressContai Words Messages that contain the Exchange 2013 or later

nsWords specified words in the To, Cc,
or Bcc fields.
ExceptIfAnyOfRecipientAddres
sContainsWords When a message contains the
specified recipient, the rule
action is applied (or not
applied) to all recipients of the
message. For example, the
message is rejected for all
recipients of the message, not
just for the specified recipient.

AnyOfRecipientAddressMatche Patterns Messages where the To, Cc, or Exchange 2013 or later
sPatterns Bcc fields contain text patterns
that match the specified
ExceptIfAnyOfRecipientAddres regular expressions.
sMatchesPatterns
When a message contains the
specified recipient, the rule
action is applied (or not
applied) to all recipients of the
message. For example, the
message is rejected for all
recipients of the message, not
just for the specified recipient.

AttachmentSizeOver Size Messages with attachments Exchange 2007 or later

where any attachment is
ExceptIfAttachmentSizeOver greater than or equal to the
specified value.

FromAddressContainsWords Words Messages that contain the Exchange 2007 or later

specified words in the sender's
ExceptIfFromAddressContains email address.
Words
 CONDITION AND EXCEPTION
PARAMETERS IN THE EXCHANGE
MANAGEMENT SHELL PROPERTY TYPE DESCRIPTION AVAILABLE IN

FromAddressMatchesPatterns Patterns Messages where the sender's Exchange 2007 or later

email address contains text
ExceptIfFromAddressMatchesP patterns that match the
atterns specified regular expressions.

FromScope UserScopeFrom Messages that are sent by Exchange 2007 or later

either internal senders or
ExceptIfFromScope external senders.

HeaderContainsMessageHead First property: Messages that contain the Exchange 2007 or later
er and HeaderContainsWords MessageHeaderField specified header field, and the
value of that header field
ExceptIfHeaderContainsMessa Second property: Words contains the specified words.
geHeader and
ExceptIfHeaderContainsWords The name of the header field
and the value of the header
field are always used together.

HeaderMatchesMessageHeade First property: Messages that contain the Exchange 2007 or later
r and HeaderMatchesPatterns MessageHeaderField specified header field, and the
value of that header field
ExceptIfHeaderMatchesMessag Second property: Patterns contains the specified regular
eHeader and expressions.
ExceptIfHeaderMatchesPattern
s The name of the header field
and the value of the header
field are always used together.

MessageSizeOver Size Messages where the total size Exchange 2013 or later
(message plus attachments) is
ExceptIfMessageSizeOver greater than or equal to the
specified value.

SCLOver SCLValue Messages that are assigned an Exchange 2007 or later

SCL that's greater than or
ExceptIfSCLOver equal to the specified value.

SubjectContainsWords Words Messages that contain the Exchange 2007 or later

specified words in the Subject
ExceptIfSubjectContainsWords field.

SubjectMatchesPatterns Patterns Messages where the Subject Exchange 2007 or later

field contains text patterns
ExceptIfSubjectMatchesPattern that match the specified
s regular expressions.

SubjectOrBodyContainsWords Words Messages that contain the Exchange 2007 or later

specified words in the Subject
ExceptIfSubjectOrBodyContain field or message body.
sWords

SubjectOrBodyMatchesPattern Patterns Messages where the Subject Exchange 2007 or later

s field or message body contain
text patterns that match the
ExceptIfSubjectOrBodyMatches specified regular expressions.
Patterns

Property types
The property types that are used in conditions and exceptions are described in the following table.
NOTE
If the property is a string, trailing spaces are not allowed.

PROPERTY TYPE VALID VALUES DESCRIPTION

ADAttribute Select from a predefined list of Active UNRESOLVED_TOKENBLOCK_VAL(PD_Trans

Directory attributes port_Rules_ADAttributes_Snippet)
In the EAC, to specify multiple words or text
patterns for the same attribute, separate
the values with commas. For example, the
value San Francisco,Palo Alto for the City
attribute looks for "City equals San
Francisco" or City equals Palo Alto".
In the Exchange Management Shell, use the
syntax
"AttributeName1:Value1,Value 2 with
spaces,Value3...","AttributeName2:Word4,Value
5 with spaces,Value6..."
, where Value is the word or text pattern
that you want to match.
For example,
"City:San Francisco,Palo Alto" or
"City:San Francisco,Palo Alto" ,
"Department:Sales,Finance" .
When you specify multiple attributes, or
multiple values for the same attribute, the
or operator is used. Don't use values with
leading or trailing spaces.
Note that the Country attribute requires
the two-letter ISO 3166-1 country code
value (for example, DE for Germany). To
search for values, see
https://go.microsoft.com/fwlink/p/?
LinkId=331680.

Addresses Exchange recipients Depending on the nature of the condition

or exception, you might be able to specify
any mail-enabled object in the organization
(for example, recipient-related conditions),
or you might be limited to a specific object
type (for example, groups for group
membership conditions). And, the condition
or exception might require one value, or
allow multiple values.
In the Exchange Management Shell,
separate multiple values by commas.
Note: This condition doesn't consider
messages that are sent to recipient proxy
addresses. It only matches messages that
are sent to the recipient's primary email
address.
PROPERTY TYPE VALID VALUES DESCRIPTION

CharacterSets Array of character set names One or more content character sets that
exist in a message. For example:
Arabic/iso-8859-6

Chinese/big5

Chinese/euc-cn

Chinese/euc-tw

Chinese/gb2312

Chinese/iso-2022-cn

Cyrillic/iso-8859-5

Cyrillic/koi8-r

Cyrillic/windows-1251

Greek/iso-8859-7

Hebrew/iso-8859-8

Japanese/euc-jp

Japanese/iso-022-jp

Japanese/shift-jis

Korean/euc-kr

Korean/johab

Korean/ks_c_5601-1987

Turkish/windows-1254

Turkish/iso-8859-9

Vietnamese/tcvn

DomainName Array of SMTP domains For example, contoso.com or

eu.contoso.com .
In the Exchange Management Shell, you can
specify multiple domains separated by
commas.

EvaluatedUser Single value of Sender or Recipient Specifies whether the rule is looking for the
manager of the sender or the manager of
the recipient.

Evaluation Single value of Equal or Not equal ( When comparing the Active Directory
NotEqual ) attribute of the sender and recipients, this
specifies whether the values should match,
or not match.

Importance Single value of Low, Normal, or High The Importance level that was assigned to
the message by the sender in Outlook or
Outlook Web App.
PROPERTY TYPE VALID VALUES DESCRIPTION

IPAddressRanges Array of IP addresses or address ranges You enter the IPv4 addresses using the
following syntax:
Single IP address For example,
192.168.1.1 .

IP address range For example,

192.168.0.1-192.168.0.254 .

Classless InterDomain Routing

(CIDR) IP address range For
example, 192.168.0.1/25 .
In the Exchange Management Shell, you can
specify multiple IP addresses or ranges
separated by commas.

ManagementRelationship Single value of Manager or Direct report( Specifies the relationship between the
DirectReport ) sender and any of the recipients. The rule
checks the Manager attribute in Active
Directory to see if the sender is the
manager of a recipient, or if the sender is
managed by a recipient.

MessageClassification Single message classification In the EAC, you select from the list of
message classifications that you've created.
In the Exchange Management Shell, you use
the Get-MessageClassification cmdlet to
identify the message classification. For
example, use the following command to
search for messages with the
Company Internal classification and
prepend the message subject with the value
CompanyInternal .

New-TransportRule "Rule Name" -

HasClassification @(Get-
MessageClassification "Company
Internal").Identity -PrependSubject
"CompanyInternal"

MessageHeaderField Single string Specifies the name of the header field. The
name of the header field is always paired
with the value in the header field (word or
text pattern match).
The message header is a collection of
required and optional header fields in the
message. Examples of header fields are To,
From, Received, and Content-Type.
Official header fields are defined in RFC
5322. Unofficial header fields start with X-
and are known as X-headers.
PROPERTY TYPE VALID VALUES DESCRIPTION

MessageType Single message type value Specifies one of the following message
types:
Automatic reply ( OOF )
Auto-forward ( AutoForward )
Encrypted
Calendaring
Permission controlled (
PermissionControlled )

Voicemail
Signed
Approval request (
ApprovalRequest )

Read receipt ( ReadReceipt )

NOTE
When Outlook or Outlook Web App is
configured to forward a message, the
ForwardingSmtpAddress property is
added to the message. The message
type isn't changed to AutoForward .

Patterns Array of regular expressions Specifies one or more regular expressions

that are used to identify text patterns in
values. For more information, see Regular
Expression Syntax.
In the Exchange Management Shell, you
specify multiple regular expressions
separated by commas, and you enclose
each regular expression in quotation marks
(").

SCLValue One of the following values: Specifies the spam confidence level (SCL)
that's assigned to a message. A higher SCL
Bypass spam filtering ( -1 ) value indicates that a message is more likely
Integers 0 through 9 to be spam.

SensitiveInformationTypes Array of sensitive information types Specifies one or more sensitive information
types that are defined in your organization.
For a list of built-in sensitive information
types, see What the sensitive information
types in Exchange look for.
In the Exchange Management Shell, use the
syntax
@{<SensitiveInformationType1>},@{<SensitiveInformationType
. For example, to look for content that
contains at least two credit card numbers,
and at least one ABA routing number, use
the value
@{Name="Credit Card Number";
minCount="2"},@{Name="ABA Routing
Number"; minCount="1"}
.
PROPERTY TYPE VALID VALUES DESCRIPTION

Size Single size value Specifies the size of an attachment or the

whole message.
In the EAC, you can only specify the size in
kilobytes (KB).
In the Exchange Management Shell, when
you enter a value, qualify the value with one
of the following units:
B (bytes)
KB (kilobytes)
MB (megabytes)
GB (gigabytes)
For example, 20MB

Unqualified values are typically treated as

bytes, but small values may be rounded up
to the nearest kilobyte.

UserScopeFrom Single value of Inside the organization ( A sender is considered to be inside the
InOrganization ) or Outside the organization if either of the following
organization ( NotInOrganization ) conditions is true:
The sender is a mailbox, mail user,
group, or mail-enabled public folder
that exists in the organization's
Active Directory.
The sender's email address is in an
accepted domain that's configured
as an authoritative domain or an
internal relay domain, and the
message was sent or received over
an authenticated connection. For
more information about accepted
domains, see Accepted domains.
A sender is considered to be outside the
organization if either of the following
conditions is true:
The sender's email address isn't in an
accepted domain.
The sender's email address is in an
accepted domain that's configured
as an external relay domain.

NOTE
To determine whether mail contacts are
considered to be inside or outside the
organization, the sender's address is
compared with the organization's
accepted domains.
 PROPERTY TYPE VALID VALUES DESCRIPTION

UserScopeTo One of the following values: A recipient is considered to be inside the

organization if either of the following
Inside the organization ( conditions is true:
InOrganization )
The recipient is a mailbox, mail user,
Outside the organization ( group, or mail-enabled public folder
NotInOrganization ) that exists in the organization's
In an external partner Active Directory.
organization ( ExternalPartner ) The recipient's email address is in an
accepted domain that's configured
In an external non-partner
as an authoritative domain or an
organization (
internal relay domain, and the
ExternalNonPartner )
message was sent or received over
an authenticated connection.
A recipient is considered to be outside the
organization if either of the following
conditions is true:
The recipient's email address isn't in
an accepted domain.
The recipient's email address is in an
accepted domain that's configured
as an external relay domain.
External partner organizations are external
domains where you've configured Domain
Security (mutual TLS authentication) to send
mail.
External non-partner organizations are all
other external domains that aren't
considered partner domains.

Words Array of strings Specifies one or more words to look for. The
words aren't case-sensitive, and can be
surrounded by spaces and punctuation
marks. Wildcards and partial matches aren't
supported.
For example, "contoso" matches " Contoso.".
However, if the text is surrounded by other
characters, it isn't considered a match. For
example, "contoso" doesn't match the
following values:
Acontoso
Contosoa
Acontosob
The asterisk (*) is treated as a literal
character, and isn't used as a wildcard
character.

For more information

Transport rules in Exchange 2013
Transport rule actions in Exchange 2013
Transport rule procedures in Exchange 2013
Transport rule conditions and exceptions (predicates) in Exchange Online for Exchange Online
Transport rule conditions and exceptions (predicates) in Exchange Online Protection for Exchange Online Protection
 Transport rule actions in Exchange 2013
5/30/2019 • 19 minutes to read • Edit Online

Applies to: Exchange Server 2013

Actions in transport rules specify what you want to do to messages that match conditions of the rule. For example,
you can create a rule that forwards message from specific senders to a moderator, or adds a disclaimer or
personalized signature to all outbound messages.
Actions typically require additional properties. For example, when the rule redirects a message, you need to
specify where to redirect the message. Some actions have multiple properties that are available or required. For
example, when the rule adds a header field to the message header, you need to specify both the name and value of
the header. When the rule adds a disclaimer to messages, you need to specify the disclaimer text, but you can also
specify where to insert the text, or what to do if the disclaimer can't be added to the message. Typically, you can
configure multiple actions in a rule, but some actions are exclusive. For example, one rule can't reject and redirect
the same message.
For more information about transport rules in Exchange Server 2013, see Transport rules in Exchange 2013.
For more information about conditions and exceptions in transport rules, see Transport rule conditions and
exceptions (predicates) in Exchange 2013.
For more information about actions in transport rules in Exchange Online or Exchange Online Protection, see
Transport rule actions in Exchange Online or Transport rule actions in Exchange Online Protection.

Actions for transport rules on Mailbox servers

The actions that are available in transport rules on Mailbox servers are described in the following table. Valid
values for each property are described in the Property values section.
Notes:
After you select an action in the Exchange admin center (EAC ), the value that's ultimately shown in the Do
the following field is often different from the click path you selected. Also, when you create new rules, you
can sometimes (depending on the selections you make) select a short action name from a template (a
filtered list of actions) instead of following the complete click path. The short names and full click path
values are shown in the EAC column in the table.
The names of some of the actions that are returned by the Get-TransportRuleAction cmdlet are different
than the corresponding parameter names, and multiple parameters might be required for an action.

ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Forward the ModerateMessag Addresses Forwards the Exchange 2010

message for eByUser message to the or later
approval to specified
these people moderators as an
attachment
Forward the wrapped in an
message for approval request.
approval > to For more
these people information, see
Common
message approval
scenarios. You
can't use a
distribution
group as a
moderator.

Forward the ModerateMessag n/a Forwards the Exchange 2010

message for eByManager message to the or later
approval to the sender's manager
sender's for approval.
manager
This action only
Forward the works if the
message for sender's
approval > to Manager
the sender's attribute is
manager defined in Active
Directory.
Otherwise, the
message is
delivered to the
recipients without
moderation.

Redirect the RedirectMessageT Addresses Redirects the Exchange 2007

message to o message to the or later
these recipients specified
recipients. The
Redirect the message isn't
message to > delivered to the
these recipients original recipients,
and no
notification is
sent to the
sender or the
original recipients.
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Reject the RejectMessageRe String Returns the Exchange 2007

message with asonText message to the or later
the explanation sender in a non-
delivery report
Block the (also known as an
message > NDR or bounce
reject the message) with
message and the specified text
include an as the rejection
explanation reason. The
recipient doesn't
receive the
original message
or notification.
The default
enhanced status
code that's used
is 5.7.1 .
When you create
or modify the rule
in the Exchange
Management
Shell, you can
specify the DSN
code by using the
RejectMessageEn
hancedStatusCod
e parameter.
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Reject the RejectMessageEn DSNEnhancedStatusCode Returns the Exchange 2007

message with hancedStatusCod message to the or later
the enhanced e sender in an NDR
status code with the specified
enhanced
Block the delivery status
message > notification (DSN)
reject the code. The
message with recipient doesn't
the enhanced receive the
status code of original message
or notification.
Valid DSN codes
are 5.7.1 or
5.7.900
through
5.7.999 .
The default
reason text that's
used is
Delivery not
authorized,
message
refused
.
When you create
or modify the rule
in the Exchange
Management
Shell, you can
specify the
rejection reason
text by using the
RejectMessageRe
asonText
parameter.

Delete the DeleteMessage n/a Silently drops the Exchange 2007

message message without or later
without sending a
notifying notification to the
anyone recipient or the
sender.
Block the
message >
delete the
message
without
notifying
anyone
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Add recipients BlindCopyTo Addresses Adds one or Exchange 2007

to the Bcc box more recipients or later
to the Bcc field of
Add recipients the message. The
> to the Bcc box original recipients
aren't notified,
and they can't see
the additional
addresses.

Add recipients AddToRecipients Addresses Adds one or Exchange 2007

to the To box more recipients or later
to the To field of
Add recipients the message. The
> to the To box original recipients
can see the
additional
addresses.

Add recipients CopyTo Addresses Adds one or Exchange 2007

to the Cc box more recipients or later
to the Cc field of
Add recipients the message. The
> to the Cc box original recipients
can see the
additional
address.

Add the AddManagerAsRe AddedManagerAction Adds the sender's Exchange 2010

sender's cipientType manager to the or later
manager as a message as the
recipient specified recipient
type (To, Cc,
Add recipients Bcc), or redirects
> add the the message to
sender's the sender's
manager as a manager without
recipient notifying the
sender or the
recipient.
This action only
works if the
sender's
Manager
attribute is
defined in Active
Directory.
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Append the ApplyHtmlDisclai First property: Applies the Exchange 2007

disclaimer merText DisclaimerText specified HTML or later
disclaimer to the
Apply a ApplyHtmlDisclai Second property: end of the
disclaimer to merFallbackActio DisclaimerFallbackAction
message.
the message > n
append a Third property When you create
disclaimer ApplyHtmlDisclai (Exchange or modify the rule
merTextLocation Management in the Exchange
Shell only): Management
DisclaimerTextLocation Shell, use the
ApplyHtmlDisclai
merTextLocation
parameter with
the value
Append .

Prepend the ApplyHtmlDisclai First property: Applies the Exchange 2007

disclaimer merText DisclaimerText specified HTML or later
disclaimer to the
Apply a ApplyHtmlDisclai Second property: beginning of the
disclaimer to merFallbackActio DisclaimerFallbackAction
message.
the message > n
prepend a Third property When you create
disclaimer ApplyHtmlDisclai (Exchange or modify the rule
merTextLocation Management in the Exchange
Shell only): Management
DisclaimerTextLocation Shell, use the
ApplyHtmlDisclai
merTextLocation
parameter with
the value
Prepend .

Remove this RemoveHeader MessageHeaderField Removes the Exchange 2007

header specified header or later
field from the
Modify the message header.
message
properties >
remove a
message header

Set the message SetHeaderName First property: Adds or modifies Exchange 2007
header to this MessageHeaderField the specified or later
value SetHeaderValue header field in the
Second property: message header,
Modify the String and sets the
message header field to
properties > set the specified
a message value.
header
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Apply a ApplyClassificati MessageClassification Applies the Exchange 2007

message on specified message or later
classification classification to
the message.
Modify the
message
properties >
apply a
message
classification

Set the spam SetSCL SCLValue Sets the spam Exchange 2007
confidence level confidence level or later
(SCL) to (SCL) of the
message to the
Modify the specified value.
message
properties > set
the spam
confidence level
(SCL)

Apply rights ApplyRightsProte RMSTemplate Applies the Exchange 2010

protection to ctionTemplate specified Rights or later
the message Management
with Services (RMS)
template to the
Modify the message.
message
security > apply RMS requires
rights Exchange
protection Enterprise client
access licenses
(CALs) for each
mailbox. For more
information
about CALs, see
Exchange Server
Licensing.

Require TLS RouteMessageOu n/a Forces the Exchange 2013

encryption tboundRequireTls outbound or later
messages to be
Modify the routed over a TLS
message encrypted
security > connection.
require TLS
encryption
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Prepend the PrependSubject String Adds the Exchange 2007

subject of the specified text to or later
message with the beginning of
the Subject field
of the message.
Consider using a
space or a colon
(:) as the last
character of the
specified text to
differentiate it
from the original
subject text.
To prevent the
same string from
being added to
messages that
already contain
the text in the
subject (for
example, replies),
add the The
subject includes
(ExceptIfSubjectC
ontainsWords)
exception to the
rule.
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Notify the NotifySender First property: Notifies the Exchange 2013

sender with a NotifySenderType sender or blocks or later
Policy Tip RejectMessageRe the message
asonText Second property: when the
String message matches
RejectMessageEn
hancedStatusCod Third property a DLP policy.
e (Exchange (Exchange When you use
Management Management this action, you
Shell only) Shell only): need to use the
DSNEnhancedStatusCode The message
contains
sensitive
information
(MessageContain
sDataClassificati
on condition.
When you create
or modify the rule
in the Exchange
Management
Shell, the
RejectMessageRe
asonText
parameter is
optional. If you
don't use this
parameter, the
default text
Delivery not
authorized,
message
refused
is used.
In the Exchange
Management
Shell, you can
also use the
RejectMessageEn
hancedStatusCod
e parameter to
specify the
enhanced status
code. If you don't
use this
parameter, the
default enhanced
status code
5.7.1 is used.

This action limits

the other
conditions,
exceptions, and
actions that you
can configure in
the rule.
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Generate GenerateIncident First property: Sends an incident Exchange 2013

incident report Report Addresses report that or later
and send it to contains the
IncidentReportCo Second property: specified content
ntent IncidentReportContent to the specified
recipients.
An incident
report is
generated for
messages that
match data loss
prevention (DLP)
policies in your
organization.

Notify the GenerateNotifica NotificationMessageTextSpecifies the text, Exchange 2013

recipient with a tion HTML tags, and or later
message message
keywords to
include in the
notification
message that's
sent to the
message's
recipients. For
example, you can
notify recipients
that the message
was rejected by
the rule, or
marked as spam
and delivered to
their Junk Email
folder.
 ACTION PARAMETER IN
THE EXCHANGE
ACTION IN THE EAC MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE IN

Properties of SetAuditSeverity AuditSeverityLevel Specifies whether Exchange 2013

this rule section to: or later
> Audit this rule
with severity Prevent
level the
generatio
n of an
incident
report
and the
correspon
ding entry
in the
message
tracking
log.
Generate
an
incident
report
and the
correspon
ding entry
in the
message
tracking
log with
the
specified
severity
level (low,
medium,
or high).

Properties of StopRuleProcessi n/a Specifies that Exchange 2013

this rule section ng after the message or later
> Stop is affected by the
processing rule, the message
more rules is exempt from
processing by
More options > other rules.
Properties of
this rule section
> Stop
processing
more rules

Actions for transport rules on Edge Transport servers

A small subset of actions that are available on Mailbox servers are also available on Edge Transport servers, but
there are also some actions that are only available on Edge Transport servers. There's no EAC on Edge Transport
servers, so you can only manage transport rules in the Exchange Management Shell on the local Edge Transport
server. The actions are described in the following table. The properties types are described in the Property values
section.
ACTION PARAMETER IN
THE EXCHANGE
MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE ON AVAILABLE IN

AddToRecipients Addresses Adds one or Mailbox servers Exchange 2007

more recipients and Edge or later
to the To field of Transport servers
the message. The
original recipients
can see the
additional
addresses.

BlindCopyTo Addresses Adds one or Mailbox servers Exchange 2007

more recipients and Edge or later
to the Bcc field of Transport servers
the message. The
original recipients
aren't notified,
and they can't see
the additional
addresses.

CopyTo Addresses Adds one or Mailbox servers Exchange 2007

more recipients and Edge or later
to the Cc field of Transport servers
the message. The
original recipients
can see the
additional
address.

DeleteMessage n/a Silently drops the Mailbox servers Exchange 2007

message without and Edge or later
sending a Transport servers
notification to the
recipient or the
sender.

Disconnect n/a Ends the SMTP Edge Transport Exchange 2007

connection servers only or later
between the
sending server
and the Edge
Transport server
without
generating an
NDR.
ACTION PARAMETER IN
THE EXCHANGE
MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE ON AVAILABLE IN

LogEventText String Generates an Edge Transport Exchange 2007

event with the servers only or later
specified text in
the Application
log of the local
Edge Transport
server. The entry
contains the
following
information:
Level
Information

Source
MSExchange
Messaging
Policies

Event
ID
4000

Task
Category
Rules

EventDat
a
The
following
message
is logged
by an
action in
the
rules:
<text you
specify>.

PrependSubject String Adds the Mailbox servers Exchange 2007

specified text to and Edge or later
the beginning of Transport servers
the Subject field
of the message.
Consider using a
space or a colon
(:) as the last
character of the
specified text to
differentiate it
from the original
subject.
ACTION PARAMETER IN
THE EXCHANGE
MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE ON AVAILABLE IN

Quarantine n/a Delivers the Edge Transport Exchange 2010

message to the servers only or later
quarantine
mailbox that's
defined in the
content filtering
configuration on
the Edge
Transport server.
For more
information, see
Configure a spam
quarantine
mailbox.
If the quarantine
mailbox isn't
configured, the
message is
returned to the
sender in an NDR.

RedirectMessageT Addresses Redirects the Mailbox servers Exchange 2007

o message to the and Edge or later
specified Transport servers
recipients. The
message isn't
delivered to the
original recipients,
and no
notification is
sent to the
sender or the
original recipients.

RemoveHeader MessageHeaderField Removes the Mailbox servers Exchange 2007

specified header and Edge or later
field from the Transport servers
message header.

SetHeaderName First property: Adds or modifies Mailbox servers Exchange 2007

MessageHeaderField the specified and Edge or later
SetHeaderValue header field in the Transport servers
Second property: message header,
String and sets the
header field to
the specified
value.

SetSCL SCLValue Sets the SCL of Mailbox servers Exchange 2007

the message to and Edge or later
the specified Transport servers
value.
 ACTION PARAMETER IN
THE EXCHANGE
MANAGEMENT SHELL PROPERTY DESCRIPTION AVAILABLE ON AVAILABLE IN

SmtpRejectMessa First property: Ends the SMTP Edge Transport Exchange 2007
geRejectText String connection servers only or later
between the
SmtpRejectMessa Second property: sending server
geRejectStatusCo SMTPStatusCode and the Edge
de Transport server
with the specified
SMTP status code
and the specified
rejection text. The
recipient doesn't
receive the
original message
or notification.
Valid values for
the SMTP status
code are integers
from 400
through 500 as
defined in RFC
3463.
If you specify the
rejection text
without
specifying the
SMTP status
code, the default
code 550 is
used.
If you specify the
SMTP status code
without
specifying the
rejection text, the
text that's used is
Delivery not
authorized,
message
refused
.

StopRuleProcessi n/a Specifies that Mailbox servers Exchange 2013

ng after the message and Edge or later
is affected by the Transport servers
rule, the message
is exempt from
processing by
other rules.

Property values
The property values that are used for actions in transport rules are described in the following table.
PROPERTY VALID VALUES DESCRIPTION

AddedManagerAction One of the following values: Specifies how to include the

sender's manager in messages.
To
If you select To, Cc, or Bcc,
Cc the sender's manager is
Bcc added as a recipient in the
specified field.
Redirect
If you select Redirect, the
message is only delivered to
the sender's manager
without notifying the
sender or the recipient.
This action only works if the
sender's Manager attribute is
defined in Active Directory.

Addresses Exchange recipients Depending on the action, you

might be able to specify any mail-
enabled object in the organization,
or you might be limited to a
specific object type. Typically, you
can select multiple recipients, but
you can only send an incident
report to one recipient.

AuditSeverityLevel One of the following values: The values Low, Medium, or High
specify the severity level that's
Uncheck Audit this rule assigned to the incident report and
with severity level, or to the corresponding entry in the
select Audit this rule with message tracking log.
severity level with the
value Not specified ( The other value prevents an
DoNotAudit ) incident report from being
generated, and prevents the
Low corresponding entry from being
Medium written to the message tracking
log.
High
PROPERTY VALID VALUES DESCRIPTION

DisclaimerFallbackAction One of the following values: Specifies what to do if the

disclaimer can't be applied to a
Wrap message. There are situations
Ignore where the contents of a message
can't be altered (for example, the
Reject message is encrypted). The
available fallback actions are:
Wrap The original
message is wrapped in a
new message envelope, and
the disclaimer text is
inserted into the new
message. This is the default
value.
Notes:
Subsequent
transport rules are
applied to the new
message envelope,
not to the original
message. Therefore,
configure these rules
with a lower priority
than other rules.
If the original
message can't be
wrapped in a new
message envelope,
the original message
isn't delivered. The
message is returned
to the sender in an
NDR.
Ignore The rule is ignored
and the message is
delivered without the
disclaimer
Reject The message is
returned to the sender in an
NDR.

DisclaimerText HTML string Specifies the disclaimer text, which

can include HTML tags, inline
cascading style sheet (CSS) tags,
and images by using the IMG tag.
The maximum length is 5000
characters, including tags.
PROPERTY VALID VALUES DESCRIPTION

DisclaimerTextLocation Single value: Append or Prepend In the Exchange Management Shell,

you use the
ApplyHtmlDisclaimerTextLocation
to specify the location of the
disclaimer text in the message:
Append Add the
disclaimer to the end of the
message body. This is the
default value.
Prepend Add the
disclaimer to the beginning
of the message body.

DSNEnhancedStatusCode Single DSN code value: Specifies the DSN code that's used.
You can create custom DSNs by
5.7.1
using the New-SystemMessage
5.7.900 through cmdlet.
5.7.999 If you don't specify the rejection
reason text along with the DSN
code, the default reason text that's
used is
Delivery not authorized,
message refused
.
When you create or modify the rule
in the Exchange Management Shell,
you can specify the rejection reason
text by using the
RejectMessageReasonText
parameter.

IncidentReportContent One or more of the following Specifies the original message

values: properties to include in the incident
report. You can choose to include
Sender any combination of these
Recipients properties. In addition to the
properties you specify, the message
Subject ID is always included. The available
Cc'd recipients ( Cc ) properties are:
Sender The sender of the
Bcc'd recipients ( Bcc )
original message.
Severity Recipients, Cc'd recipients
Sender override , and Bcc'd recipients All
information ( Override ) recipients of the message,
or only the recipients in the
Matching rules ( Cc or Bcc fields. For each
RuleDetections ) property, only the first 10
recipients are included in
False positive reports ( the incident report.
FalsePositive )
Subject The Subject field
Detected data of the original message.
classifications (
DataClassifications ) Severity The audit
severity of the rule that was
Matching content ( triggered. Message tracking
 IdMatch ) logs include all the audit
PROPERTY VALID VALUES DESCRIPTION
severity levels, and can be
Original mail ( filtered by audit severity. In
AttachOriginalMail ) the EAC, if you clear the
Audit this rule with
severity level check box (in
the Exchange Management
Shell, the SetAuditSeverity
parameter value
DoNotAudit ), rule matches
won't appear in the rule
reports. If a message is
processed by more than
one rule, the highest
severity is included in any
incident reports.
Sender override
information The override
if the sender chose to
override a Policy Tip. If the
sender provided a
justification, the first 100
characters of the
justification are also
included.
Matching rules The list of
rules that the message
triggered.
False positive
reports The false positive
if the sender marked the
message as a false positive
for a Policy Tip.
Detected data
classifications The list of
sensitive information types
detected in the message.
Matching content The
sensitive information type
detected, the exact matched
content from the message,
and the 150 characters
before and after the
matched sensitive
information.
Original mail The entire
message that triggered the
rule is attached to the
incident report.
In the Exchange Management Shell,
you specify multiple values
separated by commas.
PROPERTY VALID VALUES DESCRIPTION

MessageClassification Single message classification object In the EAC, you select from the list
of available message classifications.
In the Exchange Management Shell,
use the Get-
MessageClassification cmdlet to
see the message classification
objects that are available.

MessageHeaderField Single string Specifies the SMTP message header

field to add, remove, or modify.
The message header is a collection
of required and optional header
fields in the message. Examples of
header fields are To, From,
Received, and Content-Type.
Official header fields are defined in
RFC 5322. Unofficial header fields
start with X- and are known as X-
headers.

NotificationMessageText Any combination of plain text, Specified the text to use in a

HTML tags, and keywords recipient notification message.
In addition to plain text and HTML
tags, you can specify the following
keywords that use values from the
original message:
%%From%%

%%To%%

%%Cc%%

%%Subject%%

%%Headers%%

%%MessageDate%%
PROPERTY VALID VALUES DESCRIPTION

NotifySenderType One of the following values: Specifies the type of Policy Tip that
the sender receives if the message
Notify the sender, but violates a DLP policy. The settings
allow them to send ( are described in the following list:
NotifyOnly )
Notify the sender, but
Block the message ( allow them to send The
RejectMessage ) sender is notified, but the
Block the message unless message is delivered
it's a false positive ( normally.
RejectUnlessFalsePositiveOverride Block the message The
) message is rejected, and the
sender is notified.
Block the message, but
allow the sender to Block the message unless
override and send ( it's a false positive The
RejectUnlessSilentOverride message is rejected unless
) it's marked as a false
positive by the sender.
Block the message, but
allow the sender to Block the message, but
override with a business allow the sender to
justification and send ( override and send The
RejectUnlessExplicitOverride message is rejected unless
) the sender has chosen to
override the policy
restriction.
Block the message, but
allow the sender to
override with a business
justification and send This
is similar to Block the
message, but allow the
sender to override and
send type, but the sender
also provides a justification
for overriding the policy
restriction.
When you use this action, you
need to use the The message
contains sensitive information
(MessageContainsDataClassificati
on) condition.
 PROPERTY VALID VALUES DESCRIPTION

RMSTemplate Single RMS template object Specifies the Rights Management

Services (RMS) template that's
applied to the message.
In the EAC, you select the RMS
template from a list.
In the Exchange Management Shell,
use the Get-RMSTemplate cmdlet
to see the RMS templates that are
available.
RMS requires Exchange Enterprise
client access licenses (CALs) for
each mailbox. For more information
about CALs, see Exchange Server
Licensing.

SCLValue One of the following values: Specifies the spam confidence level
(SCL) that's assigned to the
Bypass spam filtering ( message. A higher SCL value
-1 )
indicates that a message is more
Integers 0 through 9 likely to be spam.

String Single string Specifies the text that's applied to

the specified message header field,
NDR, or event log entry.
In the Exchange Management Shell,
if the value contains spaces, enclose
the value in quotation marks (").

For more information

Manage transport rules in Exchange 2013
Transport rules in Exchange 2013
Transport rule conditions and exceptions (predicates) in Exchange 2013
Transport rule actions in Exchange Online for Exchange Online
Transport rule actions in Exchange Online Protection for Exchange Online Protection
Organization-wide message disclaimers, signatures, footers, or headers in Office 365
 Best practices for configuring transport rules in
Exchange 2013
5/30/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Follow these best practice recommendations for Exchange transport rules in order to avoid common configuration
errors. Each recommendation links to a topic with an example and step-by-step instructions.

Test your rules

To make sure unexpected things don't happen to people's email, and to make sure you're really meeting the
business, legal, or compliance intentions of your rule, be sure to test it thoroughly. There are many options, and
rules can interact with each other, so it's important to test messages that you expect both will match the rule and
won't match the rule in case you inadvertently made a rule too general. To learn all the options for testing rules, see
Test a transport rule.

Scope your rule

Make sure your rule applies only to the messages you intend it to. For example:
Restrict a rule to messages either coming into or going out of the organization
By default, a new rule applies to messages that are either sent or received by people in your organization. So
if you want the rule to apply only one way, be sure to specify that in the conditions for the rule. For an
example, see Common attachment blocking scenarios for transport rules.
Restrict a rule based on the sender's or receiver's domain
By default, a new rule applies to messages sent from or received at any domain. Sometimes you want a rule
to apply to all domains except for one, or to just one domain. For examples, see Create a Domain or User-
Based Safe Sender or Blocked Sender List Using Transport Rules.
For a complete list of all the conditions and exceptions that are available for transport rules, see Transport rule
conditions and exceptions (predicates) in Exchange 2013.

Know when you need two rules

Sometimes it takes two rules to do what you want. Transport rules are processed in order, so multiple rules can
apply to the same message. For example, if one of the actions is to block the message, and you also have another
action you'd like to apply, such as copying the message to the sender's manager or changing the subject for the
notification message, you would need two rules. The first rule could copy the message to the sender's manager and
change the subject, and the second rule could block the message.
If you use two rules like this, be sure that the conditions are identical. To see examples, look at example 3 in
Common message approval scenarios, example 3 in Common attachment blocking scenarios for transport rules,
and Organization-wide disclaimers, signatures, footers, or headers.

Don't repeat an action on every email in a conversation

The chain of email in a conversation can include many individual messages, and repeating the action on each
message in the thread might get annoying. For example, if you have an action such as adding a disclaimer, you
might want it to apply only to the first message in the thread. If so, add an exception for messages that already
include the disclaimer text. For an example, see Organization-wide disclaimers, signatures, footers, or headers.

Know when to stop rule processing

Sometimes it makes sense to stop rule processing once a rule is matched. For example, if you have one rule to
block messages with attachments and one to insert a disclaimer in messages that match a pattern, you probably
should stop rule processing once the message is blocked. There's no need for further action.
To stop rule processing after a rule is triggered, in the rule, select the Stop processing more rules check box.

If you have lots of keywords or patterns to match, load them from a file
For example, you might want to prevent emails from being sent if they contain a list of unacceptable or bad words.
You can create a text file containing these words and phrases, and then use Windows PowerShell to set up a
transport rule that blocks messages that use them.
The text file can contain regular expressions for patterns. These expressions are not case-sensitive. Common
regular expressions include:

EXPRESSION MATCHES

. Any single character

* Any additional characters

\d Any decimal digit

[character_group] Any single character in character_group.

For an example that shows a text file with regular expressions and the Exchange module Windows PowerShell
commands to use, see Use transport rules to route email based on a list of words, phrases, or patterns.
To learn how to specify patterns using regular expressions, see Regular Expression Reference.
 Use transport rules to inspect message attachments
6/14/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can inspect email attachments in your organization by setting up transport rules. Exchange offers transport
rules that provide the ability to examine email attachments as a part of your messaging security and compliance
needs. When you inspect attachments, you can then take action on the messages that were inspected based on the
content or characteristics of those attachments. Here are some attachment-related tasks you can do by using
transport rules:
Search files in compressed attachments such as .zip and .rar files and, if there's any text that matches a
pattern you specify, add a disclaimer to the end of the message.
Inspect content within attachments and, if there are any keywords you specify, redirect the message to a
moderator for approval before it's delivered.
Check for messages with attachments that can't be inspected and then block the entire message from being
sent.
Check for attachments that exceed a certain size and then notify the sender of the issue if you choose to
prevent the message from being delivered.
Create notifications that alert users if they send a message that has matched a transport rule.
Block all messages containing attachments. For examples, see Common attachment blocking scenarios.
Exchange administrators can create transport rules by going to Exchange admin center > Mail flow > Rules.
You need to be assigned permissions before you can perform this procedure. After you start to create a new rule,
you can see the full list of attachment-related conditions by clicking More options > Any attachment under
Apply this rule if. The attachment-related options are shown in the following diagram.

For more information about transport rules, including the full range of conditions and actions that you can choose,
see Mail flow or transport rules. Exchange Online Protection (EOP ) and hybrid customers can benefit from the
transport rules best practices provided in Best practices for configuring EOP. If you're ready to start creating rules,
see Manage transport rules in Exchange 2013.

Inspect the content within attachments

You can use the transport rule conditions in the following table to examine the content of attachments to
messages. For these conditions, only the first 150 KB of an attachment is inspected. In order to start using these
conditions when inspecting messages, you need to add them to a transport rule. Learn about creating or changing
rules at Manage transport rules in Exchange 2013

CONDITION NAME IN EAC CONDITION NAME IN THE SHELL DESCRIPTION

Any attachment content includes AttachmentContainsWords This condition matches messages

any of these words with supported file type
attachments that contain a
specified string or group of
characters.

Any attachment content matches AttachmentMatchesPatterns This condition matches messages

these text patterns with supported file type
attachments that contain a text
pattern that matches a specified
regular expression.

The Exchange Management Shell names for the conditions listed here are parameters that require the
TransportRule cmdlet.

Learn more about the cmdlet at New -TransportRule.

Learn more about property types for these conditions at Conditions and Condition Properties for a Mailbox
Server.
Transport rules can inspect only the content of supported file types. If the transport rules agent encounters an
attachment that isn't in the list of supported file types, the AttachmentIsUnsupported condition is triggered. The
supported file types are listed in the following section. Any file not listed will trigger the AttachmentIsUnsupported
condition.

Compressed archive files

If the message contains a compressed archive file such as a .zip or .cab file, the transport rules agent will inspect
the files contained within that attachment. Such messages are processed in a manner similar to messages that
have multiple attachments. The properties of compressed archive files aren't inspected. For example, if the
container file type supports comments, that field isn't inspected.

Supported file types for transport rule content inspection

The following table lists the file types supported by transport rules. The system automatically detects file types by
inspecting file properties rather than the actual file name extension, thus helping to prevent malicious hackers
from being able to bypass transport rule filtering by renaming a file extension. A list of file types with executable
code that can be checked within the context of transport rules is listed later in this topic.
 CATEGORY FILE EX TENSION NOTES

Office 2013, Office 2010, and Office .docm, .docx, .pptm, .pptx, .pub, Microsoft OneNote and Microsoft
2007 .one, .xlsb, .xlsm, .xlsx Publisher files aren't supported by
default. You can enable support for
these file types by using IFilter
integration. For more information,
see Register Filter Pack IFilters with
Exchange 2013.
The contents of any embedded
parts contained within these file
types are also inspected. However,
any objects that aren't embedded
(for example, linked documents)
aren't inspected.

Office 2003 .doc, .ppt, .xls None

Additional Office files .rtf, .vdw, .vsd, .vss, .vst None

Adobe PDF .pdf None

HTML .html None

XML .xml, .odp, .ods, .odt None

Text .txt, .asm, .bat, .c, .cmd, .cpp, .cxx, None

.def, .dic, .h, .hpp, .hxx, .ibq, .idl, .inc,
inf, .ini, inx, .js, .log, .m3u, .pl, .rc,
.reg, .txt, .vbs, .wtx

OpenDocument .odp, .ods, .odt No parts of .odf files are processed.

For example, if the .odf file contains
an embedded document, the
contents of that embedded
document aren't inspected.

AutoCAD Drawing .dxf AutoCAD 2013 files aren't

supported.

Image .jpg, .tiff Only the metadata text associated

with these image files is inspected.
There is no optical character
recognition.

Inspect the file properties of attachments

The following transport rule conditions inspect the properties of a file that is attached to a message. In order to
start using these conditions when inspecting messages, you need to add them to a transport rule. A list of
supported file types with executable code that can be checked within the context of transport rules is listed here.
For more information about creating or changing rules, see Manage transport rules in Exchange 2013.

CONDITION NAME IN EAC CONDITION NAME IN THE SHELL DESCRIPTION

Any attachment file name AttachmentNameMatchesPatterns This condition matches messages

matches these text patterns with supported file type
attachments when those
attachments have a name that
contains the characters you specify.

Any attachment file extension AttachmentExtensionMatchesWords This condition matches messages

includes these words with supported file type
attachments when the file name
extension matches what you
specify.

Any attachment size is greater AttachmentSizeOver This condition matches messages

than or equal to with supported file type
attachments when those
attachments are larger than the
size you specify.

Any attachment didn't complete AttachmentProcessingLimitExceeded This condition matches messages

scanning when an attachment is not
inspected by the transport rules
agent.

Any attachment has executable AttachmentHasExecutableContent This condition matches messages

content that contain executable files as
attachments. The supported file
types are listed here.

Any attachment is password AttachmentIsPasswordProtected This condition matches messages

protected with supported file type
attachments when those
attachments are protected by a
password.

The Exchange Management Shell names for the conditions listed here are parameters that require the
TransportRule cmdlet.

Learn more about the cmdlet at New -TransportRule.

Learn more about property types for these conditions at Conditions and Condition Properties for a Mailbox
Server.

Supported executable file types for transport rule inspection

The transport agent uses true type detection by inspecting file properties rather than merely the file extensions.
This helps to prevent malicious hackers from being able to bypass your rule by renaming a file extension. The
following table lists the executable file types supported by these conditions. If a file is found that is not listed here,
the AttachmentIsUnsupported condition is triggered.
 TYPE OF FILE NATIVE EX TENSION

Self-extracting archive file created with the WinRAR .rar

archiver.

32-bit Windows executable file with a dynamic link library .dll

extension.

Self-extracting executable program file. .exe

Java archive file. .jar

Uninstallation executable file. .exe

Program shortcut file. .exe

Compiled source code file or 3-D object file or sequence .obj

file.

32-bit Windows executable file. .exe

Microsoft Visio XML drawing file. .vxd

OS/2 operating system file. .os2

16-bit Windows executable file. .w16

Disk-operating system file. .dos

European Institute for Computer Antivirus Research .com

standard antivirus test file.

Windows program information file. .pif

Windows executable program file. .exe

Extending the number of supported file types

The supported file types listed in this topic can be revised at any time using IFilter integration. For more
information, see Register Filter Pack IFilters with Exchange 2013.
The file types you add using this process become supported file types and no longer trigger the
AttachmentIsUnsupported condition.
Data loss prevention policies and attachment transport rules
To help you manage important business information in email, you can include any of the attachment-related
conditions along with the rules of a data loss prevention (DLP ) policy. For example, you might want to allow
messages with passport numbers to be sent but only if the passport numbers are in a password-protected
attachment. To accomplish this, do the following:
Create a DLP policy that inspects mail for passport-related sensitive information. Learn more at DLP
procedures.
Add the Any attachment is password protected exception in the Except if... transport rule area.
Define an action to take on mail that contains passport numbers that are not in the protected file.
DLP policies and attachment-related conditions can help you enforce your business needs by defining those needs
as transport rule conditions, exceptions, and actions. When you include the sensitive information inspection in a
DLP policy, any attachments to messages are scanned for that information only. However, attachment-related
conditions such as size or file type are not included until you add the conditions listed in this topic. DLP is not
available with all versions of Exchange; learn more at Data loss prevention.

For more information

Data loss prevention
Mail flow or transport rules
Transport rule conditions (predicates)
Use transport rules to inspect message attachments in Exchange Online
 Common attachment blocking scenarios for transport
rules in Exchange 2013
5/30/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Your organization might require that certain types of messages be blocked or rejected in order to meet legal or
compliance requirements, or to implement specific business needs. This article discusses examples of common
scenarios for blocking all attachments which you can set up using transport rules in Exchange.
For additional examples showing how to block specific attachments, see Using transport rules to inspect message
attachments.
The malware filter includes a Common Attachment Types Filter. In the Exchange admin center (EAC ), go to
Protection, then click New to add filters.
To get started implementing any of these scenarios to block certain message types:
1. Sign in to the Exchange admin center.
2. Go to Mail flow > Rules.
3. Click New and then select Create a new rule.
4. In the Name box, specify a name for the rule, and then click More options.
5. Select the conditions and actions you want.
Note: In the EAC, the smallest attachment size that you can enter is 1 kilobyte, which should detect most
attachments. However, if you want to detect every possible attachment of any size, you need to use
PowerShell to adjust the attachment size to 1 byte after you create the rule in the EAC. To learn how to open
the Exchange Management Shell in your on-premises Exchange organization, see Open the Shell.
Replace <Rule Name> with the name of the existing rule, and run the following command to set the
attachment size to 1 byte:

Set-TransportRule -Identity "<Rule Name>" -AttachmentSizeOver 1B

After you adjust the attachment size to 1 byte, the value that's displayed for the rule in the EAC is 0.00 KB.

Example 1: Block messages with attachments, and notify the sender

If you don't want people in your organization to send or receive attachments, you can set up a transport rule to
block all messages with attachments.
In this example, all messages sent to or from the organization with attachments are blocked.
If all you want to do is block the message, you might want to stop rule processing once this rule is matched. Scroll
down the rule dialog box, and select the Stop processing more rules check box.

Example 2: Notify intended recipients when an inbound message is

blocked
If you want to reject a message but let the intended recipient know what happened, you can use the Notify the
recipient with a message action.
You can include placeholders in the notification message so that it includes information about the original
message. The placeholders must be enclosed in two percent signs (%%), and when the notification message is
sent, the placeholders are replaced with information from the original message. You can also use basic HTML such
as <br>, <b>, <i>, and <img> in the message.

TYPE OF INFORMATION PLACEHOLDER

Sender of the message. %%From%%

Recipients listed on the "To" line. %%To%%

Recipients listed on the "Cc" line. %%Cc%%

Subject of the original message. %%Subject%%

Headers from the original message. This is similar to the list of %%Headers%%
headers in a delivery status notification (DSN) generated for
the original message.

Date the original message was sent. %%MessageDate%%

In this example, all messages that contain attachments and are sent to people inside your organization are blocked,
and the recipient is notified.
Example 3: Modify the subject line for notifications
When a notification is sent to the recipient, the subject line is the subject of the original message. If you want to
modify the subject so that it is clearer to the recipient, you must use two transport rules:
The first rule adds the word "undeliverable" to the beginning of the subject of any messages with
attachments.
The second rule blocks the message and sends a notification message to the sender using the new subject
of the original message.

IMPORTANT
The two rules must have identical conditions. Rules are processed in order, so the first rule adds the word "undeliverable",
and the second rule blocks the message and notifies the recipient.

Here's what the first rule would look like if you want to add "undeliverable" to the subject:

And the second rule does the blocking and notification (the same rule from Example 2):
Example 4: Apply a rule with a time limit
If you have a malware outbreak, you might want to apply a rule with a time limit so that you temporarily block
attachments. For example, the following rule has both a start and stop day and time:

See also
Transport rules in Exchange 2013
 Organization-wide disclaimers, signatures, footers, or
headers
5/21/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can add an email disclaimer, legal disclaimer, disclosure statement, signature, or other information to the top or
bottom of email messages that enter or leave your organization. This might be needed for legal, business, or
regulatory requirements, to identify potentially unsafe e-mail messages, or for other reasons unique to your
organization.
To set up a disclaimer, you create a transport rule that includes the conditions, such when the sender is in a specific
group or when the message includes specific text patterns, and the text to add. To apply multiple disclaimers to a
single email message, you use multiple transport rules.

IMPORTANT
If you want the information to be added only to outgoing messages, you must add a condition such as recipients
located outside the organization. By default, transport rules are applied to both incoming and outgoing messages.

Looking for procedures? See Add an email disclaimer, legal disclaimer, common signature, or email footer or
header.

Examples
Here are a few ideas for how to use disclaimers.

TYPE SAMPLE TEX T ADDED

Legal - outgoing messages This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity
to whom they are addressed. If you have received this
email in error, please notify the system manager.

Legal - incoming messages Employees are expressly required not to make defamatory
statements and not to infringe or authorize any
infringement of copyright or any other legal right by email
communications. Employees who receive such an email
must notify their supervisor immediately.

Notice that message was sent to an alias This message was sent to the Sales discussion group.

Signature - pulls in data for each employee Kathleen Mayer

Sales Department
Contoso
www.contoso.com
[email protected]
cell: 111-222-1234
 TYPE SAMPLE TEX T ADDED

Advertisement Click here for March specials

The examples in this article are not intended for use as-is. Modify them for your needs.

Scoping your disclaimer

As you work on your disclaimers, consider which messages they should apply to. For example, you might want
different disclaimers for internal and external messages or for messages sent by users in specific departments. To
make sure only the first message in a conversation gets a disclaimer, add an exception that looks for unique text in
your disclaimer.
Here are some examples of the conditions and exceptions you can use.

CONDITIONS AND EXCEPTIONS IN THE

DESCRIPTION CONDITIONS AND EXCEPTIONS IN EAC SHELL

Outside your organization, if the Condition: The recipient is

original message doesn't include located > Outside the -FromScope NotInOrganization
text from your disclaimer, such as organization -ExceptIf -
"CONTOSO LEGAL NOTICE" SubjectOrBodyMatches "CONTOSO
Exception: The subject or body > LEGAL NOTICE"
Subject or body matches these
text patterns > CONTOSO LEGAL
NOTICE

Incoming messages with executable Condition 1: The sender is located

attachments > Outside the organization -FromScope NotInOrganization
-
Condition 2: Any attachment > AttachmentHasExecutableConten
has executable content t

Sender is in the marketing Condition: The sender > is a

department member of this group > group -FromMemberOf "Marketing
name Team"

Every message that comes from an Condition 1: The sender is located

external sender to the sales > Outside the organization -FromScope NotInOrganization
discussion group -SentTo "Sales Discussion
Condition 2: The message > To or Group" -PrependSubject "Sent
Cc box contains this person > to Sales Discussion Group: "
group name

Prepend an advertisement to Condition 1: The recipient is

outgoing messages for one month located > Outside the -ApplyHtmlDisclaimerLocation
organization 'Prepend' -SentToScope
'NotInOrganization' -
Specify the dates at the bottom of ActivationDate '03/1/2014' -
the New rule dialog. ExpiryDate '03/31/2014'

For a complete list of transport rule conditions you can use to target the disclaimer, see one of the following:
Transport rule conditions (predicates) (Exchange Online)
 Transport rule conditions (predicates) (Exchange 2013)
Transport rule conditions (predicates) (Exchange Online Protection)

Formatting your disclaimer

You can format your disclaimer as needed. Here's what can be included in your disclaimer text.

TYPE OF INFORMATION DESCRIPTION

Text The maximum length is 5,000 characters, including any

HTML tags and inline Cascading Style Sheets (CSS).

HTML and inline CSS You can use HTML and inline CSS styles to format the
text. For example, use the <HR> tag to add a line before
the disclaimer.
HTML in a disclaimer is ignored if the disclaimer is added
to a plain text message.

Add Images Use the <IMG> tag to point to an image available on the
internet. For example,
<IMG
src="http://contoso.com/images/companylogo.gif"
alt="Contoso logo">

Keep in mind that Outlook Web App and Outlook block

external web content, including images, by default. Users
may need to perform a specific action if they want to view
the blocked external content. This means that images
added by using the IMG tag may not be visible by
default. We recommend that you test a disclaimer with
IMG tags in the email clients your recipients are likely to
use to make sure it displays well.

Add information for personalized signatures If you want everyone to have signatures formatted the
same way with the same information, you can add unique
information for each employee, such as DisplayName ,
FirstName , LastName , PhoneNumber , Email ,
FaxNumber , and Department . This information must be
enclosed in two percent signs (%%) on each side of the
information. For example, to use DisplayName , you must
use %%DisplayName%% in your disclaimer.
When a disclaimer rule is triggered, the corresponding
values for that user are inserted. The data comes from the
sender's Active Directory user account (for on-premises
Exchange Server), or from the sender's Office 365 account
for Exchange Online.
For a complete list of attributes that can be used in
disclaimers and personalized signatures, see the
description for the ADAttribute property in Transport
rule conditions (predicates) (Exchange Server), Transport
rule conditions (predicates) (Exchange Online), or
Transport rule conditions (predicates) (Exchange Online
Protection).

For example, here's an example of an HTML disclaimer that includes a signature, an IMG tag, and embedded CSS.
 <div style="font-size:9pt; font-family: 'Calibri',sans-serif;">
%%displayname%%</br>
%%title%%</br>
%%company%%</br>
%%street%%</br>
%%city%%, %%state%% %%zipcode%%</div>
&nbsp;</br>
<div style="background-color:#D5EAFF; border:1px dotted #003333; padding:.8em; ">
<div><img alt="Fabrikam" src="http://fabrikam.com/images/fabrikamlogo.png"></div>
<span style="font-size:12pt; font-family: 'Cambria','times new roman','garamond',serif; color:#ff0000;">HTML
Disclaimer Title</span></br>
<p style="font-size:8pt; line-height:10pt; font-family: 'Cambria','times roman',serif;">This message contains
confidential information and is intended only for the individual(s) addressed in the message. If you are not
the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended
recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.
</p>
<span style="padding-top:10px; font-weight:bold; color:#CC0000; font-size:10pt; font-family:
'Calibri',Arial,sans-serif; "><a href="http://www.fabrikam.com">Fabrikam, Inc. </a></span></br></br>
</div>

Fallback options if the disclaimer can't be added

Some messages, such as encrypted messages, prevent Exchange from modifying the content of the original
message. You can control how your organization handles these messages. You specify whether to wrap a message
that can't be modified in a message envelope that contains the disclaimer, reject the message if a disclaimer can't
be added, or ignore the disclaimer action and deliver the message without a disclaimer.
The following list describes each fallback action:
Wrap: If the disclaimer can't be inserted into the original message, Exchange encloses, or "wraps," the
original message in a new message envelope. Then the disclaimer is inserted into the new message. If the
original message can't be wrapped in a new message envelope, the original message is not delivered. The
sender of the message receives a non-delivery report (NDR ) that explains why the message was not
delivered.

IMPORTANT
If an original message is wrapped in a new message envelope, subsequent transport rules are applied to the new
message envelope, not to the original message. Therefore, you must configure transport rules with disclaimer actions
that wrap original messages in a new message body after you configure other transport rules.

Reject: If the disclaimer can't be inserted into the original message, Exchange doesn't deliver the message.
The sender of the message receives an NDR that explains why the message wasn't delivered.
Ignore: If the disclaimer can't be inserted into the original message, Exchange delivers the original message
unmodified. No disclaimer is added.

For more information

Add an email disclaimer, legal disclaimer, common signature, or email footer or header
Mail flow or transport rules (Exchange Server 2013)
Mail flow or transport rules (Exchange Online)
Transport rules (Exchange Online Protection)
 Mail flow or transport rule procedures
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can begin using transport rules by using the following procedures. To learn about concepts and objectives for
transport rules, see Mail flow or transport rules.
Add an email disclaimer, legal disclaimer, common signature, or email footer or header: Information to help you set
up a legal disclaimer, email disclaimer, consistent signature, email header, or email footer by using transport rules.
Create a domain or user-based safe sender or blocked sender list: Information to help you create domain or user-
based safe sender and blocked sender lists by using transport rules.
Use transport rules to route email based on a list of words, phrases, or patterns: Information to help you comply
with your organization's email policies.
Register Filter Pack IFilters with Exchange 2013: Information to help you register additional file types for
attachments so that transport rules that apply to attachments can scan these file types.
Manage transport rules in Exchange 2013: Information to help you create, view, modify, enable, disable, or remove
a transport rule, and information about importing and exporting transport rule collections.
Best practices for configuring transport rules: Information to help you avoid common configuration errors.
 Manage transport rules in Exchange 2013
5/30/2019 • 12 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use transport rules, also known as transport rules, to look for specific conditions on messages that pass
through your organization and take action on them. This topic shows you how to create, copy, adjust the order,
enable or disable, delete, or import or export rules.

TIP
To make sure your rules work the way you expect, be sure to thoroughly test each rule and interactions between rules.

Interested in scenarios where these procedures are used? See the following topics:
Organization-wide Disclaimers, Signatures, Footers, or Headers
Use transport rules to inspect message attachments in Exchange 2013
Common attachment blocking scenarios for transport rules
Use transport rules to route email based on a list of words, phrases, or patterns
Common message approval scenarios
Best practices for configuring transport rules
Use transport rules to aggressively filter bulk email messages
Define rules to encrypt or decrypt messages
Create a Domain or User-Based Safe Sender or Blocked Sender List Using Transport Rules

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport rules" entry in Messaging policy and compliance permissions.
When a rule is listed as version 14, this means that the rule is based on an Exchange Server 2010 transport
rule format. All options are available for these rules.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Create a transport rule

You can create a transport rule by setting up a Data Loss Prevention (DLP ) policy, creating a new rule, or by
copying a rule. You can use the Exchange admin center (EAC ) or the Exchange Management Shell.
 NOTE
After you create or modify a transport rule, it can take up to 30 minutes for the new or updated rule to be applied to email.

Use a DLP policy to create transport rules

Each DLP policy is a collection of transport rules. After you create the DLP policy, you can fine-tune the rules using
the procedures below.
1. Create a DLP policy. For instructions, see Exchange Server 2013 DLP Procedures.
2. Modify the transport rules created by the DLP policy. See View or modify a transport rule.
Use the EAC to create a transport rule
The EAC allows you to create transport rules by using a template, copying an existing rule, or from scratch.
1. Go to Mail flow > Rules.
2. Create the rule by using one of the following options:
To create a rule from a template, click Add and select a template.
To copy a rule, select the rule, and then select Copy .
To create a new rule from scratch, Add and then select Create a new rule.
3. In the New rule dialog box, name the rule, and then select the conditions and actions for this rule:
a. In Apply this rule if..., select the condition you want from the list of available conditions.
Some conditions require you to specify values. For example, if you select The sender is...
condition, you must specify a sender address. If you're adding a word or phrase, note that
trailing spaces are not allowed.
If the condition you want isn't listed, or if you need to add exceptions, select More options.
Additional conditions and exceptions will be listed.
If you don't want to specify a condition, and want this rule to apply to every message in your
organization, select [Apply to all messages] condition.
b. In Do the following..., select the action you want the rule to take on messages matching the criteria
from the list of available actions.
Some of the actions will require you to specify values. For example, if you select the Forward
the message for approval to... condition, you will need to select a recipient in your
organization.
If the condition you want isn't listed, select More options. Additional conditions will be listed.
c. Specify how rule match data for this rule is displayed in the Data Loss Prevention (DLP ) reports and
the transport rule reports.
Under Audit this rule with severity level, select a level to specify the severity level for this rule.
Severity level is just a filter to make the reports easier to use. The severity level has no impact on the
priority in which the rule is processed.
 NOTE
If you clear the Audit this rule with severity level checkbox, rule matches will not show up in the rule
reports.

d. Set the mode for the rule. You can use one of the two test modes to test the rule without impacting
mail flow. In both test modes, when the conditions are met, an entry is added to the message trace.
Enforce: This turns on the rule and it starts processing messages immediately. All actions on
the rule will be performed.
Test with Policy Tips: This turns on the rule, and any Policy Tip actions ( Notify the sender
with a Policy Tip) will be sent, but no actions related to message delivery will be performed.
Data Loss Prevention (DLP ) is required in order to use this mode. To learn more, see Policy
Tips.
Test without Policy Tips: Only the Generate incident report action will be enforced. No actions related
to message delivery are performed.
4. If you are satisfied with the rule, go to step 5. If you want to add more conditions or actions, or if you want
to specify exceptions or set additional properties, click More options. After you click More options,
complete the following fields to create your rule:
a. To add more conditions, click Add condition. If you have more than one condition, you can remove
any one of them by clicking Remove X next to it. Note that there are a larger variety of conditions
available once you click More options.
b. To add more actions, click Add action. If you have more than one action, you can remove any one of
them by clicking Remove X next to it. Note that there are a larger variety of actions available once
you click More options.
c. To specify exceptions, click Add exception, then select exceptions using the Except if... dropdown.
You can remove any exceptions from the rule by clicking the Remove X next to it.
d. If you want this rule to take effect after a certain date, click Activate this rule on the following
date: and specify a date. Note that the rule will still be enabled prior to that date, but it won't be
processed.
Similarly, you can have the rule stop processing at a certain date. To do so, click Deactivate this rule
on the following date: and specify a date. Note that the rule will remain enabled, but it won't be
processed.
e. You can choose to avoid applying additional rules once this rule processes a message. To do so, click
Stop processing more rules. If you select this, and a message is processed by this rule, no
subsequent rules are processed for that message.
f. You can specify how the message should be handled if the rule processing can't be completed. By
default, the rule will be ignored and the message will be processed regularly, but you can choose to
resubmit the message for processing. To do so, check the Defer the message if rule processing
doesn't complete check box.
g. If your rule analyzes the sender address, it only examines the message headers by default. However,
you can configure your rule to also examine the SMTP message envelope. To specify what's
examined, click one of the following values for Match sender address in message:
Header: Only the message headers will be examined.
Envelope: Only the SMTP message envelope will be examined.
 Header or envelope: Both the message headers and SMTP message envelope will be
examined.
h. You can add comments to this rule in the Comments box.
5. Click Save to complete creating the rule.
Use the Exchange Management Shell to create a transport rule
This example uses the New -TransportRule cmdlet to create a new transport rule that prepends "
External message to Sales DG: " to messages sent from outside the organization to the Sales Department
distribution group.

New-TransportRule -Name "Mark messages from the Internet to Sales DG" -FromScope NotInOrganization -SentTo
"Sales Department" -PrependSubject "External message to Sales DG:"

The rule parameters and action used in the above procedure are for illustration only. Review all the available
transport rule conditions and actions to determine which ones meet your requirements.
How do you know this worked?
To verify that you have successfully created a new transport rule, do the following:
From the EAC, verify that the new transport rule you created is listed in the Rules list.
From the Exchange Management Shell, verify that you created the new transport rule successfully by
running the following command (the example below verifies the rule created in the Exchange Management
Shell example above):

Get-TransportRule "Mark messages from the Internet to Sales DG"

View or modify a transport rule

NOTE
After you create or modify a transport rule, it can take up to 30 minutes for the new or updated rule to be applied to email.

Use the EAC to view or modify a transport rule

1. From the EAC, go to Mail flow > Rules.
2. When you select a rule in the list, the conditions, actions, exceptions and select properties of that rule are
displayed in the details pane. To view all the properties of a specific rule, double click it. This opens the rule
editor window, where you can make changes to the rule. For more information about rule properties, see
Use the EAC to create a transport rule section, earlier in this topic.
Use the Exchange Management Shell to view or modify a transport rule
The following example gives you a list of all rules configured in your organization:

Get-TransportRule

To view the properties of a specific transport rule, you provide the name of that rule or its GUID. It is usually
helpful to send the output to the Format-List cmdlet to format the properties. The following example returns all
the properties of the transport rule named Sender is a member of Marketing:
 Get-TransportRule "Sender is a member of marketing" | Format-List

To modify the properties of an existing rule, use the Set-TransportRule cmdlet. This cmdlet allows you to change
any property, condition, action or exception associated with a rule. The following example adds an exception to the
rule "Sender is a member of marketing" so that it won't apply to messages sent by the user Kelly Rollin:

Set-TransportRule "Sender is a member of marketing" -ExceptIfFrom "Kelly Rollin"

How do you know this worked?

To verify that you have successfully modified a transport rule, do the following:
From the rules list in the EAC, click the rule you modified in the Rules list and view the details pane.
From the Exchange Management Shell, verify that you modified the transport rule successfully by running
the following command to list the properties you modified along with the name of the rule (the example
below verifies the rule modified in the Exchange Management Shell example above):

Get-TransportRule "Sender is a member of marketing" | Format-List Name,ExceptIfFrom

Transport rule properties

You can also use the Set-TransportRule cmdlet to modify existing transport rules in your organization. Below is a
list properties not available in the EAC that you can change. For more information on using the Set-
TransportRule cmdlet to make these changes see Set-TransportRule

CONDITION NAME IN
EXCHANGE MANAGEMENT
CONDITION NAME IN THE EAC SHELL PROPERTIES DESCRIPTION

Stop Processing Rules StopRuleProcessing Not applicable Enables you to stop

processing additional rules

Header/Envelope SenderAddressLocation Not applicable Enables you to examine the

matching SMTP message envelope to
ensure the header and
envelop match

**Audit severity ** SetAuditSeverity Not applicable Enables you to select a

severity level for the audit

Rule modes Mode Not applicable Enables you to set the mode
for the rule

Set the priority of a transport rule

The rule at the top of the list is processed first. This rule has a Priority of 0.
Use the EAC to set the priority of a rule
1. From the EAC, go to Mail flow > Rules. This displays the rules in the order in which they are processed.
2. Select a rule, and use the arrows to move the rule up or down the list.
Use the Exchange Management Shell to set the priority of a rule
The following example sets the priority of "Sender is a member of marketing" to 2:

Set-TransportRule "Sender is a member of marketing" priority "2"

How do you know this worked?

To verify that you have successfully modified a transport rule, do the following:
From the rules list in the EAC, look at the order of the rules.
From the Exchange Management Shell, verify the priority of the rules (the example below verifies the rule
modified in the Exchange Management Shell example above):

Get-TransportRule * | Format-List Name,Priority

Enable or disable a transport rule

Rules are enabled when you create them. You can disable a transport rule.
Use the EAC to enable or disable a transport rule
1. From the EAC, go to Mail flow > Rules.
2. To disable a rule, clear the check box next to its name.
3. To enable a disabled rule, select the check box next to its name.
Use the Exchange Management Shell to enable or disable a transport rule
The following example disables the transport rule "Sender is a member of marketing":

Disable-TransportRule "Sender is a member of marketing"

The following example enables the transport rule "Sender is a member of marketing":

Enable-TransportRule "Sender is a member of marketing"

How do you know this worked?

To verify that you have successfully enabled or disabled a transport rule, do the following:
From the EAC, view the list of rules in the Rules list and check the status of the check box in the ON
column.
From the Exchange Management Shell, run the following command which will return a list of all rules in
your organization along with their status:

Get-TransportRule | Format-Table Name,State

Remove a transport rule

Use the EAC to remove a transport rule
1. From the EAC, go to Mail flow > Rules.
2. Select the rule you want to remove and then click Delete .
Use the Exchange Management Shell to remove a transport rule
The following example removes the transport rule "Sender is a member of marketing":

Remove-TransportRule "Sender is a member of marketing"

How do you know this worked?

To verify that you have successfully removed the transport rule, do the following:
From the EAC, view the rules in the Rules list and verify that the rule you removed is no longer shown.
From the Exchange Management Shell, run the following command and verify that the rule you remove is
no longer listed:

Get-TransportRule

Import or export a transport rule collection

You must use the Exchange Management Shell to import or export a transport rule collection. For information
about how to import a transport rule collection from an XML file, see Import-TransportRuleCollection. For
information about how to export a transport rule collection to an XML file, see Export-TransportRuleCollection.

Need more help?

Transport Rules
Transport Rule Conditions
Transport Rule Actions
 Test a transport rule in Exchange 2013
5/30/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Each time you create a transport rule, you should test it before turning it on. This way, if you accidentally create a
condition that doesn't do exactly what you want or interacts with other rules in unexpected ways, you won't have
any unintended consequences.

IMPORTANT
Wait 30 minutes after creating a rule before you test it. If you test immediately after you create the rule, you may get
inconsistent behavior. If you're using Exchange Server and have multiple Exchange servers, it may take even longer for all the
servers to receive the rule.

Step 1: Create a rule in test mode

You can evaluate the conditions for a rule without taking any actions that impact mail flow by choosing a test
mode. You can set up a rule so that you get an email notification any time the rule is matched, or you can look at
the message trace for messages that might match the rule. There are two test modes:
Test without Policy Tips: Use this mode together with an incident report action, and you can receive an
email message each time an email matches the rule.
Test with Policy Tips: This mode is only available if you're using Data loss prevention (DLP ). With this
mode, a message is set to the sender when a message they are sending matches a policy, but no mail flow
actions are taken.
Here's what you'll see when a rule is matched if you include the incident report action:

Use a test mode with an incident report action

1. In the Exchange admin center (EAC ), go to Mail flow > Rules.
2. Create a new rule, or select an existing rule, and then select Edit.
3. Scroll down to the Choose a mode for this rule section, and then select Test without Policy Tips or Test
with Policy Tips.
4. Add an incident report action:
a. Select Add action, or, if this isn't visible, select More options, and then select Add action.
 b. Select Generate incident report and send it to.
c. Click Select one... and select yourself or someone else.
d. Select Include message properties, and then select any message properties that you want included
in the email you receive. If you don't select any, you will still get an email when the rule is matched.
e. Select Save.

Step 2: Evaluate whether your rule does what you intend

To test a rule, you can either send enough test messages to confirm that what you expect happens, or look at the
message trace for messages that people in your organization send. Be sure to evaluate the following types of
messages:
Messages that you expect to match the rule
Messages that you don't expect to match the rule
Messages sent to and from people in your organization
Messages sent to and from people outside your organization
Replies to messages that match the rule
Messages that might cause interactions between multiple rules
Tips for sending test messages
One way to test is to sign in as both the sender and recipient of a test message.
Because a web browser typically doesn't let you have simultaneous open sessions on the same computer signed in
to multiple accounts, you can use Internet Explorer InPrivate Browsing, or a different computer, device, or web
browser for each user.
Look at the message trace
The message trace includes an entry for each rule that is matched for the message, and an entry for each action
the rule takes. This is useful for tracking what happens to test messages, and also for tracking what happens to real
messages going through your organization.

1. In the EAC, go to Mail flow > Message trace.

2. Find the messages that you want to trace by using criteria such as the sender and the date sent. For help
specifying criteria, see Run a Message Trace and View Results.
3. After locating the message you want to trace, double-click it to view details about the message.
4. Look in the Event column for Transport rule. The Action column shows the specific action taken.
Step 3: When you're done testing, set the rule to enforce
1. In the EAC, go to Mail flow > Rules.
2. Select a rule, and then select Edit.
3. Select Enforce.
4. If you used an action to generate an incident report, select the action and then select Remove.
5. Select Save.

TIP
To avoid surprises, inform your users about new rules.

Troubleshooting suggestions
Here are some common problems and resolutions:
Everything looks right, but the rule isn't working:
Occasionally it takes longer than 15 minutes for a new mail flow to be available. Wait a few hours, and then
test again. Also check to see if another rule might be interfering. Try changing this rule to priority 0 by
moving it to the top of the list.
Disclaimer is added to original message and all replies, instead of just the original message:
To avoid this, you can add an exception to your disclaimer rule to look for a unique phrase in the disclaimer.
My rule has two conditions, and I want the action to happen when either of the conditions is met,
but it only is matched when both conditions are met:
You need to create two rules, one for each condition. You can easily copy the rule by selecting Copy and
then remove one condition from the original and the other condition from the copy.
I'm working with distribution groups, and 'The sender is' (SentTo) doesn't seem to be working:
SentTo matches messages where one of the recipients is a mailbox, mail-enabled user, or contact, but you
can't specify a distribution group with this condition. Instead, use To box contains a member of this
group (SentToMemberOf).

Need more help?

Manage transport rules in Exchange 2013
Transport Rules
 Use transport rules to route email based on a list of
words, phrases, or patterns in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

To help your users comply with your organization's email policies, you can use Exchange transport rules to
determine how email containing specific words or patterns is routed. For a short list of words or phrases, you can
use the Exchange admin center. For a longer list, you might want to use the Exchange Module for Windows
PowerShell to read the list from a text file.
If your organization uses Data Loss Prevention (DLP ), see Data loss prevention for additional options for
identifying and routing email that contains sensitive information.

Example 1: Use a short list of unacceptable words

If your list of words or phrases is short, you can create a rule using the Exchange admin center. For example, if you
want to make sure no one sends email with bad words or with misspellings of your company name, internal
acronyms or product names, you could create a rule to block the message and tell the sender. Note that words,
phrases, and patterns are not case sensitive.
This example blocks messages with common typos.

Example 2: Use a long list of unacceptable words

If your list of words, phrases, or patterns is long, you can put them in a text file with each word, phrase, or pattern
on its own line. Use the Exchange Module for Windows PowerShell to read in the list of keywords into a variable,
create a transport rule, and assign the variable with the keywords to the transport rule condition. For example, the
following script takes a list of misspellings from a file called misspelled_companyname.txt.
 $keywords=Import-Content .\misspelled_companyname.txt
New-TransportRule -Name "Block messages with unacceptable words" -SubjectOrBodyContainsWords $keywords -
SentToScope "NotInOrganization" -RejectMessageReasonText "Do not use internal acronyms, product names, or
misspellings in external communications."

Using phrases and patterns in the text file

The text file can contain regular expressions for patterns. These expressions are not case-sensitive. Common
regular expressions include:

Expression Matches

. Any single character

* Any additional characters

\d Any decimal digit

[character_group ] Any single character in character_group.

For example, this text file contains common misspellings of Microsoft.

[mn]sft
[mn]icrosft
[mn]icro soft
[mn].crosoft

To learn how to specify patterns using regular expressions, see Regular Expression Reference.
 Register Filter Pack IFilters with Exchange 2013
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Transport rules with attachment scanning conditions perform text extraction when analyzing the content of
attachments. Exchange 2013 can scan most commonly used attachment types natively. Additional attachment
types can be included by registering IFilters with Exchange 2013. This topic shows you how to register IFilters
released by Microsoft and third-party providers.
After you register an IFilter for a specific file type, transport rules with attachment processing conditions will be
able to scan these attachments. As a result, these file types will no longer trigger the AttachmentIsUnsupported
condition.

WARNING
The procedures listed in this topic involve modifying the registry on your Exchange servers. Incorrectly editing the registry
can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the
registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.
These procedures also require you to stop and restart the Microsoft Exchange Transport service on your Mailbox servers.

For additional management tasks related to Transport rules, see Manage transport rules in Exchange 2013.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes per server.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Exchange server configuration settings" entry in the Exchange and Shell
infrastructure permissions topic.
You must perform the procedures below on servers that already have Exchange 2013 Mailbox server role
installed. If you add additional Mailbox servers after you perform these procedures, you must perform
them again on the newly provisioned servers.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Register the Microsoft Office 2010 Filter Pack

By default, the following Office file types aren't supported by Exchange transport rules:
Office OneNote
Office Publisher
If you want to support these files, you must deploy the Microsoft Office 2010 Filter Pack. This Filter Pack isn't
deployed during Exchange 2013 Setup and isn't a prerequisite for deployment.
Deploy the Microsoft Office 2010 Filter Pack
Deploying the Office 2010 Filter Pack consists of two main steps:
Downloading and installing the Filter Pack, which registers the IFilters with Windows (Search).
Modifying the registry so the IFilters are also registered with Exchange 2013. This allows Exchange to
support attachment scanning for the file formats.

IMPORTANT
You must perform this procedure on all Mailbox servers in your organization.

1. Download and save the Microsoft Office 2010 Filter Pack ( FilterPack64bit.exe ) from the Microsoft
Download Center.
2. Run the FilterPack64bit.exe file on your Mailbox server and follow the instructions to complete the
installation.
3. Start Registry Editor and locate the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\CLSID

4. Under CLSID, add a subkey for OneNote files as follows:

a. Right-click CLSID, point to New, and then click Key.
b. Change the name of the new key to {B8D12492-CE0F-40AD-83EA-099A03D493F1} .
c. Click the key you just created and set the (Default) value to where you installed the Office 2010
Filter Pack. By default, the filter pack gets installed at
C:\Program Files\Common Files\Microsoft Shared\Filters\ONIFilter.dll .

d. Right click {B8D12492-CE0F-40AD -83EA -099A03D493F1}, point to New, and then click String
Value.
e. Name the new string value ThreadingModel and set it to Both .
5. Under CLSID, add a subkey for Publisher files as follows:
a. Right-click CLSID, point to New, and then click Key.
b. Change the name of the new key to {A7FD8AC9-7ABF-46FC-B70B-6A5E5EC9859A} .
c. Click the key you just created and set the (Default) value to where you installed the Office 2010
Filter Pack. By default, the filter pack gets installed at
C:\Program Files\Common Files\Microsoft Shared\Filters\PUBFILT.dll .

d. Right-click {A7FD8AC9-7ABF-46FC -B70B -6A5E5EC9859A }, point to New, and then click String
Value.
e. Name the new string value ThreadingModel and set it to Both .
6. Locate the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\filters

7. Under filters, add a subkey for .one extensions as follows.

 a. Right-click filters, point to New, and then click Key.
b. Change the name of the new key to .one .
c. Click the key you just created and set the (Default) value to
{B8D12492-CE0F-40AD-83EA-099A03D493F1} .

8. Under filters, add a subkey for .pub extensions as follows:

a. Right-click filters, point to New and then click Key.
b. Change the name of the new key to .pub .
c. Click the key you just created and set the (Default) value to
{A7FD8AC9-7ABF-46FC-B70B-6A5E5EC9859A} .

9. Close Registry Editor.

10. On your Mailbox server, stop and then restart the following services in the specified order:
a. Stop the Microsoft Exchange Transport service.
b. Stop the Microsoft Filtering Management Service.
c. Start the Microsoft Filtering Management Service.
d. Start the Microsoft Exchange Transport service.

How do you know this worked?

To verify that you have successfully registered the Microsoft Office 2010 Filter Pack IFilters, do the following:
1. Create a Transport rule with the following properties. For detailed instructions about how to create
Transport rules, see Manage transport rules in Exchange 2013.
The sender is your mailbox.
Any attachment's content includes "Testing IFilters".
Generate an incident report and send it to your mailbox.
2. Create a OneNote file that contains the phrase "Testing IFilters", attach it to a new email message, and send
it to yourself.
3. Verify that you receive a Transport rule incident report for the rule you just created. This confirms that the
rules engine was able to analyze the contents of the OneNote file.
4. Repeat Steps 2 and 3 with a Publisher file.

Register third-party IFilters to support additional file formats

You can extend the attachment scanning capability for additional file types by registering additional third-party
IFilters. Support for additional files can be added by installing and registering the file type's IFilter on each of your
Mailbox servers.

IMPORTANT
Microsoft hasn't tested third-party IFilters with transport rules, therefore we recommend that you deploy and test any
third-party IFilters in a test environment before deploying into your production environment.
Deploy the Adobe PDF IFilter
This procedure shows how to deploy the Adobe PDF IFilter to support processing of PDF attachments in
transport rules.

NOTE
By default, Exchange 2013 supports the scanning of PDF files in transport rules. The PDF example here is used simply to
illustrate how you can extend support for additional file types using third-party IFilters.

1. Download the Adobe PDF IFilterand then follow the installation instructions.
2. Start Registry Editor and locate the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\CLSID

3. Under CLSID, add a subkey for PDF files as follows:

a. Right-click CLSID, point to New, and then click Key.
b. Change the name of the new key to {E8978DA6-047F-4E3D-9C78-CDBE46041603} .

NOTE
Each IFilter has a unique class ID (CLSID). You can find the CLSID in the installation documentation for the
IFilter you're registering or by searching for the file extension under the HKEY_CLASSES_ROOT\CLSID key in
the registry.

c. Click the key you just created and set the (Default) value to where you installed the PDF IFilter. By
default, the PDF IFilter is installed at
C:\Program Files\Adobe\Adobe PDF IFilter 9 for 64-bit platforms\bin\PDFFilter.dll .

4. Locate the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\filters

5. Under filters, add a subkey for .pdf extensions as follows:

a. Right-click filters, point to New, and then click Key.
b. Change the name of the new key to .pdf .
c. Click the key you just created and set the (Default) value to
{E8978DA6-047F-4E3D-9C78-CDBE46041603} .

6. Close Registry Editor.

7. On your Mailbox server, stop and restart the following services in the specified order:
a. Stop the Microsoft Exchange Transport service.
b. Stop the Microsoft Filtering Management Service.
c. Start the Microsoft Filtering Management Service.
d. Start the Microsoft Exchange Transport service.
How do you know this worked?
Use the same procedure listed in the How do you know this worked? section earlier in this topic, substituting
Publisher files with Adobe PDF files.

For more information

Use transport rules to inspect message attachments
Mail flow or transport rules
Transport rule conditions (predicates)
Transport rule actions
 Manage message approval in Exchange 2013
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sometimes it makes sense to have a second set of eyes on a message before the message is delivered. As an
Exchange administrator, you can set this up. This process is called moderation, and the approver is called the
moderator. Depending on which messages need approval, you can use one of two approaches:
Change the distribution group properties
Create a transport rule
This article explains:
How to decide which approval approach to use
How the approval process works
To learn how to implement common scenarios, see Common message approval scenarios.

How to decide which approval approach to use

Here's a comparison of the two approaches to message approval.

WHAT DO YOU WANT TO DO? APPROACH FIRST STEP

Create a moderated distribution group Set up message approval for the Go to the Exchange admin center (EAC)
where all messages to the group must distribution group. > Recipients> Groups, edit the
be approved. distribution group, and then select
Message approval.

Require approval for messages that Create a transport rule using the Go to the EAC > Mail flow > Rules.
match specific criteria or that are sent Forward the message for approval
to a specific person. action.
You can specify message criteria,
including text patterns, senders, and
recipients. Your criteria can also contain
exceptions.

How the approval process works

When someone sends a message to a person or group that requires approval, if they're using Outlook Web App,
they're notified that their message might be delayed.
The moderator receives an email with a request to approve or reject the message. The text of the message includes
buttons to approve or reject the message, and the attachment includes the original message to review.

The moderator can take one of three actions:

1. If approved, the message goes to the original intended recipients. The original sender isn't notified.
2. If rejected, a rejection message is sent to the sender. The moderator can add an explanation:

3. If the approver either deletes or ignores the approval message, an expiration message is sent to the sender.
This happens after five days in Exchange Server 2013. (you can change this time period).
The message that's waiting for approval gets temporarily stored in a system mailbox called the arbitration mailbox.
Until the moderator decides to approve or reject the message, deletes the approval message, or lets the approval
message expire, the original message is kept in the arbitration mailbox.

Questions and answers

What's the difference between the approver and owner of a distribution group?
The owner of a distribution group is responsible for managing the distribution group membership, but he or she
might not be able to moderate messages sent to it. For example, a person in IT might be the owner of a distribution
group called All Employees, but only the Human Resources manager might be set up as the moderator.
What happens when the moderator or approver sends a message to the distribution group?
The message goes directly to the group, bypassing the approval process.
What happens when only a subset of recipients needs approval?
You can send a message to a group of recipients where only a subset of the recipients requires approval. Consider
a message that's sent to 12 recipients, one of which is a moderated distribution group. The message is
automatically split into two copies. One message is delivered immediately to the 11 recipients that don't require
approval, and the second message is submitted to the approval process for the moderated distribution group. If a
message is intended for more than one moderated recipient, a separate copy of the message is automatically
created for each moderated recipient and each copy goes through the appropriate approval process.
What if my distribution group contains moderated recipients that require approval?
A distribution group can include moderated recipients that also require approval. In this case, after the message to
the distribution group is approved, a separate approval process occurs for each moderated recipient that's a
member of the distribution group. However, you can also enable the automatic approval of the distribution group
members after the message to the moderated distribution group is approved. To do this, you use the
BypassNestedModerationEnabled parameter on the Set-DistributionGroup cmdlet.
Is this process different if we have our own Exchange servers?
By default, one arbitration mailbox is used for each Exchange organization. If you have your own Exchange servers
and need more arbitration mailboxes for load balancing, follow the instructions for adding arbitration mailboxes in
Manage and troubleshoot message approval. Arbitration mailboxes are system mailboxes and don't require an
Exchange license.

Need more info?

Manage transport rules in Exchange 2013
Exchange Management Shell Quick Reference for Exchange 2013
 Common message approval scenarios in Exchange
2013
5/30/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Your organization may require certain types of messages be approved in order to meet legal or compliance
requirements, or to implement a specific business workflow. This article discusses examples of common scenarios
that you can set up by using Exchange.

Example 1: Avoid mail storms to a large distribution group

To control messages to a large distribution group, you can require that a moderator approve messages that are
sent to that group. If there are no criteria for which messages require approval, the simplest way to set this up is to
configure the group to require message approval.
In this example, all messages to the All Employees group must be approved, except if the senders are members of
the distribution group named Legal Team.

To require that messages to a specific distribution group be approved, in the Exchange admin center (EAC ), go to
Recipients > Groups, edit the distribution group, and then select Message approval.

Example 2: Forward messages to a sender's manager for approval

Here are some common types of messages for which you might want to require manager approval:
Messages sent from a user to certain distribution groups or recipients
Messages sent to external users or partners
Message sent between two groups
 Messages sent with specific content, such as the name of a specific customer
Messages sent by a trainee
To require that a message be sent for approval, first, create a rule using the Send messages to a moderator
template, and select that the messages should go to the sender's manager, as shown in the following screenshots.

Then, define which messages need approval.

Here's an example where all messages sent out by a trainee, Garth Fort, to recipients outside the organization
requires a manager's approval.

To get started, go to EAC > Mail flow > Rules, and create a new rule using the Send messages to a moderator
template.

IMPORTANT
Some conditions and actions, including forwarding to the sender's manager, are hidden by default in the New rule page. To
see all the conditions and actions, select More options.

Example 3: Set up a message approval chain

You can require multiple levels of approval for messages. For example, you can require that messages to a specific
customer be approved first by a customer relationship manager and then by a compliance officer, or you can
require that expense reports be approved by two levels of managers.
To create this type of multiple-level approval, create one transport rule for each level of approval. Each rule detects
the same patterns in the messages, as follows:
The first rule forwards the message to the first approver. When the first approver accepts the message, the
message automatically goes to the approver in the second rule.
If all approvers in the chain select Approve when they receive the approval request, when the last approval
in the chain is complete, the original message is sent to the intended recipients.
If anyone in the approval chain selects Reject when they receive the approval request, the sender receives a
rejection message.
If any of the approval requests aren't approved within the expiration time (5 days for Exchange Server
2013), the sender receives an expiration message.
The following example assumes that you have a customer called Blue Yonder Airlines, and you want both the
customer relationship manager and the compliance officer to approve all messages that go to this customer. You
create two rules, one for each approver. The first rule goes to the first-level approver. The second rule goes to the
second-level approver.

The first rule identifies all messages with the company name Blue Yonder Airlines in the subject or message, and it
sends these messages to the internal customer relationship manager for Blue Yonder Airlines, Garret Vargas.

The second rule sends these messages to the compliance officer, Tony Krijnen.
Example 4: Forward messages that match one of several criteria
Within a transport rule, all conditions configured within the rule must be true for the rule to match. If you want the
same actions applied for either condition, you should create a separate rule for each one.
To do this, on the Rules page in EAC, create a rule for the first condition. Then select the rule, select Copy, and
change the conditions in the new rule to match the second condition.
Be careful when you create multiple rules with "OR" conditions so you don't end up with a message being sent
multiple times to the approver. To avoid this, add an exception to the second rule so it ignores messages that
matched the first rule.
For example, a single rule can't check whether a message has "sales quote" in either the subject or in the
attachment title. To avoid the message being sent multiple times to the approver, if the first rule checks for "sales
quote" in the subject or body of the message, the second rule that checks for "sales quote" in attachment content
needs an exception that contains the first rule's criteria.

NOTE
Exceptions are hidden by default in the New rule page. To see all the conditions and actions, select More options.
Example 5: Forward a message that contains sensitive information
If you have the Data loss prevention(DLP ) feature, many types of sensitive information are predefined. With DLP,
you see that the message contains a sensitive information condition. Whether or not you have DLP, you can create
conditions that identify specific sensitive information patterns that are unique to your organization.
Here's an example where messages with sensitive information require approval. In this example, messages that
contain a credit card number require approval.

See also
Manage message approval
 Manage and troubleshoot message approval in
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You may receive the following error when you attempt to remove an arbitration mailbox:
Can't remove the arbitration mailbox < mailbox> because it's being used for the approval workflow for existing
recipients that have either membership restrictions or moderation enabled. You should either disable the
approval features on those recipients or specify a different arbitration mailbox for those recipients before
removing this arbitration mailbox.

An arbitration mailbox can be used to handle the approval workflow for moderated recipients and distribution
group membership approvals. You use PowerShell to find all the recipients that are configured to use the
arbitration mailbox. After you identify the recipients, you can either configure them to use a different arbitration
mailbox, or you can disable moderation for them.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Aribtration" entry in the Recipients permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

Step 1: Use the Shell to find all the recipients that use the arbitration
mailbox you are trying to delete
Run the following commands:

$AM = Get-Mailbox "<arbitration mailbox>" -Arbitration

$AMDN = $AM.DistinguishedName
Get-Recipient -RecipientPreviewFilter {ArbitrationMailbox -eq $AMDN}

For example, to find all the recipients that use the arbitration mailbox named Arbitration Mailbox01, run the
following commands:

$AM = Get-Mailbox "Arbitration Mailbox01" -Arbitration

$AMDN = $AM.DistinguishedName
Get-Recipient -RecipientPreviewFilter {ArbitrationMailbox -eq $AMDN}

NOTE
The arbitration mailbox is specified using the distinguished name (DN). If you know the DN of the arbitration mailbox, you
can run the single command: Get-Recipient -RecipientPreviewFilter {ArbitrationMailbox -eq <DN>} .
Step 2: Use the Shell to specify a different arbitration mailbox or
disable moderation for the recipients
To stop moderated recipients from using the arbitration mailbox you are trying to delete, you can either specify a
different arbitration mailbox, or you can disable moderation for the recipients.
If you choose to specify a different arbitration mailbox for the recipients, run the following command:

Set-<RecipientType> <Identity> -ArbitrationMailbox <different arbitration mailbox>

For example, to reconfigure the distribution group named All Employees to use the arbitration mailbox named
Arbitration Mailbox02 for membership approval, run the following command:

Set-DistributionGroup "All Employees" -ArbitrationMailbox "Arbitration Mailbox02"

If you choose to disable moderation for the recipients, run the following command:

Set-<RecipientType> <Identity> -ModerationEanbled $false

For example, to disable moderation for the mailbox named Human Resources, run the following command:

Set-Mailbox "Human Resources" -ModerationEanbled $false

How do you know this worked?

The procedure was successful if you can delete the arbitration mailbox without receiving the error that it's being
used.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
 Data loss prevention in Exchange 2013
6/14/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

Learn about DLP policies in Exchange Server 2013, including what they contain and how to test them. You'll
also learn about a new feature in Exchange DLP.
Data loss prevention (DLP ) is an important issue for enterprise message systems because of the extensive use
of email for business critical communication that includes sensitive data. In order to enforce compliance
requirements for such data, and manage its use in email, without hindering the productivity of workers, DLP
features make managing sensitive data easier than ever before. For a conceptual overview of DLP, watch the
following video.
DLP Overview
DLP policies are simple packages that contain sets of conditions, which are made up of transport rules, actions,
and exceptions that you create in the Exchange admin center (EAC ) and then activate to filter email messages
and attachments. You can create a DLP policy, but choose to not activate it. This allows you to test your policies
without affecting mail flow. DLP policies can use the full power of existing transport rules. In fact, a number of
new types of transport rules have been created in Microsoft Exchange Server 2013 in order to accomplish new
DLP capability.
One important new feature of transport rules is a new approach to classifying sensitive information that can be
incorporated into mail flow processing. This new DLP feature performs deep content analysis through keyword
matches, dictionary matches, regular expression evaluation, and other content examination to detect content
that violates organizational DLP policies. Exchange 2013 Service Pack 1 (SP1) adds Document Fingerprinting,
which helps you detect sensitive information in standard forms. For more information about transport rules, see
Transport rules in Exchange 2013, and Integrating sensitive information rules with transport rules. You can also
manage your DLP policies by using Exchange Management Shell cmdlets. For more information about policy
and compliance cmdlets, see Messaging policy and compliance.
In addition to the customizable DLP policies themselves, you can also inform email senders that they may be
about to violate one of your policies, even before they send an offending message. You can accomplish this by
configuring Policy Tips. Policy Tips are similar to MailTips, and can be configured to present a brief note in
Outlook 2013 or later that provides information about possible policy violations to a person creating a message.
In Exchange 2013 SP1, Policy Tips are also displayed in Outlook Web App and OWA for Devices. For more
information, see Policy Tips.

NOTE
DLP is a premium feature that requires an Exchange Enterprise Client Access License (CAL). For more information about
CALs and server licensing, see Exchange Server Licensing.

Exchange Enterprise CAL with Services: There is a behavior distinction to take note of if you are an Exchange Enterprise
CAL with Services customer with a hybrid deployment, where you have some mailboxes located on premises and some in
Exchange Online. DLP policies are applied in Exchange Online. Therefore, messages sent from one on-premises user to
another on-premises user do not have DLP policies applied, because the message doesn't leave the on-premises
infrastructure.

Looking for management tasks related to Data Loss Prevention? See DLP procedures.
Establish policies to protect sensitive data
The data loss prevention features can help you identify and monitor many categories of sensitive information
that you have defined within the conditions of your policies, such as private identification numbers or credit card
numbers. You have the option of defining your own custom policies and transport rules or using the pre-defined
DLP policy templates provided by Microsoft in order to get started quickly. For more information about the
policy templates that are included, see DLP policy templates supplied in Exchange 2013. A policy template
includes a range of conditions, rules, and actions that you can choose from in order to create and save an actual
DLP policy that will help you inspect messages. The policy templates are models from which you can select or
build your own specific rules to create a policy that meets your needs for data loss prevention.
Three different methods exist for you to begin using DLP:
1. Apply an out-of-the-box template supplied by Microsoft: The quickest way to start using DLP
policies is to create and implement a new policy using a template. This saves you the effort of building a
new set of rules from nothing. You will need to know what type of data you want to check for or which
compliance regulation you are attempting to address. You will also need to know your organizations
expectations for processing such data. More information at DLP policy templates supplied in Exchange
2013 and Create a DLP policy from a template.
2. Import a pre-built policy file from outside your organization: You can import policies that have
already been created outside of your messaging environment by independent software vendors. In this
way you can extend the DLP solutions to suit your business requirements. More information at Policy
templates from Microsoft partners, Define your own DLP templates and information types, and Import a
custom DLP policy template from a file.
3. Create a custom policy without any pre-existing conditions: Your enterprise may have its own
requirements for monitoring certain types of data known to exist within a messaging system. You can
create a custom policy entirely on your own in order to start checking and acting upon your own unique
message data. You will need to know the requirements and constraints of the environment in which the
DLP policy will be enforced in order to create such a custom policy. More information at Create a custom
DLP policy.
After you have added a policy, you can review and change its rules, make the policy inactive, or remove it
completely. The procedures for these actions are provided in the Manage DLP policies topic.

Sensitive information types in DLP policies

When you create or change DLP policies, you can include rules that include checks for sensitive information. The
sensitive information types listed in the Sensitive Information Types Inventory topic are available to be used in
your policies. The conditions that you establish within a policy, such as how many times something has to be
found before an action is taken or exactly what that action is can be customized within your new custom policies
in order to meet your specific policy requirements. For more information about creating DLP policies see,
Create a custom DLP policy. For more information about the full suite transport rules, see Transport rules in
Exchange 2013.
To make it easy for you to make use of the sensitive information-related rules, Microsoft has supplied policy
templates that already include some of the sensitive information types. You cannot add conditions for all of the
sensitive information types listed here to policy templates however, because the templates are designed to help
you focus on the most-common types of compliance-related data within your organization. For more
information about the pre-built templates, see DLP policy templates supplied in Exchange 2013. You can create
numerous DLP policies for your organization and have them all enabled so that many disparate types of
information are examined. You can also create a DLP policy that is not based on an existing template. To begin
creating such a policy, see Create a custom DLP policy. For more information about sensitive information types,
see Sensitive Information Types Inventory.
Detecting sensitive form data with Document Fingerprinting
With Exchange 2013 SP1, you can use Document Fingerprinting to easily create a sensitive information type
based on a standard form. To learn how to protect form data, see Protect form data with document
fingerprinting.

Policy Tips notify users about sensitive content expectations

You can use Policy Tip notification messages to inform email senders about possible compliance issues while
they are composing an email message. When you configure a Policy Tip in a DLP policy, the notification
message will only show up if something in the sender's email message meets the conditions described in your
policy. Policy Tips are similar to MailTips that were introduced in Microsoft Exchange 2010. For more
information, see Policy Tips.

Detecting sensitive information along with traditional message

classification
Exchange 2013 presents a new method of helping you manage message and attachment data when compared
with traditional message classification. A key factor in the strength of a DLP solution is the ability to correctly
identify confidential or sensitive content that may be unique to the organization, regulatory needs, geography, or
other business needs. Exchange 2013 can achieve this by using a new architecture for deep content analysis
coupled with detection criteria that you establish through rules in your DLP policies. Helping prevent data loss
in Exchange 2013 relies on configuring the correct set of sensitive information rules so that they provide a high
degree of protection while minimizing inappropriate mail flow disruption with false positives and negatives.
These types of rules, referred to throughout the DLP information as sensitive information detection, function
within the framework offered by transport rules in order to enable DLP capabilities.
To learn more about these new features, see Integrating sensitive information rules with transport rules. The
traditional message classification fields can still be applied to messages in Exchange and these can be combined
with the new sensitive information detection either together within a single DLP policy or running concurrently
so they are evaluated independently within Exchange. To learn more about the legacy Exchange 2010 message
classifications, see Understanding Message Classifications.

Information about DLP-processed messages

For Exchange 2013 to obtain information about messages and DLP policy detections in your environment, see
DLP policy detection reports and Create incident reports for DLP policy detections. Data related to DLP
detections, is highly integrated into the delivery reports message tracking tool of Exchange 2013.

Installation prerequisites
In order to make use of DLP features, you must have Exchange 2013 configured with at least one sender
mailbox. Data Loss Prevention is a premium feature that requires an Enterprise Client Access License (CAL ). For
more information about getting started with Exchange Server, see Planning and Deployment.

For more information

Messaging Policy and Compliance
DLP Procedures
DLP policy detection reports
Document Fingerprinting
Messaging Policy and Compliance Cmdlets
 How DLP rules are applied to evaluate messages in
Exchange 2013
5/30/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can set up sensitive information rules within your Microsoft Exchange data loss prevention (DLP ) policies to
detect very specific data in email messages. This topic will help you understand how these rules are applied and
how messages are evaluated. You can avoid workflow disruptions for your email users and achieve a high degree
of accuracy with your DLP detections if you know how your rules are enforced. Let's use the Microsoft-supplied
credit card information rule as an example. When you activate a transport rule or DLP policy, the Exchange
transport rules agent compares all messages that your users send with the rule sets that you create.

Get precise about your needs

Suppose you need to act on credit card information in messages. The actions you take once it is found are not the
subject of this topic, but you can learn more about that in Transport Rule Actions. With as most certainty as
possible, you need to ensure that what is detected in a message is truly credit card data and not something else
that could be a legitimate use of groups of numbers that merely resemble credit card data; for example, a
reservation code or a vehicle identification number. To meet this need, let's make it clear that the following
information should be classified as a credit card.

Margie's Travel,

I have received updated credit card information for Spencer.

Spencer Badillo
Visa: 4111 1111 1111 1111
Expires: 2/2012

Please update his travel profile. **

Let's also make it clear that the following information should not be classified as a credit card.

Hi Alex,

I expect to be in Hawaii too. My booking code is 1234 1234 1234 1234 and I'll be there on 3/2012.

Regards, Lisa

The following XML snippet shows how the needs expressed earlier are currently defined in a sensitive information
rule that is provided with Exchange and it is embedded within one of the supplied DLP policy templates.
 <Entity id="50842eb7-edc8-4019-85dd-5a5c1f2bb085" patternsProximity="300" recommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="Func_credit_card" />
<Any minMatches="1">
<Match idRef="Keyword_cc_verification" />
<Match idRef="Keyword_cc_name" />
<Match idRef="Func_expiration_date" />
</Any>
</Pattern>
</Entity>

Pattern-matching in your solution

The XML rule definition shown earlier includes pattern-matching, which improves the likelihood that the rule will
detect only the important information and not detect vague, related information. For more information about the
XML schema for DLP rules and templates, see Define your own DLP templates and information types.
In the credit card rule, there is a section of XML code for patterns, which includes a primary identifier match and
some additional corroborative evidence. All three of these requirements are explained here:
1. <IdMatch idRef="Func_credit_card" /> : This requires a match of a function, titled credit card, that is internally
defined. This function includes a couple of validations as follows:
a. It matches a regular expression (in this instance for 16 digits) that could also include variations like a
space delimiter so that it also matches 4111 1111 1111 1111 or a hyphen delimiter so that it also
matches 4111-1111-1111-1111.
b. It evaluates the Lhun's checksum algorithm against the 16-digit number in order to ensure the
likelihood of this being a credit card number is high.
c. It requires a mandatory match, after which corroborative evidence is evaluated.
2. <Any minMatches="1"> : This section indicates that the presence of at least one of the following items of
evidence is required.
3. The corroborative evidence can be a match of one of these three:
<Match idRef="Keyword_cc_verification"/>

<Match idRef="Keyword_cc_name"/>

<Match idRef="Func_expiration_date"/>

These three simply mean a list of keywords for credit cards, the names of the credit cards, or an expiration
date is required. The expiration date is defined and evaluated internally as another function.

The process of evaluating content against rules

The five steps here represent actions that Exchange takes to compare your rule with email messages. For our credit
card rule example, the following steps are taken.

STEP ACTION

1. Get Content Spencer Badillo

Visa: 4111 1111 1111 1111
Expires: 2/2012

2. Regular Expression Analysis 4111 1111 1111 1111 -> a 16-digit number is detected
 STEP ACTION

3. Function Analysis 4111 1111 1111 1111 -> matches checksum

1234 1234 1234 1234 -> doesn't match

4. Additional Evidence

Keyword Visa is near the number. A regular expression for a

date (2/2012) is near the number.

5. Verdict

There is a regular expression that matches a checksum.

Additional evidence increases confidence.

The way this rule is set up by Microsoft makes it mandatory that corroborating evidence such as keywords are a
part of the email message content in order to match the rule. So the following email content would not be detected
as containing a credit card:

Margie's Travel,

I have received updated information for Spencer.

Spencer Badillo
4111 1111 1111 1111

Please update his travel profile.

You can use a custom rule that defines a pattern without extra evidence, as shown in the next example. This would
detect messages with only credit card number and no corroborating evidence.

<Pattern confidenceLevel="85">
<IdMatch idRef="Func_credit_card" />
</Pattern>
</Entity>

The illustration of credit cards in this article can be extended to other sensitive information rules as well. To see the
complete list of the Microsoft-supplied rules in Exchange, use the Get-ClassificationRuleCollection cmdlet in the
Exchange Management Shell in the following manner:

$rule_collection = Get-ClassificationRuleCollection

$rule_collection[0].SerializedClassificationRuleCollection | Set-Content oob_classifications.xml -Encoding byte

For more information

Data loss prevention
Transport Rules
Exchange Management Shell
 Integrating sensitive information rules with transport
rules in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange, you can create DLP policies that contain rules for not only traditional message
classifications and existing transport rules but also combine these with rules for sensitive information found within
messages. The existing transport rules framework offers rich capabilities to define messaging policies, covering
the entire spectrum of soft to hard controls. Examples include:
Limiting the interaction between recipients and senders, including interactions between departmental
groups inside an organization.
Applying separate policies for communications within and outside of an organization.
Preventing inappropriate content from entering or leaving an organization.
Filtering confidential information.
Tracking or archiving messages that are sent to or received from specific individuals.
Redirecting inbound and outbound messages for inspection before delivery.
Applying disclaimers to messages as they pass through the organization.
Transport rules allow you to apply messaging policies to email messages that flow through the transport pipeline
in the Transport service on Mailbox servers and on Edge Transport servers. These rules allow system
administrators to enforce messaging policies, help keep messages more secure, help to protect messaging
systems, and help prevent accidental information loss. For more information about transport rules, see Transport
protection rules.

Sensitive information rules within the transport rule framework

Sensitive information rules are integrated with the transport rules framework by introduction of a condition that
you can customize: If the message contains...Sensitive Information. This condition can be configured with one
or more sensitive information types that are contained within the messages. When multiple DLP policies or rules
within a policy are configured with this condition, the policy or rule is satisfied when any of the conditions match.
Exchange policy rules examine the subject, body and any attachments of a message. If the rule matches any of
these message components, the rule actions will be applied.
The sensitive information condition may be combined with any of the already existing transport rules to define
messaging policies. If combined, the condition works in conjunction with other rules and provides the AND
semantics. For example, two different conditions are added together with an AND statement such that both need
to match for the action to be applied. Any of the transport rule actions can be configured as result of rules
containing the sensitive information type matching. Many different file types can be scanned by the transport
rules agent, which scans messages to enforce transport rules. To learn more about the supported file types, see
[File Types That Are Supported In Transport Rules](http://technet.microsoft.com/library/c0de687e-e33c-4e8a-
b253-771494678795.aspx.
The rules can also be used in the exception part of a rule definition. Their use in the exception definition is
independent of their use as a condition within the rule. This provides the flexibility to define rules that have the
condition specifying multiple information types to be applied as part of the condition and also differing
information types in the condition. This would allow policies such as matching specific traditional message-
classification rules, but not matching other sensitive information types before performing actions that you define
within a policy.

For more information

Data loss prevention
Sensitive Information Types Inventory
Transport protection rules
Create a custom DLP policy
 What the sensitive information types in Exchange
look for
6/14/2019 • 67 minutes to read • Edit Online

Applies to: Exchange Server 2013

Data loss prevention (DLP ) includes sensitive information types that are ready for you to use in your DLP policies.
This topic lists all the sensitive information types (80 in Exchange Online, 51 in Exchange Server 2013), and shows
what a DLP policy looks for when it detects each type.
A sensitive information type is defined by a pattern that can be identified by a regular expression or a function.
Additionally, corroborative evidence such as keywords and checksums can be used to identify a sensitive
information type. Confidence level and proximity are also used in the evaluation process.

ABA Routing Number

Availability Exchange Online, Exchange Server 2013

Format Nine digits, which may be in a formatted or unformatted

pattern

Pattern Formatted:
Four digits beginning with 0, 1, 2, 3, 6, 7, or 8
A hyphen
Four digits
A hyphen
A digit
Unformatted:
Nine consecutive digits beginning with 0, 1, 2, 3, 6,
7, or 8

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_aba_routing finds content
that matches the pattern.
A keyword from Keyword_ABA_Routing is found.

&lt;!-- ABA Routing Number --&gt;

&lt;Entity id=&quot;cb353f78-2b72-4c3c-8827-
92ebe4f69fdf&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_aba_routing&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_ABA_Routing&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_ABA_RO UTING

aba
aba #
aba routing #
aba routing number
aba#
abarouting#
aba number
abaroutingnumber
american bank association routing #
american bank association routing number
americanbankassociationrouting#
americanbankassociationroutingnumber
bank routing number
bankrouting#
bankroutingnumber
routing transit number
RTN

Argentina National Identity (DNI) Number

Availability Exchange Online
Format Eight digits separated by periods

Pattern Eight digits:

Two digits
A period
Three digits
A period
Three digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_argentina_national_id finds content
that matches the pattern.
A keyword from
Keyword_argentina_national_id is found.

&lt;!-- Argentina National Identity (DNI) Number

--&gt;
&lt;Entity id=&quot;eefbb00e-8282-433c-8620-
8f1da3bffdb2&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_argentina_national_id&quot;/&g
t;
&lt;Match
idRef=&quot;Keyword_argentina_national_id&quot;/
&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_ARGENTINA_NATIO NAL_ID

Argentina National Identity number

Identity
Identification National Identity Card
DNI
NIC National Registry of Persons
Documento Nacional de Identidad
Registro Nacional de las Personas
Identidad
Identificación

Australia Bank Account Number

Availability Exchange Online, Exchange Server 2013

Format 6-10 digits with or without a bank state branch number

Pattern Account number is 6-10 digits.

Australia bank state branch number:
Three digits
A hyphen
Three digits

Checksum No
Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_australia_bank_account_number finds
content that matches the pattern..
A keyword from
Keyword_australia_bank_account_number is
found.
The regular expression
Regex_australia_bank_account_number_bsb
finds content that matches the pattern.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_australia_bank_account_number finds
content that matches the pattern..
A keyword from
Keyword_australia_bank_account_number is
found.

&lt;!-- Australia Bank Account Number --&gt;

&lt;Entity id=&quot;74a54de9-2a30-4aa0-a8aa-
3d9327fc07c7&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_australia_bank_account_number&
quot; /&gt;
&lt;Match
idRef=&quot;Keyword_australia_bank_account_numbe
r&quot; /&gt;
&lt;Match
idRef=&quot;Regex_australia_bank_account_number_
bsb&quot; /&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_australia_bank_account_number&
quot; /&gt;
&lt;Match
idRef=&quot;Keyword_australia_bank_account_numbe
r&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_AUSTRALIA_BANK_ACCO UNT_NUM BER

swift bank code

correspondent bank
base currency
usa account
holder address
bank address
information account
fund transfers
bank charges
bank details
banking information
full names
iaea

Australia Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format Nine letters and digits

Pattern Nine letters and digits:

Two digits or letters (not case sensitive)
Two digits
Five digits or letters (not case sensitive)
OR
1-2 optional letters (not case sensitive)
4-9 digits
OR
Nine digits or letters (not case sensitive)

Checksum No
Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_australia_drivers_license_number
finds content that matches the pattern.
A keyword from
Keyword_australia_drivers_license_number is
found.
No keyword from
Keyword_australia_drivers_license_number_exclusions
is found.

&lt;!-- Australia Drivers License Number --&gt;

&lt;Entity id=&quot;1cbbc8f5-9216-4392-9eb5-
5ac2298d1356&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_australia_drivers_license_numb
er&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_australia_drivers_license_nu
mber&quot; /&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_australia_drivers_license_nu
mber_exclusions&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_AUSTRALIA_DRIV
KEYWO RD_AUSTRALIA_DRIV ERS_LICENSE_NUM BER_E XCL
ERS_LICENSE_NUM BER USIO NS

international driving aaa

permits
DriverLicense
australian automobile
association DriverLicenses

sydney nsw Driver License

international driving Driver Licenses

permit DriversLicense
DriverLicence DriversLicenses
DriverLicences Drivers License
Driver Lic Drivers Licenses
Driver Licence Driver'License
Driver Licences Driver'Licenses
DriversLic Driver' License
DriversLicence Driver' Licenses
DriversLicences Driver'sLicense
Drivers Lic
Drivers Lics Driver'sLicenses
Drivers Licence Driver's License
Drivers Licences Driver's Licenses
Driver'Lic DriverLicense#
Driver'Lics DriverLicenses#
Driver'Licence Driver License#
Driver'Licences Driver Licenses#
Driver' Lic DriversLicense#
Driver' Lics DriversLicenses#
Driver' Licence Drivers License#
Driver' Licences Drivers Licenses#
Driver'sLic Driver'License#
Driver'sLics Driver'Licenses#
Driver'sLicence Driver' License#
Driver'sLicences Driver' Licenses#
Driver's Lic Driver'sLicense#
Driver's Lics Driver'sLicenses#
Driver's Licence Driver's License#
Driver's Licences Driver's Licenses#
DriverLic#
DriverLics#
DriverLicence#
DriverLicences#
Driver Lic#
Driver Lics#
Driver Licence#
Driver Licences#
DriversLic#
DriversLics#
DriversLicence#
DriversLicences#
Drivers Lic#
Drivers Lics#
Drivers Licence#
Drivers Licences#
Driver'Lic#
Driver'Lics#
Driver'Licence#
Driver'Licences#
Driver' Lic#
Driver' Lics#
Driver' Licence#
Driver' Licences#
Driver'sLic#
Driver'sLics#
 Driver'sLicence#
Driver'sLicences#
Driver's Lic#
Driver's Lics#
Driver's Licence#
Driver's Licences#

Australia Medical Account Number

Availability Exchange Online, Exchange Server 2013

Format 10-11 digits

Pattern 10-11 digits:

First digit is in the range 2-6
Ninth digit is a check digit
Tenth digit is the issue digit
Eleventh digit (optional) is the individual number

Checksum Yes
Definition A DLP policy is 95% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_australian_medical_account_number
finds content that matches the pattern.
A keyword from
Keyword_Australia_Medical_Account_Number is
found.
The checksum passes.
A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_australian_medical_account_number
finds content that matches the pattern.
The checksum passes.

&lt;!-- Australia Medical Account Number --

&gt;
&lt;Entity id=&quot;104a99a0-3d3b-4542-a40d-
ab0b9e1efe63&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;95&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_australian_medical_account_numb
er&quot;/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_Australia_Medical_Account_Nu
mber&quot;/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_australian_medical_account_numb
er&quot;/&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_Australia_Medical_Account_Nu
mber&quot;/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_AUSTRALIA_M EDICAL_ACCO UNT_NUM BER

bank account details

medicare payments
mortgage account
bank payments
information branch
credit card loan
department of human services
local service
medicare

Australia Passport Number

Availability Exchange Online, Exchange Server 2013

Format A letter followed by seven digits

Pattern A letter (not case sensitive) followed by seven digits

Checksum No
Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_australia_passport_number finds
content that matches the pattern.
A keyword from Keyword_passport or
Keyword_australia_passport_number is found.

&lt;!-- Australia Passport Number --&gt;

&lt;Entity id=&quot;29869db6-602d-4853-ab93-
3484f905df50&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_australia_passport_number&quot
; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_australia_passport_number&qu
ot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_AUSTRALIA_PASS
KEYWO RD_PASSPO RT PO RT_NUM BER

Passport Number passport

Passport No passport details
Passport # immigration and
citizenship
Passport#
commonwealth of
PassportID australia
Passportno department of
passportnumber immigration
パスポート residential address
パスポート番号 department of
immigration and
パスポートの Num citizenship
パスポート ＃ visa
Numéro de passeport national identity card
Passeport n ° passport number
Passeport Non travel document
Passeport # issuing authority
Passeport#
PasseportNon
Passeportn °
Australia Tax File Number
Availability Exchange Online, Exchange Server 2013

Format 8-9 digits

Pattern 8-9 digits typically presented with spaces as follows:

Three digits
An optional space
Three digits
An optional space
2-3 digits where the last digit is a check digit

Checksum Yes

Definition A DLP policy is 95% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_australian_tax_file_number
finds content that matches the pattern.
A keyword from
Keyword_Australia_Tax_File_Number is found.
No keyword from Keyword_number_exclusions
is found.
The checksum passes.
A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_australian_tax_file_number
finds content that matches the pattern.
No keyword from
Keyword_Australia_Tax_File_Number or
Keyword_number_exclusions is found.
The checksum passes.
 &lt;!-- Australia Tax File Number --&gt;
&lt;Entity id=&quot;e29bc95f-ff70-4a37-aa01-
04d17360a4c5&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;95&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_australian_tax_file_number&quot
; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_Australia_Tax_File_Number&qu
ot; /&gt;
&lt;/Any&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_number_exclusions&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_australian_tax_file_number&quot
; /&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_Australia_Tax_File_Number&qu
ot; /&gt;
&lt;Match
idRef=&quot;Keyword_number_exclusions&quot;
/&gt;
Keywords &lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
KEYWO RD_AUSTRALIA_TAX_ KEYWO RD_NUM BER_E XCLUSI
FILE_NUM BER O NS
 australian business 00000000
number
11111111
marginal tax rate
22222222
medicare levy
33333333
portfolio number
44444444
service veterans
55555555
withholding tax
66666666
individual tax return
77777777
tax file number
88888888
99999999
000000000
111111111
222222222
333333333
444444444
555555555
666666666
777777777
888888888
999999999
0000000000
1111111111
2222222222
3333333333
4444444444
5555555555
6666666666
7777777777
8888888888
9999999999

Belgium National Number

Availability Exchange Online

Format 11 digits plus delimiters

Pattern 11 digits plus delimiters:
Six digits and two periods in the format
YY.MM.DD for date of birth
A hyphen
Three sequential digits (odd for males, even for
females)
A period
Two digits that are a check digit

Checksum Yes

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_belgium_national_number
finds content that matches the pattern.
A keyword from
Keyword_belgium_national_number is found.
The checksum passes.

&lt;!-- Belgium National Number --&gt;

&lt;Entity id=&quot;fb969c9e-0fd1-4b18-8091-
a2123c5e6a54&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_belgium_national_number&quot;/&
gt;
&lt;Match
idRef=&quot;Keyword_belgium_national_number&quot
;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_BELGIUM _NATIO NAL_NUM BER

Identity
Registration
Identification
ID
Identiteitskaart
Registratie nummer
Identificatie nummer
Identiteit
Registratie
Identificatie
Carte d'identité
numéro d'immatriculation
numéro d'identification
identité
inscription
Identifikation
Identifizierung
Identifikationsnummer
Personalausweis
Registrierung
Registrationsnummer

Brazil Legal Entity Number (CNPJ)

Availability Exchange Online

Format 14 digits that include a registration number, branch

number, and check digits, plus delimiters
Pattern 14 digits, plus delimiters:
Two digits
A period
Three digits
A period
Three digits (these first eight digits are the
registration number)
A forward slash
Four-digit branch number
A hyphen
Two digits which are check digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_brazil_cnpj finds content
that matches the pattern.
A keyword from Keyword_brazil_cnpj is found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_brazil_cnpj finds content
that matches the pattern.
The checksum passes.

&lt;!-- Brazil Legal Entity Number (CNPJ) --&gt;

&lt;Entity id=&quot;9b58b5cd-5e90-4df6-b34f-
1ebcc88ceae4&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_brazil_cnpj&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_brazil_cnpj&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_brazil_cnpj&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_BRAZIL_CNPJ

CNPJ
CNPJ/MF
CNPJ-MF
National Registry of Legal Entities
Taxpayers Registry
Legal entity
Legal entities
Registration Status
Business
Company
CNPJ
Cadastro Nacional da Pessoa Jurídica
Cadastro Geral de Contribuintes
CGC
Pessoa jurídica
Pessoas jurídicas
Situação cadastral
Inscrição
Empresa

Brazil CPF Number

Availability Exchange Online

Format 11 digits that include a check digit and can be formatted

or unformatted

Pattern Formatted:
Three digits
A period
Three digits
A period
Three digits
A hyphen
Two digits which are check digits
Unformatted:
11 digits where the last two digits are check digits
Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_brazil_cpf finds content that
matches the pattern.
A keyword from Keyword_brazil_cpf is found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_brazil_cpf finds content that
matches the pattern.
The checksum passes.

&lt;!-- Brazil CPF Number --&gt;

&lt;Entity id=&quot;78e09124-f2c3-4656-b32a-
c1a132cd2711&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_brazil_cpf&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_brazil_cpf&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_brazil_cpf&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_BRAZIL_CPF

CPF
Identification
Registration
Revenue
Cadastro de Pessoas Físicas
Imposto
Identificação
Inscrição
Receita

Brazil National ID Card (RG)

Availability Exchange Online

Format Registro Geral (old format)

Nine digits

Registro de Identidade (RIC) (new format)

11 digits

Pattern Registro Geral (old format):

Two digits
A period
Three digits
A period
Three digits
A hyphen
One digit which is a check digit
Registro de Identidade (RIC) (new format)
10 digits
A hyphen
One digit which is a check digit
Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_brazil_rg finds content that
matches the pattern.
A keyword from Keyword_brazil_rg is found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_brazil_rg finds content that
matches the pattern.
The checksum passes.

&lt;!-- Brazil National ID Card (RG) --&gt;

&lt;Entity id=&quot;486de900-db70-41b3-a886-
abdf25af119c&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_brazil_rg&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_brazil_rg&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_brazil_rg&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_BRAZIL_RG

Cédula de identidade
identity card
national id
número de rregistro
registro de Iidentidade
registro geral
RG (this keyword is case sensitive)
RIC (this keyword is case sensitive)
Canada Bank Account Number
Availability Exchange Online, Exchange Server 2013

Format Seven or twelve digits

Pattern A Canada Bank Account Number is seven or twelve digits.

A Canada bank account transit number is:
Five digits
A hyphen
Three digits
OR
A zero "0"
Eight digits

Checksum No
Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_canada_bank_account_number finds
content that matches the pattern.
A keyword from
Keyword_canada_bank_account_number is found.
The regular expression
Regex_canada_bank_account_transit_number
finds content that matches the pattern.
A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_canada_bank_account_number finds
content that matches the pattern.
A keyword from
Keyword_canada_bank_account_number is found.

&lt;!-- Canada Bank Account Number --&gt;

&lt;Entity id=&quot;552e814c-cb50-4d94-bbaa-
bb1d1ffb34de&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_canada_bank_account_number&quo
t; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_bank_account_number&q
uot; /&gt;
&lt;Match
idRef=&quot;Regex_canada_bank_account_transit_nu
mber&quot; /&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_canada_bank_account_number&quo
t; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_bank_account_number&q
uot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords
KEYWO RD_CANADA_BANK_ACCO UNT_NUM BER

canada savings bonds

canada revenue agency
canadian financial institution
direct deposit form
canadian citizen
legal representative
notary public
commissioner for oaths
child care benefit
universal child care
canada child tax benefit
income tax benefit
harmonized sales tax
social insurance number
income tax refund
child tax benefit
territorial payments
institution number
deposit request
banking information
direct deposit
Canada Driver's License Number
Availability Exchange Online, Exchange Server 2013

Format Varies by province

Pattern Various patterns covering Alberta, British Columbia,

Manitoba, New Brunswick, Newfoundland/Labrador, Nova
Scotia, Ontario, Prince Edward Island, Quebec, and
Saskatchewan

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_[province_name]_drivers_license_number
finds content that matches the pattern.
A keyword from
Keyword_[province_name]_drivers_license_name
is found.
A keyword from
Keyword_canada_drivers_license is found.

&lt;!-- Canada Driver&#39;s License Number --

&gt;
&lt;Entity id=&quot;37186abb-8e48-4800-ad3c-
e3d1610b3db0&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_alberta_drivers_license_number&
quot; /&gt;
&lt;Match
idRef=&quot;Keyword_alberta_drivers_license_name
&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_british_columbia_drivers_licens
e_number&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_british_columbia_drivers_lic
ense_name&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_manitoba_drivers_license_number
&quot; /&gt;
&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_manitoba_drivers_license_nam
e&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_new_brunswick_drivers_license_n
umber&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_new_brunswick_drivers_licens
e_name&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_newfoundland_labrador_drivers_l
icense_number&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_newfoundland_labrador_driver
s_license_name&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_nova_scotia_drivers_license_num
ber&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_nova_scotia_drivers_license_
name&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_ontario_drivers_license_number&
quot; /&gt;
&lt;Match
idRef=&quot;Keyword_ontario_drivers_license_name
&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_prince_edward_island_drivers_li
cense_number&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_prince_edward_island_drivers
_license_name&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_quebec_drivers_license_number&q
uot; /&gt;
&lt;Match
idRef=&quot;Keyword_quebec_drivers_license_name&
quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
 idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_saskatchewan_drivers_license_nu
mber&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_saskatchewan_drivers_license
_name&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_[PRO VINCE_NAM KEYWO RD_CANADA_DRIVER

E]_DRIVERS_LICENSE_NAM E S_LICENSE

The province DL
abbreviation, for
example AB DLS

The province name, for CDL

example Alberta CDLS
DriverLic
DriverLics
DriverLicense
DriverLicenses
DriverLicence
DriverLicences
Driver Lic
Driver Lics
Driver License
Driver Licenses
Driver Licence
Driver Licences
DriversLic
DriversLics
DriversLicence
DriversLicences
DriversLicense
DriversLicenses
Drivers Lic
Drivers Lics
Drivers License
Drivers Licenses
Drivers Licence
Drivers Licences
Driver'Lic
Driver'Lics
Driver'License
Driver'Licenses
Driver'Licence
Driver'Licences
Driver' Lic
Driver' Lics
Driver' License
Driver' Licenses
Driver' Licence
Driver' Licences
Driver'sLic
Driver'sLics
Driver'sLicense
Driver'sLicenses
Driver'sLicence
Driver'sLicences
Driver's Lic
Driver's Lics
Driver's License
Driver's Licenses
Driver's Licence
Driver's Licences
Permis de Conduire
id
ids
idcard number
idcard numbers
idcard #
idcard #s
idcard card
idcard cards
idcard
identification number
identification numbers
identification #
identification #s
identification card
identification cards
identification
DL#
DLS#
CDL#
CDLS#
DriverLic#
DriverLics#
DriverLicense#
DriverLicenses#
DriverLicence#
DriverLicences#
Driver Lic#
Driver Lics#
Driver License#
Driver Licenses#
Driver License#
Driver Licences#
DriversLic#
DriversLics#
DriversLicense#
DriversLicenses#
DriversLicence#
DriversLicences#
Drivers Lic#
Drivers Lics#
Drivers License#
Drivers Licenses#
Drivers Licence#
Drivers Licences#
Driver'Lic#
Driver'Lics#
Driver'License#
Driver'Licenses#
Driver'Licence#
Driver'Licences#
Driver' Lic#
Driver' Lics#
Driver' License#
Driver' Licenses#
Driver' Licence#
Driver' Licences#
Driver'sLic#
Driver'sLics#
Driver'sLicense#
Driver'sLicenses#
Driver'sLicence#
Driver'sLicences#
Driver's Lic#
Driver's Lics#
Driver's License#
Driver's Licenses#
Driver's Licence#
 Driver's Licences#
Permis de Conduire#
id#
ids#
idcard card#
idcard cards#
idcard#
identification card#
identification cards#
identification#

Canada Health Service Number

Availability Exchange Online, Exchange Server 2013

Format 10 digits

Pattern 10 digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_canada_health_service_number finds
content that matches the pattern.
A keyword from
Keyword_canada_health_service_number is
found.

&lt;!-- Canada Health Service Number --&gt;

&lt;Entity id=&quot;59c0bf39-7fab-482c-af25-
00faa4384c94&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_canada_health_service_number&q
uot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_canada_health_service_number
&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_CANADA_HEALTH_SERVICE_NUM BER

personal health number

patient information
health services
speciality services
automobile accident
patient hospital
psychiatrist
workers compensation
disability

Canada Passport Number

Availability Exchange Online, Exchange Server 2013

Format Two uppercase letters followed by six digits

Pattern Two uppercase letters followed by six digits

Checksum No
Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_canada_passport_number finds content
that matches the pattern.
A keyword from
Keyword_canada_passport_number or
Keyword_passport is found.

&lt;!-- Canada Passport Number --&gt;

&lt;Entity id=&quot;14d0db8b-498a-43ed-9fca-
f6097ae687eb&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_canada_passport_number&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_canada_passport_number&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_passport&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_CANADA_PASSPO
RT_NUM BER KEYWO RD_PASSPO RT

canadian citizenship Passport Number

canadian passport Passport No
passport application Passport #
passport photos Passport#
certified translator PassportID
canadian citizens Passportno
processing times passportnumber
renewal application パスポート

パスポート番号

パスポートの Num

パスポート＃

Numéro de passeport
Passeport n °
Passeport Non
Passeport #
Passeport#
PasseportNon
Passeportn °

Canada Personal Health Identification Number (PHIN)

Availability Exchange Online, Exchange Server 2013

Format Nine digits

Pattern Nine digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_canada_phin finds
content that matches the pattern.
At least two keywords from
Keyword_canada_phin or
Keyword_canada_provinces are found..

&lt;!-- Canada PHIN --&gt;

&lt;Entity id=&quot;722e12ac-c89a-4ec8-a1b7-
fea3469f89db&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_canada_phin&quot; /&gt;
&lt;Any minMatches=&quot;2&quot;&gt;
&lt;Match
idRef=&quot;Keyword_canada_phin&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_canada_provinces&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_CANADA_PRO VIN

KEYWO RD_CANADA_PHIN CES

social insurance number Nunavut

health information act Quebec
income tax information Northwest Territories
manitoba health Ontario
health registration British Columbia
prescription purchases Alberta
benefit eligibility Saskatchewan
personal health Manitoba
power of attorney Yukon
registration number Newfoundland and
Labrador
personal health number
New Brunswick
practitioner referral
Nova Scotia
wellness professional
Prince Edward Island
patient referral
Canada
health and wellness

Canada Social Insurance Number

Availability Exchange Online, Exchange Server 2013
Format Nine digits with optional hyphens or spaces

Pattern Formatted:
Three digits
A hyphen or space
Three digits
A hyphen or space
Three digits
Unformatted:
Nine digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_canadian_sin finds content
that matches the pattern.
At least two of any combination of the following:
A keyword from Keyword_sin is found.
A keyword from
Keyword_sin_collaborative is found.
The function Func_eu_date finds a date
in the right date format.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_unformatted_canadian_sin
finds content that matches the pattern.
A keyword from Keyword_sin is found.
The checksum passes.
 &lt;!-- Canada Social Insurance Number --&gt;
&lt;Entity id=&quot;a2f29c85-ecb8-4514-a610-
364790c0773e&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_canadian_sin&quot; /&gt;
&lt;Any minMatches=&quot;2&quot;&gt;
&lt;Match
idRef=&quot;Keyword_sin&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_sin_collaborative&quot;
/&gt;
&lt;Match
idRef=&quot;Func_eu_date&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_unformatted_canadian_sin&quot;
/&gt;
&lt;Match idRef=&quot;Keyword_sin&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_SIN_CO LL ABO RAT

KEYWO RD_SIN IVE

sin driver's license

social insurance drivers license
numero d'assurance driver's licence
sociale
drivers licence
sins
DOB
ssn
Birthdate
ssns
Birthday
social security
Date of Birth
numero d'assurance
social
national identification
number
national id
sin#
soc ins
social ins

Chile Identity Card Number

Availability Exchange Online
Format 7-8 digits plus delimiters a check digit or letter

Pattern 7-8 digits plus delimiters:

1-2 digits
A period
Three digits
A period
Three digits
A dash
One digit or letter (not case sensitive) which is a
check digit

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_chile_id_card finds content
that matches the pattern.
A keyword from Keyword_chile_id_card is
found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_chile_id_card finds content
that matches the pattern.
The checksum passes.

&lt;!-- Chile Identity Card Number --&gt;

&lt;Entity id=&quot;4e979794-49a0-407e-a0b9-
2c536937b925&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_chile_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_chile_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_chile_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_CHILE_ID_CARD

National Identification Number

Identity card
ID
Identification
Rol Único Nacional
RUN
Rol Único Tributario
RUT
Cédula de Identidad
Número De Identificación Nacional
Tarjeta de identificación
Identificación

China Resident Identity Card (PRC) Number

Availability Exchange Online

Format 18 digits

Pattern 18 digits:
Six digits which are an address code
Eight digits in the form YYYYMMDD which are the
date of birth
Three digits which are an order code
One digit which is a check digit

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_china_resident_id finds
content that matches the pattern.
A keyword from Keyword_china_resident_id is
found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_china_resident_id finds
content that matches the pattern.
The checksum passes.

&lt;!-- China Resident Identity Card (PRC)

Number --&gt;
&lt;Entity id=&quot;c92daa86-2d16-4871-901f-
816b3f554fc1&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_china_resident_id&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_china_resident_id&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_china_resident_id&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_CHINA_RESIDENT_ID

Resident Identity Card

PRC
National Identification Card
身份证

居民 身份证

居民身份证

鉴定

身分證

居民 身份證

鑑定

Credit Card Number

Availability Exchange Online

Format 16 digits which can be formatted or unformatted

(dddddddddddddddd) and must pass the Luhn test.

Pattern Very complex and robust pattern that detects cards from
all major brands worldwide, including Visa, MasterCard,
Discover Card, JCB, American Express, gift cards, and diner
cards.

Checksum Yes, the Luhn checksum

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_credit_card finds content
that matches the pattern.
One of the following is true:
A keyword from
Keyword_cc_verification is found.
A keyword from Keyword_cc_name is
found.
The function Func_expiration_date finds
a date in the right date format.
The checksum passes.
A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:

NOTE
This part of the definition applies to Exchange Online
only.

The function Func_credit_card finds content

that matches the pattern.
The checksum passes.
 &lt;!-- Credit Card Number --&gt;
&lt;Entity id=&quot;50842eb7-edc8-4019-85dd-
5a5c1f2bb085&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_credit_card&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_cc_verification&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_cc_name&quot; /&gt;
&lt;Match
idRef=&quot;Func_expiration_date&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_credit_card&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_CC_VERIFICATIO N KEYWO RD_CC_NAM E

card verification amex

card identification american express
number
americanexpress
cvn
Visa
cid
mastercard
cvc2
master card
cvv2
mc
pin block
mastercards
security code
master cards
security number
diner's Club
security no
diners club
issue number
dinersclub
issue no
discover card
cryptogramme
discovercard
numéro de sécurité
discover cards
numero de securite
JCB
kreditkartenprüfnummer
japanese card bureau
kreditkartenprufnummer
carte blanche
prüfziffer
carteblanche
prufziffer
credit card
sicherheits Kode
cc#
sicherheitscode
cc#:
sicherheitsnummer
expiration date
verfalldatum
exp date
codice di verifica
cod. sicurezza expiry date
cod sicurezza date d'expiration
n autorizzazione date d'exp
código date expiration
codigo bank card
cod. seg bankcard
cod seg card number
código de segurança card num
codigo de seguranca cardnumber
codigo de segurança cardnumbers
código de seguranca card numbers
cód. segurança creditcard
cod. seguranca cod. credit cards
segurança
creditcards
cód. seguranca
ccn
cód segurança
card holder
cod seguranca cod
segurança cardholder

cód seguranca card holders

número de verificação cardholders

numero de verificacao check card

ablauf checkcard

gültig bis check cards

gültigkeitsdatum checkcards

gultig bis debit card

gultigkeitsdatum debitcard

scadenza debit cards

data scad debitcards

fecha de expiracion atm card

fecha de venc atmcard

vencimiento atm cards

válido hasta atmcards

valido hasta enroute

vto en route

data de expiração card type

data de expiracao carte bancaire

data em que expira carte de crédit

validade carte de credit

valor numéro de carte

vencimento numero de carte

Venc nº de la carte
nº de carte
kreditkarte
karte
karteninhaber
karteninhabers
kreditkarteninhaber
kreditkarteninstitut
kreditkartentyp
eigentümername
kartennr
kartennummer
kreditkartennummer
kreditkarten-nummer
carta di credito
carta credito
n. carta
n carta
nr. carta
nr carta
numero carta
numero della carta
numero di carta
tarjeta credito
tarjeta de credito
tarjeta crédito
tarjeta de crédito
tarjeta de atm
tarjeta atm
tarjeta debito
tarjeta de debito
tarjeta débito
tarjeta de débito
nº de tarjeta
no. de tarjeta
no de tarjeta
numero de tarjeta
número de tarjeta
tarjeta no
tarjetahabiente
cartão de crédito
cartão de credito
cartao de crédito
cartao de credito
cartão de débito
cartao de débito
cartão de debito
cartao de debito
débito automático
debito automatico
número do cartão
 numero do cartão
número do cartao
numero do cartao
número de cartão
numero de cartão
número de cartao
numero de cartao
nº do cartão
nº do cartao
nº. do cartão
no do cartão
no do cartao
no. do cartão
no. do cartao

Croatia Identity Card Number

Availability Exchange Online

Format Nine digits

Pattern Nine consecutive digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_croatia_id_card finds
content that matches the pattern.
A keyword from Keyword_croatia_id_card is
found.

&lt;!--Croatia Identity Card Number--&gt;

&lt;Entity id=&quot;ff12f884-c20a-4189-b185-
34c8e7258d47&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_croatia_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_croatia_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_CRO ATIA_ID_CARD

Croatian identity card

Osobna iskaznica

Croatia Personal Identification (OIB) Number

Availability Exchange Online

Format 10 digits

Pattern 10 digits:
Six digits in the form DDMMYY which are the date
of birth
Four digits where the final digit is a check digit

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_croatia_oib_number finds
content that matches the pattern.
A keyword from Keyword_croatia_oib_number is
found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_croatia_oib_number finds
content that matches the pattern.
The checksum passes.

&lt;!-- Croatia Personal Identification (OIB)

Number --&gt;
&lt;Entity id=&quot;31983b6d-db95-4eb2-a630-
b44bd091968d&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_croatia_oib_number&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_croatia_oib_number&quot;/&gt
;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_croatia_oib_number&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_CRO ATIA_O IB_NUM BER

Personal Identification Number

Osobni identifikacijski broj
OIB

Czech National Identity Card Number

Availability Exchange Online

Format 10 digits containing a forward slash

 Pattern 10 digits:
Six digits which are the date of birth
A forward slash
Four digits where the final digit is a check digit

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_czech_id_card finds content
that matches the pattern.
A keyword from Keyword_czech_id_card is
found.
The checksum passes.

&lt;!-- Czech National Identity Card Number --

&gt;
&lt;Entity id=&quot;60c0725a-4eb6-455b-9dda-
05d8a7396497&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_czech_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_czech_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_CZECH_ID_CARD

Czech national identity card

Občanský průka

Denmark Personal Identification Number

Availability Exchange Online

Format 10 digits containing a hyphen

 Pattern 10 digits:
Six digits in the format DDMMYY which are the
date of birth
A hyphen
Four digits where the final digit is a check digit

Checksum Yes

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_denmark_id finds
content that matches the pattern.
A keyword from Keyword_denmark_id is found.
The checksum passes.

&lt;!-- Denmark Personal Identification Number -

-&gt;
&lt;Entity id=&quot;6c4f2fef-56e1-4c00-8093-
88d7a01cf460&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_denmark_id&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_denmark_id&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_DENM ARK_ID

Personal Identification Number

CPR
Det Centrale Personregister
Personnummer

Drug Enforcement Agency (DEA) Number

Availability Exchange Online, Exchange Server 2013

Format Two letters followed by seven digits

 Pattern Pattern must include all of the following:
One letter (not case sensitive) from this set of
possible letters: abcdefghjklmnprstux, which is a
registrant code
One letter (not case sensitive), which is the first
letter of the registrant's last name
Seven digits, the last of which is the check digit

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_dea_number finds content that
matches the pattern.
The checksum passes.

&lt;!-- DEA Number --&gt;

&lt;Entity id=&quot;9a5445ad-406e-43eb-8bd7-
cac17ab6d0e4&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_dea_number&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords None

EU Debit Card Number

Availability Exchange Online, Exchange Server 2013

Format 16 digits

Pattern Very complex and robust pattern

Checksum Yes
Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_eu_debit_card finds content
that matches the pattern.
At least one of the following is true:
A keyword from Keyword_eu_debit_card
is found.
A keyword from
Keyword_card_terms_dict is found.
A keyword from
Keyword_card_security_terms_dict is
found.
A keyword from
Keyword_card_expiration_terms_dict is
found.
The function Func_expiration_date finds
a date in the right date format.
The checksum passes.

&lt;!-- EU Debit Card Number --&gt;

&lt;Entity id=&quot;0e9b3178-9678-47dd-a509-
37222ca96b42&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_eu_debit_card&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_eu_debit_card&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_card_terms_dict&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_card_security_terms_dict&quo
t; /&gt;
&lt;Match
idRef=&quot;Keyword_card_expiration_terms_dict&q
uot; /&gt;
&lt;Match
idRef=&quot;Func_expiration_date&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords
 KEY
KEY WO R
WO R D_CA
KEY D_CA RD_E
KEY WO R RD_S XPIR
WO R D_CA ECUR ATIO
D_EU RD_T IT Y_T N_TE
_DEBI ERM ERM RM S
T_CA S_DI S_DI _DIC
RD CT CT T

acco acct card abla

unt nbr iden uf
num tifica
ber acct tion data
num num de
card ber expi
num acct raca
ber no card o
ame verif
card icati data
no. rica de
n on
expi
secu expr card raçã
rity ess i la o
num verif
ber ame data
rica ica
del
cc# nex cid exp
pres
s cod data
seg di
ame exp
rica cod
no seg data
espr uran di
esso ca scad
enza
ame cod
x seg data
uran em
atm ça que
card expi
cod ra
atm sicur
card ezza data
s scad
cod.
atm seg data
kaar scad
t cod. enza
seg
atm uran date
card ca de
atm valid
cod. ité
card seg
s uran datu
atm ça m
kaar aflo
cod. op
t sicur
atm ezza datu
kaar m
codi van
ten ce exp
ban di
cont sicur de
act ezza aflo
op
ban codi
k ce espi
card di ra
verif
ban ica espi
kkaa ra
rt codi
go exp
card codi date
hold go
er de exp
seg datu
card uran m
hold ca
ers expi
codi ratio
card go n
num de expi
card seg re
num uran
ber ça expi
res
card critt
num ogr expi
bers am ry
ma fech
card
type cryp a de
togr expi
card am raci
ano on
num cryp
eric togr fech
o am a de
me venc
card
hold cv2 gulti
er g
cvc bis
card cvc2
hold gulti
ers cvn gkei
tsda
card cvv tum
num
ber cvv2 gülti
g
card cód bis
num seg
bers uran gülti
ca gkei
cart tsda
a cód tum
bian seg
ca uran la
ça scad
cart enza
a cód.
cred seg scad
ito uran enza
ca
cart vala
a di cód. ble
cred seg
uran valid
ito ade
ça
cart valid
ao códi
go o
de hast
cred códi a
ito go
de valo
cart r
ao seg
de uran venc
créd ca
venc
ito códi ime
cart go nto
ao de
seg venc
de imie
debi uran
ça nto
to
de verl
cart oop
ao kaar
de t t
débi cont
to role verv
alda
cart geef g
e t nr
ban uit verv
cair alda
e issu tum
e no
cart vto
e issu
e válid
blan o
che num
ber hast
cart a
e kaar
bleu tide
e ntific
atie
cart num
e de mer
cred
it kred
itkar
cart tenp
e de rufn
créd um
it mer
cart kred
e di itkar
cred tenp
ito rüfn
um
cart mer
ebla
nche kwe
stiea
cart anta
ão l
de
cred no.
ito dell'
edizi
cart one
ão
de no.
créd di
ito sicur
ezza
cart
ão num
de ero
debi de
to secu
rite
cart
ão num
de ero
débi de
to verif
icac
cb ao
ccn num
chec ero
k dell'
card edizi
one
chec
k num
card ero
s di
iden
chec tifica
kcar zion
d e
dell
chec a
kcar
ds sche
da
che
que num
kaar ero
t di
sicur
cirru ezza
s
num
cirru ero
s- van
edc- veili
mae ghei
stro d
cont num
role éro
kaar de
t sécu
cont rité
role nº
kaar auto
ten rizza
cred zion
it e
card núm
cred ero
it de
card verif
s icaç
ão
cred
itcar pern
d o il
bloc
cred co
itcar
ds pin
bloc
deb k
etka
art pruf
ziffe
deb r
etka
arte prüf
n ziffe
r
debi
t secu
card rity
cod
debi e
t
card secu
s rity
no
debi
tcar secu
d rity
num
debi ber
tcar
ds sich
erhe
debi its
to kod
auto e
mati
co sich
erhe
dine itsco
rs de
club
sich
dine erhe
rsclu itsnu
b mm
er
disc
over spel
dblo
disc k
over
card veili
ghei
disc d nr
over
card veili
s ghei
dsa
disc anta
over l
card
veili
disc ghei
over dsc
card ode
s
veili
débi ghei
to dsn
auto um
máti mer
co
verf
edc alld
eige atu
ntü m
mer
nam
e
euro
pea
n
debi
t
card
hoof
dka
art
hoof
dka
arte
n
in
viag
gio
japa
nese
card
bure
au
japa
nse
kaar
tdie
nst
jcb
kaar
t
kaar
t
num
kaar
taan
tal
kaar
taan
talle
n
kaar
thou
der
kaar
thou
ders
kart
e
kart
enin
hab
er
kart
enin
hab
ers
kart
ennr
kart
enn
um
mer
kred
itkar
te
kred
itkar
ten-
num
mer
kred
itkar
teni
nha
ber
kred
itkar
teni
nstit
ut
kred
itkar
tenn
um
mer
kred
itkar
tent
yp
mae
stro
mas
ter
card
mas
ter
card
s
mas
terc
ard
mas
terc
ards
mc
mist
er
cash
n
cart
a
n.
cart
a
no
de
tarje
ta
no
do
cart
ao
no
do
cart
ão
no.
de
tarje
ta
no.
do
cart
ao
no.
do
cart
ão
nr
cart
a
nr.
cart
a
num
eri
di
sche
da
num
ero
cart
a
num
ero
de
cart
ao
num
ero
de
cart
e
num
ero
de
cart
ão
num
ero
de
tarje
ta
num
ero
dell
a
cart
a
num
ero
di
cart
a
num
ero
di
sche
da
num
ero
do
cart
ao
num
ero
do
cart
ão
num
éro
de
cart
e
nº
cart
a
nº
de
cart
e
nº
de
la
cart
e
nº
de
tarje
ta
nº
do
cart
ao
nº
do
cart
ão
nº.
do
cart
ão
núm
ero
de
cart
ao
núm
ero
de
cart
ão
núm
ero
de
tarje
ta
núm
ero
do
cart
ao
sche
da
dell'
asse
gno
sche
da
dell'
atm
osfe
ra
sche
da
dell'
atm
osfe
ra
sche
da
dell
a
ban
ca
sche
da
di
cont
rollo
sche
da
di
debi
to
sche
da
matr
ice
sche
de
dell'
atm
osfe
ra
sche
de
di
cont
rollo
sche
de
di
debi
to
sche
de
matr
ici
sco
pro
no
la
sche
da
sco
pro
no
le
sche
de
solo
sup
port
i di
sche
da
sup
port
o di
sche
da
swit
ch
tarje
ta
atm
tarje
ta
cred
ito
tarje
ta
de
atm
 tarje
ta
de
cred
ito
tarje
ta
de
debi
to
tarje
ta
debi
to
tarje
ta
no
tarje
taha
bien
te
tipo
dell
a
sche
da
uffici
o
giap
pon
ese
dell
a
sche
da
v
pay
v-
pay
visa
visa
plus
visa
elect
ron
visto
visu
m
vpay

Finland National ID
Availability Exchange Online, Exchange Server 2013

Format Six digits plus a character indicating a century plus three

digits plus a check digit
 Pattern Pattern must include all of the following:
Six digits in the format DDMMYY which are a date
of birth
Century marker (either '-', '+' or 'a')
Three-digit personal identification number
A digit or letter (case insensitive) which is a check
digit

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_finnish_national_id finds
content that matches the pattern.
A keyword from Keyword_finnish_national_id
is found.
The checksum passes.

&lt;!-- Finnish National ID--&gt;

&lt;Entity id=&quot;338FD995-4CB5-4F87-AD35-
79BD1DD926C1&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_finnish_national_id&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_finnish_national_id&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_FINNISH_NATIO NAL_ID

Sosiaaliturvatunnus
SOTU Henkilötunnus HETU
Personbeteckning
Personnummer

Finland Passport Number

Availability Exchange Online

Format Combination of nine letters and digits

 Pattern Combination of nine letters and digits:
Two letters (not case sensitive)
Seven digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_finland_passport_number finds content
that matches the pattern.
A keyword from
Keyword_finland_passport_number is found.

&lt;!-- Finland Passport Number --&gt;

&lt;Entity id=&quot;d1685ac3-1d3a-40f8-8198-
32ef5669c7a5&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_finland_passport_number&quot;/
&gt;
&lt;Match
idRef=&quot;Keyword_finland_passport_number&quot
;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_FINL AND_PASSPO RT_NUM BER

Passport
Passi

France Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format 12 digits

Pattern 12 digits with validation to discount similar patterns such

as French telephone numbers

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters::
The function Func_french_drivers_license
finds content that matches the pattern.
At least one of the following is true:
A keyword from
Keyword_french_drivers_license is
found.
The function Func_eu_date finds a date
in the right date format.

&lt;!-- France Driver&#39;s License Number --

&gt;
&lt;Entity id=&quot;18e55a36-a01b-4b0f-943d-
dc10282a1824&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_french_drivers_license&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_french_drivers_license&quot;
/&gt;
&lt;Match
idRef=&quot;Func_eu_date&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_FRENCH_DRIVERS_LICENSE

drivers licence
drivers license
driving licence
driving license
permis de conduire
licence number
license number
licence numbers
license numbers

France National ID Card (CNI)

Availability Exchange Online, Exchange Server 2013
 Format 12 digits

Pattern 12 digits

Checksum No

Definition A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_france_cni finds
content that matches the pattern.

&lt;!-- France CNI --&gt;

&lt;Entity id=&quot;f741ac74-1bc0-4665-b69b-
f0c7f927c0c4&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;65&quot;&gt;
&lt;Pattern confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_france_cni&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords None

France Passport Number

Availability Exchange Online, Exchange Server 2013

Format Nine digits and letters

Pattern Nine digits and letters:

Two digits
Two letters (not case sensitive)
Five digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_fr_passport finds content
that matches the pattern.
A keyword from Keyword_passport is found..

&lt;!-- France Passport Number --&gt;

&lt;Entity id=&quot;3008b884-8c8c-4cd8-a289-
99f34fc7ff5d&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_fr_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_passport&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_PASSPO RT

Passport Number
Passport No
Passport #
Passport#
PassportID
Passportno
passportnumber
パスポート

パスポート番号

パスポートの Num

パスポート ＃

Numéro de passeport
Passeport n °
Passeport Non
Passeport #
Passeport#
PasseportNon
Passeportn °

France Social Security Number (INSEE)

Availability Exchange Online, Exchange Server 2013
Format 15 digits

Pattern Must match one of two patterns:

13 digits followed by a space followed by two
digits, or
15 consecutive digits

Checksum Yes

Definition A DLP policy is 95% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_french_insee or
Func_fr_insee finds content that matches the
pattern.
A keyword from Keyword_fr_insee is found.
The checksum passes.
A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_french_insee or
Func_fr_insee finds content that matches the
pattern.
No keyword from Keyword_fr_insee is found.
The checksum passes.

&lt;!-- France INSEE --&gt;

&lt;Entity id=&quot;71f62b97-efe0-4aa1-aa49-
e14de253619d&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern confidenceLevel=&quot;95&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_french_insee&quot; /&gt;
&lt;Match
idRef=&quot;Func_fr_insee&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_fr_insee&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_french_insee&quot; /&gt;
&lt;Match
idRef=&quot;Func_fr_insee&quot; /&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_fr_insee&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_FR_INSEE

insee
securité sociale
securite sociale
national id
national identification
numéro d'identité
no d'identité
no. d'identité
numero d'identite
no d'identite
no. d'identite
social security number
social security code
social insurance number
le numéro d'identification nationale
d'identité nationale
numéro de sécurité sociale
le code de la sécurité sociale
numéro d'assurance sociale
numéro de sécu
code sécu

German Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format Combination of 11 digits and letters

Pattern 11 digits and letters (not case sensitive):

A digit or letter
Two digits
Six digits or letters
A digit
A digit or letter

Checksum Yes
Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_german_drivers_license
finds content that matches the pattern.
At least one of the following is true:
A keyword from
Keyword_german_drivers_license_number
is found.
A keyword from
Keyword_german_drivers_license_collaborative
is found.
A keyword from
Keyword_german_drivers_license is
found.
The checksum passes.

&lt;!-- German Driver&#39;s License Number --

&gt;
&lt;Entity id=&quot;91da9335-1edb-45b7-a95f-
5fe41a16c63c&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_german_drivers_license&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_german_drivers_license_numbe
r&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_drivers_license_colla
borative&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_drivers_license&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO R
KEYWO R D_GERM
D_GERM AN_DRIV KEYWO R
AN_DRIV ERS_LICE D_GERM
ERS_LICE NSE_CO L AN_DRIV
NSE_NU L ABO RA ERS_LICE
M BER TIVE NSE

Führers Nr- ausstell

chein Führers ungsda
chein tum
Fuhrers
chein Nr- ausstell
Fuhrers ungsort
Fuehrer chein
schein ausstell
Führers Nr- ende
cheinnu Fuehrer behöde
mmer schein
ausstell
Fuhrers No- ende
cheinnu Führers behord
mmer chein e
Fuehrer No- ausstell
scheinn Fuhrers ende
ummer chein behoer
de
Führers No-
chein- Fuehrer
schein
Fuhrers
chein- N-
Führers
Fuehrer chein
schein-
N-
Führers Fuhrers
cheinnu chein
mmerN
r N-
Fuehrer
Fuhrers schein
cheinnu
mmerN Nr-
r Führers
chein
Fuehrer
scheinn Nr-
ummer Fuhrers
Nr chein
Führers Nr-
cheinnu Fuehrer
mmerKl schein
asse
No-
Fuhrers Führers
cheinnu chein
mmerKl
asse No-
Fuhrers
Fuehrer chein
scheinn
ummer No-
Klasse Fuehrer
schein
Führers
chein- N-
Nr Führers
chein
Fuhrers
chein- N-
Nr Fuhrers
chein
Fuehrer
schein- N-
Nr Fuehrer
schein
Führers
chein-
Klasse
Fuhrers
chein-
Klasse
Fuehrer
schein-
Klasse
Führers
cheinnu
mmerN
r
Fuhrers
cheinnu
mmerN
r
Fuehrer
scheinn
ummer
Nr
Führers
cheinnu
mmerKl
asse
Fuhrers
cheinnu
mmerKl
asse
Fuehrer
scheinn
ummer
Klasse
Führers
chein-
Nr
Fuhrers
chein-
Nr
Fuehrer
schein-
Nr
Führers
chein-
Klasse
Fuhrers
chein-
Klasse
Fuehrer
schein-
Klasse
DL
DLS
Driv Lic
Driv
Licen
Driv
License
Driv
License
s
Driv
Licence
Driv
Licence
s
Driv Lic
Driver
Licen
Driver
License
Driver
 License
s
Driver
Licence
Driver
Licence
s
Drivers
Lic
Drivers
Licen
Drivers
License
Drivers
License
s
Drivers
Licence
Drivers
Licence
s
Driver's
Lic
Driver's
Licen
Driver's
License
Driver's
License
s
Driver's
Licence
Driver's
Licence
s
Driving
Lic
Driving
Licen
Driving
License
Driving
License
s
Driving
Licence
Driving
Licence
s

German Identity Card Number

Availability Exchange Online
Format Since 1 November 2010
Nine letters and digits

From 1 April 1987 until 31 October 2010

10 digits

Pattern Since 1 November 2010:

One letter (not case sensitive)
Eight digits
From 1 April 1987 until 31 October 2010
10 digits

Checksum No

Definition A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_germany_id_card
finds content that matches the pattern.
A keyword from Keyword_germany_id_card is
found.

&lt;!-- Germany Identity Card Number --&gt;

&lt;Entity id=&quot;e577372f-c42e-47a0-9d85-
bebed1c237d4&quot;
recommendedConfidence=&quot;65&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_germany_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_germany_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_GERM ANY_ID_CARD

Identity Card
ID
Identification
Personalausweis
Identifizierungsnummer
Ausweis
Identifikation

German Passport Number

Availability Exchange Online, Exchange Server 2013

Format 10 digits or letters

Pattern Pattern must include all of the following:

First character is a digit or a letter from this set (C,
F, G, H, J, K)
Three digits
Five digits or letters from this set (C, -H, J-N, P, R,
T, V-Z)
A digit

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_german_passport finds
content that matches the pattern.
A keyword from any of the five keyword lists is
found.
 The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_german_passport_data finds
content that matches the pattern.
A keyword from any of the five keyword lists is
found.
The checksum passes.

&lt;!-- German Passport Number --&gt;

&lt;Entity id=&quot;2e3da144-d42b-47ed-b123-
fbf78604e52c&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_german_passport&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_german_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_passport_collaborativ
e&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_passport_number&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_german_passport1&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_passport2&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_german_passport_data&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_german_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_passport_collaborativ
e&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_passport_number&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_german_passport1&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_german_passport2&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KE
Y
W
O
R
D_ KE
GE Y
R W
M O
A R
N_ D_ KE KE
P GE Y Y
KE A R W W
Y SS M O O
W P A R R
O O N_ D_ D_
R R P GE GE
D_ T_ A R R
GE C SS M M
R O P A A
M LL O N_ N_
A A R P P
N_ B T_ A A
PA O N SS SS
SS R U P P
P A M O O
O TI BE R R
RT VE R T1 T2

rei g N R b
se e o- ei na
pa b R se ti
ss ur ei p o
ts se as na
rei d p s- lit.
se at as N t
pa u s r
ss m
e N
au r-
rei ss R
se tel ei
pa lu se
ss n p
nu gs as
m d s
m at
er u
pa m
ss au
p ss
or tel
t lu
pa n
ss gs
p or
or t
ts

Greece National ID Card

Availability Exchange Online

Format Combination of 7-8 letters and numbers plus a dash

 Pattern Seven letters and numbers (old format):
One letter (any letter of the Greek alphabet)
A dash
Six digits
Eight letters and numbers (new format):
Two letters whose uppercase character occurs in
both the Greek and Latin alphabets
(ABEZHIKMNOPTYX)
A dash
Six digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_greece_id_card
finds content that matches the pattern.
A keyword from Keyword_greece_id_card is
found.

&lt;!-- Greece National ID Card --&gt;

&lt;Entity id=&quot;82568215-1da1-46d3-874a-
d2294d81b5ac&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_greece_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_greece_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_GREECE_ID_CARD

Greek identity Card

Tautotita
Δελτίο αστυνομικής ταυτότητας
Ταυτότητα

Hong Kong Identity Card (HKID) Number

Availability Exchange Online
Format Combination of 8-9 letters and numbers plus optional
parentheses around the final character

Pattern Combination of 8-9 letters:

1-2 letters (not case sensitive)
Six digits
The final character (any digit or the letter A), which
is the check digit and is optionally enclosed in
parentheses.

Checksum Yes

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_hong_kong_id_card finds
content that matches the pattern.
A keyword from Keyword_hong_kong_id_card is
found.
The checksum passes.
A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_hong_kong_id_card finds
content that matches the pattern.
The checksum passes.

&lt;!-- Hong Kong Identity Card (HKID) number --

&gt;
&lt;Entity id=&quot;e63c28a7-ad29-4c17-a41a-
3d2a0b70fd9c&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_hong_kong_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_hong_kong_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_hong_kong_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_HO NG_KO NG_ID_CARD

Hong Kong Identity Card

HKID
ID card
香港身份證

香港永久性居民身份證

India Permanent Account Number (PAN)

Availability Exchange Online

Format 10 letters or digits

Pattern 10 letters or digits:

Five letters (not case sensitive)
Four digits
A letter which is an alphabetic check digit

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_india_permanent_account_number finds
content that matches the pattern.
A keyword from
Keyword_india_permanent_account_number is
found.
The checksum passes.

&lt;!-- India Permanent Account Number --&gt;

&lt;Entity id=&quot;2602bfee-9bb0-47a5-a7a6-
2bf3053e2804&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_india_permanent_account_number
&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_india_permanent_account_numb
er&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_INDIA_PERM ANENT_ACCO UNT_NUM BER

Permanent Account Number

PAN

India Unique Identification (Aadhaar) Number

Availability Exchange Online

Format 12 digits containing optional spaces or dashes

Pattern 12 digits:
Four digits
An optional space or dash
Four digits
An optional space or dash
The final digit which is the check digit

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_india_aadhaar finds content
that matches the pattern.
A keyword from Keyword_india_aadhar is found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_india_aadhaar finds content
that matches the pattern.
The checksum passes.

&lt;!-- India Unique Identification (Aadhaar)

number --&gt;
&lt;Entity id=&quot;1ca46b29-76f5-4f46-9383-
cfa15e91048f&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_india_aadhaar&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_india_aadhar&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_india_aadhaar&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_INDIA_AADHAR

Aadhar
Aadhaar
UID

Indonesia Identity Card (KTP) Number

Availability Exchange Online

Format 16 digits containing optional periods

Pattern 16 digits:
Two-digit province code
A period (optional)
Two-digit regency or city code
Two-digit subdistrict code
A period (optional)
Six digits in the format DDMMYY which are the
date of birth
A period (optional)
Four digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_indonesia_id_card finds content that
matches the pattern.
A keyword from Keyword_indonesia_id_card is
found.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_indonesia_id_card finds content that
matches the pattern.

&lt;!-- Indonesia Identity Card (KTP) Number --

&gt;
&lt;Entity id=&quot;da68fdb0-f383-4981-8c86-
82689d3b7d55&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_indonesia_id_card&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_indonesia_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_indonesia_id_card&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_INDO NESIA_ID_CARD

KTP
Kartu Tanda Penduduk
Nomor Induk Kependudukan

International Banking Account Number (IBAN)

Availability Exchange Online, Exchange Server 2013

Format Country code (two letters) plus check digits (two digits)
plus bban number (up to 30 characters)

Pattern Pattern must include all of the following:

Two-letter country code
Two check digits (followed by an optional space)
1-7 groups of four letters or digits (can be
separated by spaces)
1-3 letters or digits
The format for each country is slightly different. The IBAN
sensitive information type covers these 60 countries:

ad, ae, al, at, az, ba, be, bg, bh, ch, cr, cy, cz, de, dk,
do, ee, es, fi, fo, fr, gb, ge, gi, gl, gr, hr, hu, ie, il, is, it,
kw, kz, lb, li, lt, lu, lv, mc, md, me, mk, mr, mt, mu,
nl, no, pl, pt, ro, rs, sa, se, si, sk, sm, tn, tr, vg

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_iban finds content that
matches the pattern.
The checksum passes.

&lt;Entity id=&quot;e7dc4711-11b7-4cb0-b88b-
2c394a771f0e&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch idRef=&quot;Func_iban&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords None

IP Address
Availability Exchange Online, Exchange Server 2013

Format IPv4:
Complex pattern which accounts for formatted
(periods) and unformatted (no periods) versions of
the IPv4 addresses
IPv6:
Complex pattern which accounts for formatted
IPv6 numbers (which include colons)

Pattern

Checksum No
Definition For IPv6, a DLP policy is 85% confident that it's detected
this type of sensitive information if, within a proximity of
300 characters:
The regular expression Regex_ipv6_address
finds content that matches the pattern.
No keyword from Keyword_ipaddress is found.
For IPv4, a DLP policy is 95% confident that it's detected
this type of sensitive information if, within a proximity of
300 characters:
The regular expression Regex_ipv4_address
finds content that matches the pattern.
A keyword from Keyword_ipaddress is found.
For IPv6, a DLP policy is 95% confident that it's detected
this type of sensitive information if, within a proximity of
300 characters:
The regular expression Regex_ipv6_address
finds content that matches the pattern.
No keyword from Keyword_ipaddress is found.

&lt;!-- IP Address --&gt;

&lt;Entity id=&quot;1daa4ad5-e2dd-4ca4-a788-
54722c09efb2&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_ipv6_address&quot; /&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_ipaddress&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;95&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_ipv4_address&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_ipaddress&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;95&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_ipv6_address&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_ipaddress&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_IPADDRESS

IP (this keyword is case sensitive)

ip address
ip addresses
internet protocol
IP-‫כתובת ה‬

Ireland Personal Public Service (PPS) Number

Availability Exchange Online

Format Old format (until 31 Dec 2012)

Seven digits followed by 1-2 letters

New format (1 Jan 2013 and after)

Seven digits followed by two letters

Pattern Old format (until 31 Dec 2012)

Seven digits
1-2 letters (not case sensitive)
New format (1 Jan 2013 and after)
Seven digits
A letter (not case sensitive) which is an alphabetic
check digit
The letter "A" or "H" (not case sensitive)

Checksum Yes
Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_ireland_pps finds content
that matches the pattern.
One of the following is true:
A keyword from Keyword_ireland_pps is
found.
The function Func_eu_date finds a date
in the right date format.
The checksum passes.
A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_ireland_pps finds content
that matches the pattern.
The checksum passes.

&lt;!-- Ireland Personal Public Service (PPS)

Number --&gt;
&lt;Entity id=&quot;1cdb674d-c19a-4fcf-9f4b-
7f56cc87345a&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_ireland_pps&quot;/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_ireland_pps&quot;/&gt;
&lt;Match idRef=&quot;Func_eu_date&quot;/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_ireland_pps&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_IREL AND_PPS

Personal Public Service Number

PPS Number
PPS Num
PPS No.
PPS #
PPS#
PPSN
Public Services Card
Uimhir Phearsanta Seirbhíse Poiblí
Uimh. PSP
PSP

Israel Bank Account Number

Availability Exchange Online, Exchange Server 2013

Format 13 digits

Pattern Formatted:
Two digits
A dash
Three digits
A dash
Eight digits
Unformatted:
13 consecutive digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_israel_bank_account_number finds
content that matches the pattern.
A keyword from
Keyword_israel_bank_account_number is found.

&lt;!-- Israel Bank Account Number --&gt;

&lt;Entity id=&quot;7d08b2ff-a0b9-437f-957c-
aeddbf9b2b25&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_israel_bank_account_number&quo
t; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_israel_bank_account_number&q
uot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_ISRAEL_BANK_ACCO UNT_NUM BER

Bank Account Number

Bank Account
Account Number
‫מספר חשבון בנ ק‬

Israel National ID
Availability Exchange Online, Exchange Server 2013

Format Nine digits

Pattern Nine consecutive digits

Checksum Yes
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_israeli_national_id_number
finds content that matches the pattern.
A keyword from Keyword_Israel_National_ID is
found.
The checksum passes.

&lt;!-- Israel National ID Number --&gt;

&lt;Entity id=&quot;e05881f5-1db1-418c-89aa-
a3ac5c5277ee&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_israeli_national_id_number&quot
; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_Israel_National_ID&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_ISRAEL_NATIO NAL_ID

‫מספר זהות‬
National ID Number

Italy Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format A combination of 10 letters and digits

Pattern A combination of 10 letters and digits:

One letter (not case sensitive)
The letter "A" or "V" (not case sensitive)
Seven letters (not case sensitive), digits, or the
underscore character
One letter (not case sensitive)

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_italy_drivers_license_number finds
content that matches the pattern.
A keyword from
Keyword_italy_drivers_license_number is
found.

&lt;!-- Italy Driver&#39;s license Number --&gt;

&lt;Entity id=&quot;97d6244f-9157-41bd-8e0c-
9d669a5c4d71&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_italy_drivers_license_number&q
uot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_italy_drivers_license_number
&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_ITALY_DRIVERS_LICENSE_NUM BER

numero di patente di guida

patente di guida

Japan Bank Account Number

Availability Exchange Online, Exchange Server 2013

Format Seven or eight digits

Pattern Bank account number:

Seven or eight digits
Bank account branch code:
Four digits
A space or dash (optional)
Three digits

Checksum No
Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_jp_bank_account finds
content that matches the pattern.
A keyword from Keyword_jp_bank_account is
found.
One of the following is true:
The function
Func_jp_bank_account_branch_code
finds content that matches the pattern.
A keyword from
Keyword_jp_bank_branch_code is found.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_jp_bank_account finds
content that matches the pattern.
A keyword from Keyword_jp_bank_account is
found.

&lt;!-- Japan Bank Account Number --&gt;

&lt;Entity id=&quot;d354f95b-96ee-4b80-80bc-
4377312b55bc&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Version
minEngineVersion=&quot;15.01.0131.000&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_bank_account&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_jp_bank_account&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Func_jp_bank_account_branch_code&quo
t; /&gt;
&lt;Match
idRef=&quot;Keyword_jp_bank_branch_code&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Version&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_bank_account&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_jp_bank_account&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_JP_B
KEYWO RD_JP_B ANK_BRANCH_
ANK_ACCO UNT CO DE

Checking Otemachi
Account
Number
Checking
Account
Checking
Account #
Checking
Acct Number
Checking
Acct #
Checking
Acct No.
Checking
Account No.
Bank Account
Number
Bank Account
Bank Account
#
Bank Acct
Number
Bank Acct #
Bank Acct
No.
Bank Account
No.
Savings
Account
Number
Savings
Account
Savings
Account #
Savings Acct
Number
Savings Acct
#
Savings Acct
No.
Savings
Account No.
Debit
Account
Number
Debit
Account
Debit
Account #
Debit Acct
Number
Debit Acct #
Debit Acct
No.
Debit
Account No.
 口座番号を当
座預金口座の
確認

＃アカウントの
確認、勘定番
号の確認

＃勘定の確認

勘定番号の確
認

口座番号の確
認

銀行口座番号

銀行口座

銀行口座＃

銀行の勘定番
号

銀行の acct＃

銀行の勘定い
いえ

銀行口座番号

普通預金口座
番号

預金口座

貯蓄口座＃

貯蓄勘定の数

貯蓄勘定＃

貯蓄勘定番号

普通預金口座
番号

引き落とし口
座番号

口座番号

口座番号＃

デビットの acct
番号

デビット勘定＃

デビットACCT
の番号

デビット口座番
号

Japan Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format 12 digits
Pattern 12 consecutive digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_jp_drivers_license_number
finds content that matches the pattern.
A keyword from
Keyword_jp_drivers_license_number is found.

&lt;!-- Japan Driver&#39;s License Number --&gt;

&lt;Entity id=&quot;c6011143-d087-451c-8313-
7f6d4aed2270&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_drivers_license_number&quot;
/&gt;
&lt;Match idRef
=&quot;Keyword_jp_drivers_license_number&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords
 KEYWO RD_JP_DRIVERS_LICENSE_NUM BER

driver license
drivers license
driver's license
drivers licenses
driver's licenses
driver licenses
dl#
dls#
lic#
lics#
運転免許証

運転免許

免許証

免許

運転免許証番号

運転免許番号

免許証番号

免許番号

運転免許証ナンバー

運転免許ナンバー

免許証ナンバー

運転免許証No.

運転免許No.

免許証No.

免許No.

運転免許証#

運転免許#

免許証#

免許#

Japan Passport Number

Availability Exchange Online, Exchange Server 2013

Format Two letters followed by seven digits

Pattern Two letters (not case sensitive) followed by seven digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_jp_passport finds content
that matches the pattern.
A keyword from Keyword_jp_passport is found.

&lt;!-- Japan Passport Number --&gt;

&lt;Entity id=&quot;75177310-1a09-4613-bf6d-
833aae3743f8&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_jp_passport&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_JP_PASSPO RT

パスポート

パスポート番号

パスポートの Num

パスポート＃

Japan Resident Registration Number

Availability Exchange Online, Exchange Server 2013

Format 11 digits

Pattern 11 consecutive digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_jp_resident_registration_number finds
content that matches the pattern.
A keyword from
Keyword_jp_resident_registration_number is
found.

&lt;!-- Japan Resident Registration Number --

&gt;
&lt;Entity id=&quot;01c1209b-6389-4faf-a5f8-
3f7e13899652&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_resident_registration_number
&quot; /&gt;
&lt;Match idRef
=&quot;Keyword_jp_resident_registration_number&q
uot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_JP_RESIDENT_REGISTRATIO N_NUM BER

Resident Registration Number

Resident Register Number
Residents Basic Registry Number
Resident Registration No.
Resident Register No.
Residents Basic Registry No.
Basic Resident Register No.
住民登録番号、登録番号をレジデント

住民基本登録番号、登録番号

住民基本レジストリ番号を常駐

登録番号を常駐住民基本台帳登録番号

Japan Social Insurance Number (SIN)

Availability Exchange Online, Exchange Server 2013

Format 7-12 digits

Pattern 7-12 digits:
Four digits
A hyphen (optional)
Six digits
OR
7-12 consecutive digits

Checksum No

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_jp_sin finds content that
matches the pattern.
A keyword from Keyword_jp_sin is found.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_jp_sin_pre_1997 finds
content that matches the pattern.
A keyword from Keyword_jp_sin is found.

&lt;!-- Japan Social Insurance Number --&gt;

&lt;Entity id=&quot;c840e719-0896-45bb-84fd-
1ed5c95e45ff&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_sin&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_jp_sin&quot; /&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_jp_sin_pre_1997&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_jp_sin&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_JP_SIN

Social Insurance No.

Social Insurance Num
Social Insurance Number
社会保険のテンキー

社会保険番号

Malaysia ID Card Number

Availability Exchange Online

Format 12 digits containing optional hyphens

Pattern 12 digits:
Six digits in the format YYMMDD which are the
date of birth
A dash (optional)
Two-letter place-of-birth code
A dash (optional)
Three random digits
One-digit gender code

Checksum No
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_malaysia_id_card_number finds content
that matches the pattern.
A keyword from
Keyword_malaysia_id_card_number is found.

&lt;!-- Malaysia ID Card Number --&gt;

&lt;/Entity&gt;
&lt;Entity id=&quot;7f0e921c-9677-435b-
aba2-bb8f1013c749&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_malaysia_id_card_number&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_malaysia_id_card_number&quot
; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_M AL AYSIA_ID_CARD_NUM BER

MyKad
Identity Card
ID Card
Identification Card
Digital Application Card
Kad Akuan Diri
Kad Aplikasi Digital

Netherlands Citizen's Service (BSN) Number

Availability Exchange Online

Format 8-9 digits containing optional spaces

 Pattern 8-9 digits:
Three digits
A space (optional)
Three digits
A space (optional)
2-3 digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_netherlands_bsn finds
content that matches the pattern.
A keyword from Keyword_netherlands_bsn is
found.
The function Func_eu_date2 finds a date in the
right date format.
The checksum passes.

&lt;!-- Netherlands Citizen&#39;s Service (BSN)

Number --&gt;
&lt;Entity id=&quot;c5f54253-ef7e-44f6-a578-
440ed67e946d&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_netherlands_bsn&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_netherlands_bsn&quot; /&gt;
&lt;Match idRef=&quot;Func_eu_date2&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_NETHERL ANDS_BSN

Citizen service number

BSN
Burgerservicenummer
Sofinummer
Persoonsgebonden nummer
Persoonsnummer

New Zealand Ministry of Health Number

 Availability Exchange Online, Exchange Server 2013

Format Three letters, a space (optional), and four digits

Pattern Three letters (not case sensitive) a space (optional) four

digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_new_zealand_ministry_of_health_number
finds content that matches the pattern.
A keyword from Keyword_nz_terms is found.
The checksum passes.

&lt;!-- New Zealand Health Number --&gt;

&lt;Entity id=&quot;2b71c1c8-d14e-4430-82dc-
fd1ed6bf05c7&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_new_zealand_ministry_of_health_
number&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_nz_terms&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_NZ_TERM S

NHI
New Zealand
Health
treatment

Norway Identification Number

Availability Exchange Online
Format 11 digits

Pattern 11 digits:
Six digits in the format DDMMYY which are the
date of birth
Three-digit individual number
Two check digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_norway_id_number finds
content that matches the pattern.
A keyword from Keyword_norway_id_number is
found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_norway_id_numbe finds
content that matches the pattern.
The checksum passes.

&lt;!-- Norway Identification Number --&gt;

&lt;Entity id=&quot;d4c8a798-e9f2-4bd3-9652-
500d24080fc3&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_norway_id_number&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_norway_id_number&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_norway_id_number&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_NO RWAY_ID_NUM BER

Personal identification number

Norwegian ID Number
ID Number
Identification
Personnummer
Fødselsnummer

Philippines Unified Multi-Purpose ID Number

Availability Exchange Online

Format 12 digits separated by hyphens

Pattern 12 digits:
Four digits
A hyphen
Seven digits
A hyphen
One digit

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_philippines_unified_id finds content
that matches the pattern.
A keyword from Keyword_philippines_id is
found.

&lt;!-- Philippines Unified Multi-Purpose ID

number --&gt;
&lt;Entity id=&quot;019b39dd-8c25-4765-91a3-
d9c6baf3c3b3&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_philippines_unified_id&quot;/&
gt;
&lt;Match
idRef=&quot;Keyword_philippines_id&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_PHILIPPINES_ID

Unified Multi-Purpose ID
UMID
Identity Card
Pinag-isang Multi-Layunin ID

Poland Identity Card

Availability Exchange Online, Exchange Server 2013

Format Three letters and six digits

Pattern Three letters (not case sensitive) followed by six digits

Checksum Yes
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_polish_national_id finds
content that matches the pattern.
A keyword from
Keyword_polish_national_id_passport_number
is found.
The checksum passes.

&lt;!-- Poland Identity Card--&gt;

&lt;Entity id=&quot;25E64989-ED5D-40CA-A939-
6C14183BB7BF&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_polish_national_id&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_polish_national_id_passport_
number&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_PO LISH_NATIO NAL_ID_PASSPO RT_NUM BER

Nazwa i nr dowodu tożsamości

Dowód Tożsamości
dow. os.

Poland National ID (PESEL)

Availability Exchange Online, Exchange Server 2013

Format 11 digits

Pattern 11 consecutive digits

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_pesel_identification_number finds
content that matches the pattern.
A keyword from
Keyword_pesel_identification_number is
found.
The checksum passes.

&lt;!-- Poland National ID (PESEL) --&gt;

&lt;Entity id=&quot;E3AAF206-4297-412F-9E06-
BA8487E22456&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_pesel_identification_number&quo
t; /&gt;
&lt;Match
idRef=&quot;Keyword_pesel_identification_number&
quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_PESEL_IDENTIFICATIO N_NUM BER

Nr PESEL
PESEL

Poland Passport
Availability Exchange Online, Exchange Server 2013

Format Two letters and seven digits

Pattern Two letters (not case sensitive) followed by seven digits

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_polish_passport_number
finds content that matches the pattern.
A keyword from
Keyword_polish_national_id_passport_number
is found.
The checksum passes.

&lt;!-- Poland Passport Number --&gt;

&lt;Entity id=&quot;03937FB5-D2B6-4487-B61F-
0F8BFF7C3517&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_polish_passport_number&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_polish_national_id_passport_
number&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
&lt;/Version&gt;

Keywords

KEYWO RD_PO LISH_NATIO NAL_ID_PASSPO RT_NUM BER

Nazwa i nr dowodu tożsamości

Dowód Tożsamości
dow. os.

Portugal Citizen Card Number

Availability Exchange Online

Format Eight digits

Pattern Eight digits

Checksum No
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_portugal_citizen_card finds content
that matches the pattern.
A keyword from
Keyword_portugal_citizen_card is found.

&lt;!-- Portugal Citizen Card Number --&gt;

&lt;Entity id=&quot;91a7ece2-add4-4986-9a15-
c84544d81ecd&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_portugal_citizen_card&quot;/&g
t;
&lt;Match
idRef=&quot;Keyword_portugal_citizen_card&quot;/
&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_PO RTUGAL_CITIZEN_CARD

Citizen Card
National ID Card
CC
Cartão de Cidadão
Bilhete de Identidade

Saudi Arabia National ID

Availability Exchange Online, Exchange Server 2013

Format 10 digits

Pattern 10 consecutive digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_saudi_arabia_national_id finds content
that matches the pattern.
A keyword from
Keyword_saudi_arabia_national_id is found.

&lt;!-- Saudi Arabia National ID --&gt;

&lt;Entity id=&quot;8c5a0ba8-404a-41a3-8871-
746aa21ee6c0&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_saudi_arabia_national_id&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_saudi_arabia_national_id&quo
t; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_SAUDI_ARABIA_NATIO NAL_ID

Identification Card
I card number
ID number
‫اﻟ ﻮﻃﻨﻴ ﺔ اﻟ ﻬ ﻮ ﻳ ﺔ ﺑﻄﺎ ﻗ ﺔ رﻗ ﻢ‬

Singapore National Registration Identity Card (NRIC) Number

Availability Exchange Online

Format Nine letters and digits

Pattern Nine letters and digits:

The letter "F", "G", "S", or "T" (not case sensitive)
Seven digits
An alphabetic check digit

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_singapore_nric
finds content that matches the pattern.
A keyword from Keyword_singapore_nric is
found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_singapore_nric
finds content that matches the pattern.
The checksum passes.

&lt;!-- Singapore National Registration Identity

Card (NRIC) Number --&gt;
&lt;Entity id=&quot;cead390a-dd83-4856-9751-
fb6dc98c34da&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_singapore_nric&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_singapore_nric&quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_singapore_nric&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_SINGAPO RE_NRIC

National Registration Identity Card

Identity Card Number
NRIC
IC
Foreign Identification Number
FIN
身份证

身份證

South Africa Identification Number

Availability Exchange Online
 Format 13 digits that may contain spaces

Pattern 13 digits:
Six digits in the format YYMMDD which are the
date of birth
Four digits
A single-digit citizenship indicator
The digit "8" or "9"
One digit which is a checksum digit

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_south_africa_identification_number
finds content that matches the pattern.
A keyword from
Keyword_south_africa_identification_number
is found.
The checksum passes.

&lt;!-- South Africa Identification Number --

&gt;
&lt;Entity id=&quot;e2adf7cb-8ea6-4048-a2ed-
d89eb65f2780&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_south_africa_identification_num
ber&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_south_africa_identification_
number&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_SO UTH_AFRICA_IDENTIFICATIO N_NUM BER

Identity card
ID
Identification

South Korea Resident Registration Number

Availability Exchange Online

Format 13 digits containing a hyphen

Pattern 13 digits:
Six digits in the format YYMMDD which are the
date of birth
A hyphen
One digit determined by the century and gender
Four-digit region-of-birth code
One digit used to differentiate people for whom
the preceding numbers are identical
A check digit.

Checksum Yes
 Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_south_korea_resident_number finds
content that matches the pattern.
A keyword from
Keyword_south_korea_resident_number is
found.
The checksum passes.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_south_korea_resident_number finds
content that matches the pattern.
The checksum passes.

&lt;!-- South Korea Resident Registration Number

--&gt;
&lt;Entity id=&quot;5b802e18-ba80-44c4-bc83-
bf2ad36ae36a&quot;
recommendedConfidence=&quot;85&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_south_korea_resident_number&quo
t;/&gt;
&lt;Match
idRef=&quot;Keyword_south_korea_resident_number&
quot;/&gt;
&lt;/Pattern&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_south_korea_resident_number&quo
t;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_SO UTH_KO REA_RESIDENT_NUM BER

National ID card
Citizen's Registration Number
Jumin deungnok beonho
RRN
주민등록번호

Spain Social Security Number (SSN)

Availability Exchange Online, Exchange Server 2013
 Format 11-12 digits

Pattern 11-12 digits:

Two digits
A forward slash (optional)
7-8 digits
A forward slash (optional)
Two digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_spanish_social_security_number finds
content that matches the pattern.
The checksum passes.

&lt;!-- Spain SSN --&gt;

&lt;Entity id=&quot;5df987c0-8eae-4bce-ace7-
b316347f3070&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_spanish_social_security_number&
quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords None

Sweden National ID
Availability Exchange Online, Exchange Server 2013

Format 10 or 12 digits and an optional delimiter

Pattern 10 or 12 digits and an optional delimiter:

2-4 digits (optional)
Six digits in date format YYMMDD
Delimiter of "-" or "+" (optional), plus
Four digits
 Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_swedish_national_identifier finds
content that matches the pattern.
The checksum passes.

&lt;!-- Sweden National ID --&gt;

&lt;Entity id=&quot;f69aaf40-79be-4fac-8f05-
fd1910d272c8&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_swedish_national_identifier&quo
t; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords No

Sweden Passport Number

Availability Exchange Online, Exchange Server 2013

Format Eight digits

Pattern Eight consecutive digits

Checksum No
Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_sweden_passport_number finds content
that matches the pattern.
One of the following is true:
A keyword from Keyword_passport is
found.
A keyword from
Keyword_sweden_passport is found.

&lt;!-- Sweden Passport Number --&gt;

&lt;Entity id=&quot;ba4e7456-55a9-4d89-9140-
c33673553526&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_sweden_passport_number&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_sweden_passport&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
Keywords

KEYWO RD_SWE KEYWO RD_PAS

DEN_PASSPO RT SPO RT

visa Passport
requirements Number
Alien Passport No
Registration
Card Passport #

Schengen Passport#
visas PassportID
Schengen Passportno
visa
passportnum
Visa ber
Processing
パスポート
Visa Type
パスポート番
Single Entry 号
Multiple パスポートの
Entry Num
G3 パスポート＃
Processing
Fees Numéro de
passeport
Passeport n
°
Passeport
Non
Passeport #
Passeport#
PasseportNo
n
Passeportn °

SWIFT Code
Availability Exchange Online, Exchange Server 2013

Format Four letters followed by 5-31 letters or digits

Pattern Four letters followed by 5-31 letters or digits:

Four-letter bank code (not case sensitive)
An optional space
4-28 letters or digits (the Basic Bank Account
Number (BBAN))
An optional space
1-3 letters or digits (remainder of the BBAN)
Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_swift finds
content that matches the pattern.
A keyword from Keyword_swift is found.

&lt;Entity id=&quot;cb2ab58c-9cb8-4c81-baf8-
a4e106791df4&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_swift&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_swift&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords
 KEYWO RD_SWIFT

international organization for standardization 9362

iso 9362
iso9362
swift#
swiftcode
swiftnumber
swiftroutingnumber
swift code
swift number #
swift routing number
bic number
bic code
bic #
bic#
bank identifier code
標準化9362

迅速＃

SWIFTコード
SWIFT番号
迅速なルーティング番号

BIC番号
BICコード
銀行識別コードのための国際組織

Organisation internationale de normalisation 9362

rapide #
code SWIFT
le numéro de swift
swift numéro d'acheminement
le numéro BIC
# BIC
code identificateur de banque

Taiwan National ID
Availability Exchange Online, Exchange Server 2013

Format One letter (in English) followed by nine digits

Pattern One letter (in English) followed by nine digits:
One letter (in English, not case sensitive)
The digit "1" or "2"
Eight digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_taiwanese_national_id finds
content that matches the pattern.
A keyword from
Keyword_taiwanese_national_id is found.
The checksum passes.

&lt;!-- Taiwanese National ID --&gt;

&lt;Entity id=&quot;4C7BFC34-8DD1-421D-8FB7-
6C6182C2AF03&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_taiwanese_national_id&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_taiwanese_national_id&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_TAIWANESE_NATIO NAL_ID

身份證字號

身份證

身份證號碼

身份證號

身分證字號

身分證

身分證號碼

身份證號

身分證統一編號

國民身分證統一編號

簽名

蓋章

簽名或蓋章

簽章

Taiwan Passport Number

Availability Exchange Online

Format Biometric passport number

Nine digits

Non-biometric passport number

Nine digits

Pattern Biometric passport number

The digit "3"
Eight digits
Non-biometric passport number
Nine digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_taiwan_passport
finds content that matches the pattern.
A keyword from Keyword_taiwan_passport is
found.

&lt;!-- Taiwan Passport Number --&gt;

&lt;Entity id=&quot;e7251cb4-4c2c-41df-963e-
924eb3dae04a&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_taiwan_passport&quot;/&gt;
&lt;Match
idRef=&quot;Keyword_taiwan_passport&quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_TAIWAN_PASSPO RT

ROC passport number

Passport number
Passport no
Passport Num
Passport #
护照

中華民國護照

Zhōnghuá Mínguó hùzhào

Taiwan Resident Certificate (ARC/TARC) Number

Availability Exchange Online

Format 10 letters and digits

Pattern 10 letters and digits:

Two letters (not case sensitive)
Eight digits

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_taiwan_resident_certificate finds
content that matches the pattern.
A keyword from
Keyword_taiwan_resident_certificate is
found.

&lt;!-- Taiwan Resident Certificate (ARC/TARC) -

-&gt;
&lt;Entity id=&quot;48269fec-05ea-46ea-b326-
f5623a58c6e9&quot;
recommendedConfidence=&quot;75&quot;
patternsProximity=&quot;300&quot;&gt;
&lt;Pattern confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_taiwan_resident_certificate&qu
ot;/&gt;
&lt;Match
idRef=&quot;Keyword_taiwan_resident_certificate&
quot;/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_TAIWAN_RESIDENT_CERTIFICATE

Resident Certificate
Resident Cert
Resident Cert.
Identification card
Alien Resident Certificate
ARC
Taiwan Area Resident Certificate
TARC
居留證

外僑居留證

台灣地區居留證

U.K. Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format Combination of 18 letters and digits in the specified

format
Pattern 18 letters and digits:
Five letters (not case sensitive) or the digit "9" in
place of a letter
One digit
Five digits in the date format DDMMY for date of
birth
Two letters (not case sensitive) or the digit "9" in
place of a letter
Five digits

Checksum Yes

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_uk_drivers_license finds
content that matches the pattern.
A keyword from Keyword_uk_drivers_license is
found.
The checksum passes.

&lt;!-- U.K. Driver&#39;s License Number --&gt;

&lt;Entity id=&quot;f93de4be-d94c-40df-a8be-
461738047551&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_uk_drivers_license&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_uk_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_UK_DRIVERS_LICENSE

DVLA
light vans
quadbikes
motor cars
125cc
sidecar
tricycles
motorcycles
photocard licence
learner drivers
licence holder
licence holders
driving licences
driving licence
dual control car

U.K. Electoral Roll Number

Availability Exchange Online, Exchange Server 2013

Format Two letters followed by 1-4 digits

Pattern Two letters (not case sensitive) followed by 1-4 numbers

Checksum No
 Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression Regex_uk_electoral
finds content that matches the pattern.
A keyword from Keyword_uk_electoral is found.

&lt;!-- U.K. Electoral Number --&gt;

&lt;Entity id=&quot;a3eea206-dc0c-4f06-9e22-
aa1be3059963&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_uk_electoral&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_uk_electoral&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;

Keywords

KEYWO RD_UK_ELECTO RAL

council nomination
nomination form
electoral register
electoral roll

U.K. National Health Service Number

Availability Exchange Online, Exchange Server 2013

Format 10-17 digits separated by spaces

Pattern 10-17 digits:
Either 3 or 10 digits
A space
Three digits
A space
Four digits

Checksum Yes

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_uk_nhs_number finds content
that matches the pattern.
One of the following is true:
A keyword from Keyword_uk_nhs_number
is found.
A keyword from
Keyword_uk_nhs_number1 is found.
A keyword from
Keyword_uk_nhs_number_dob is found.
The checksum passes.

&lt;!-- U.K. NHS Number --&gt;

&lt;Entity id=&quot;3192014e-2a16-44e9-aa69-
4b20375c9a78&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;85&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_uk_nhs_number&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_uk_nhs_number&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_uk_nhs_number1&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_uk_nhs_number_dob&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO R KEYWO R KEYWO R

D_UK_NH D_UK_NH D_UK_NH
S_NUM B S_NUM B S_NUM B
ER ER1 ER_DO B

national patient GP
health id
service DOB
patient
nhs identific D.O.B
ation Date of
health
services patient Birth
authorit no Birth
y Date
patient
health number
authorit
y

U.K. National Insurance Number (NINO)

Availability Exchange Online, Exchange Server 2013

Format 7 characters or 9 characters separated by spaces or

dashes
Pattern Two possible patterns:
Two letters (valid NINOs use only certain
characters in this prefix, which this pattern
validates; not case sensitive)
Six digits
Either 'A', 'B', 'C', or 'D' (like the prefix, only certain
characters are allowed in the suffix; not case
sensitive)
OR
Two letters
A space or dash
Two digits
A space or dash
Two digits
A space or dash
Two digits
A space or dash
Either 'A', 'B', 'C', or 'D'

Checksum No
Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_uk_nino finds content that
matches the pattern.
A keyword from Keyword_uk_nino is found.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_uk_nino finds content that
matches the pattern.
No keyword from Keyword_uk_nino is found.

&lt;!-- U.K. NINO --&gt;

&lt;Entity id=&quot;16c07343-c26f-49d2-a987-
3daf717e94cc&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_uk_nino&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_uk_nino&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_uk_nino&quot; /&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_uk_nino&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_UK_NINO

national insurance number

national insurance contributions
protection act
insurance
social security number
insurance application
medical application
social insurance
medical attention
social security
great britain
insurance

U.S. / U.K. Passport Number

Availability Exchange Online, Exchange Server 2013

Format Nine digits

Pattern Nine consecutive digits

Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_usa_uk_passport finds
content that matches the pattern.
A keyword from Keyword_passport is found.

&lt;Entity id=&quot;178ec42a-18b4-47cc-85c7-
d62c92fd67f8&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_usa_uk_passport&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_passport&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_PASSPO RT

Passport Number
Passport No
Passport #
Passport#
PassportID
Passportno
passportnumber
パスポート

パスポート番号

パスポートの Num

パスポート＃

Numéro de passeport
Passeport n °
Passeport Non
Passeport #
Passeport#
PasseportNon
Passeportn °

U.S. Bank Account Number

Availability Exchange Online, Exchange Server 2013

Format 8-17 digits

Pattern 8-17 consecutive digits

Checksum No
Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The regular expression
Regex_usa_bank_account_number finds content
that matches the pattern.
A keyword from Keyword_usa_Bank_Account is
found.

&lt;!-- U.S. Bank Account Number --&gt;

&lt;Entity id=&quot;a2ce32a8-f935-4bb6-8e96-
2a5157672e2c&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Regex_usa_bank_account_number&quot;
/&gt;
&lt;Match
idRef=&quot;Keyword_usa_Bank_Account&quot; /&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_USA_BANK_ACCO UNT

Checking Account Number

Checking Account
Checking Account #
Checking Acct Number
Checking Acct #
Checking Acct No.
Checking Account No.
Bank Account Number
Bank Account #
Bank Acct Number
Bank Acct #
Bank Acct No.
Bank Account No.
Savings Account Number
Savings Account.
Savings Account #
Savings Acct Number
Savings Acct #
Savings Acct No.
Savings Account No.
Debit Account Number
Debit Account
Debit Account #
Debit Acct Number
Debit Acct #
Debit Acct No.
Debit Account No.

U.S. Driver's License Number

Availability Exchange Online, Exchange Server 2013

Format Depends on the state

Pattern Depends on the state -- for example, New York:

Nine digits formatted like ddd ddd ddd will match.
Nine digits like ddddddddd will not match.
Checksum No

Definition A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_new_york_drivers_license_number finds
content that matches the pattern.
A keyword from
Keyword_[state_name]_drivers_license_name
is found.
A keyword from Keyword_us_drivers_license is
found.
A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function
Func_new_york_drivers_license_number finds
content that matches the pattern.
A keyword from
Keyword_[state_name]_drivers_license_name
is found.
A keyword from
Keyword_us_drivers_license_abbreviations is
found.
No keyword from Keyword_us_drivers_license
is found.

&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_new_york_drivers_license_number
&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_new_york_drivers_license_nam
e&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_us_drivers_license&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_new_york_drivers_license_number
&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_new_york_drivers_license_nam
e&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_us_drivers_license_abbreviat
ions&quot; /&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Keyword_us_drivers_license&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
Keywords

KEYWO R KEYWO R
D_US_DR D_[STAT
IVERS_LI KEYWO R E_NAM E]
CENSE_A D_US_DR _DRIVER
BBREVIA IVERS_LI S_LICENS
TIO NS CENSE E_NAM E

DL DriverLi State
c abbrevi
DLS ation
DriverLi (for
CDL cs exampl
CDLS DriverLi e, "NY")
ID cense State
IDs DriverLi name
censes (for
DL# exampl
Driver e, "New
DLS# Lic York")
CDL# Driver
CDLS# Lics

ID# Driver
License
IDs#
Driver
ID License
number s
ID Drivers
number Lic
s
Drivers
LIC Lics
LIC# Drivers
License
Drivers
License
s
Drivers
Lic
Drivers
Lics
Drivers
License
Drivers
License
s
Driver'L
ic
Driver'L
ics
Driver'L
icense
Driver'L
icenses
Driver'
Lic
Driver'
Lics
Driver'
License
Driver'
License
s
Driver's
Lic
Driver's
Lics
Driver's
License
Driver's
License
s
Driver's
Lic
Driver's
Lics
Driver's
License
Driver's
License
s
identific
ation
number
identific
ation
number
s
identific
ation #
id card
id
cards
identific
ation
card
identific
ation
cards
DriverLi
c#
DriverLi
cs#
DriverLi
cense#
DriverLi
censes
#
Driver
Lic#
Driver
Lics#
Driver
License
#
Driver
License
s#
Drivers
Lic#
Drivers
Lics#
Drivers
License
#
Drivers
License
s#
Drivers
Lic#
Drivers
Lics#
Drivers
License
#
Drivers
License
s#
Driver'L
ic#
Driver'L
ics#
Driver'L
icense#
Driver'L
icenses
#
Driver'
Lic#
Driver'
Lics#
Driver'
License
#
Driver'
License
s#
Driver's
Lic#
Driver's
Lics#
Driver's
License
#
Driver's
License
s#
Driver's
Lic#
Driver's
Lics#
Driver's
License
#
Driver's
License
 s#
id
card#
id
cards#
identific
ation
card#
identific
ation
cards#

U.S. Individual Taxpayer Identification Number (ITIN)

Availability Exchange Online, Exchange Server 2013

Format Nine digits that start with a "9" and contain a "7" or "8" as
the fourth digit, optionally formatted with spaces or
dashes

Pattern Formatted:
The digit "9"
Two digits
A space or dash
A "7" or "8"
A digit
A space, or dash
Four digits
Unformatted:
The digit "9"
Two digits
A "7" or "8"
Five digits

Checksum No

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_formatted_itin finds content
that matches the pattern.
At least one of the following is true:
A keyword from Keyword_itin is found.
The function Func_us_address finds an
address in the right date format.
 The function Func_us_date finds a date
in the right date format.
A keyword from
Keyword_itin_collaborative is found.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_unformatted_itin finds
content that matches the pattern.
At least one of the following is true:
A keyword from
Keyword_itin_collaborative is found.
The function Func_us_address finds an
address in the right date format.
The function Func_us_date finds a date
in the right date format.

&lt;!-- U.S. Individual Taxpayer Identification

Number (ITIN) --&gt;
&lt;Entity id=&quot;e55e2a32-f92d-4985-a35d-
a0b269eb687b&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_formatted_itin&quot; /&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_itin&quot; /&gt;
&lt;Match
idRef=&quot;Func_us_address&quot; /&gt;
&lt;Match
idRef=&quot;Func_us_date&quot; /&gt;
&lt;Match
idRef=&quot;Keyword_itin_collaborative&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_unformatted_itin&quot; /&gt;
&lt;Match idRef=&quot;Keyword_itin&quot;
/&gt;
&lt;Any minMatches=&quot;1&quot;&gt;
&lt;Match
idRef=&quot;Keyword_itin_collaborative&quot;
/&gt;
&lt;Match
idRef=&quot;Func_us_address&quot; /&gt;
&lt;Match
idRef=&quot;Func_us_date&quot; /&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;/Entity&gt;
 Keywords

KEYWO RD_ITIN
_CO LL ABO RATI
KEYWO RD_ITIN VE

taxpayer License
tax id DL
tax DOB
identification
Birthdate
itin
Birthday
ssn
Date of Birth
tin
social
security
tax payer
itins
taxid
individual
taxpayer

U.S. Social Security Number (SSN)

Availability Exchange Online, Exchange Server 2013

Format 9 digits, which may be in a formatted or unformatted

pattern

NOTE
If issued before mid-2011, an SSN has strong
formatting where certain parts of the number must fall
within certain ranges to be valid (but there's no
checksum).

Pattern Four functions look for SSNs in four different patterns:

Func_ssn finds SSNs with pre-2011 strong
formatting that are formatted with dashes or
spaces (ddd-dd-dddd OR ddd dd dddd)
Func_unformatted_ssn finds SSNs with pre-
2011 strong formatting that are unformatted as
nine consecutive digits (ddddddddd)
Func_randomized_formatted_ssn finds post-
2011 SSNs that are formatted with dashes or
spaces (ddd-dd-dddd OR ddd dd dddd)
Func_randomized_unformatted_ssn finds post-
2011 SSNs that are unformatted as nine
consecutive digits (ddddddddd)
Checksum No

Definition A DLP policy is 85% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_ssn finds content that
matches the pattern.
A keyword from Keyword_ssn is found.
A DLP policy is 75% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_unformatted_ssn finds
content that matches the pattern.
A keyword from Keyword_ssn is found.
A DLP policy is 65% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_randomized_formatted_ssn
finds content that matches the pattern.
A keyword from Keyword_ssn is found.
The function Func_ssn does not find content
that matches the pattern.
A DLP policy is 55% confident that it's detected this type
of sensitive information if, within a proximity of 300
characters:
The function Func_randomized_unformatted_ssn
finds content that matches the pattern.
A keyword from Keyword_ssn is found.
The function Func_unformatted_ssn does not
find content that matches the pattern.
 &lt;!-- U.S. Social Security Number (SSN) --
&gt;
&lt;Entity id=&quot;a44669fe-0d48-453d-a9b1-
2cc83f2cba77&quot;
patternsProximity=&quot;300&quot;
recommendedConfidence=&quot;75&quot;&gt;
&lt;Pattern
confidenceLevel=&quot;85&quot;&gt;
&lt;IdMatch idRef=&quot;Func_ssn&quot;
/&gt;
&lt;Match idRef=&quot;Keyword_ssn&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;75&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_unformatted_ssn&quot; /&gt;
&lt;Match idRef=&quot;Keyword_ssn&quot;
/&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;65&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_randomized_formatted_ssn&quot;
/&gt;
&lt;Match idRef=&quot;Keyword_ssn&quot;
/&gt;
&lt;Any minMatches=&quot;0&quot;
maxMatches=&quot;0&quot;&gt;
&lt;Match idRef=&quot;Func_ssn&quot;
/&gt;
&lt;/Any&gt;
&lt;/Pattern&gt;
&lt;Pattern
confidenceLevel=&quot;55&quot;&gt;
&lt;IdMatch
idRef=&quot;Func_randomized_unformatted_ssn&quot
; /&gt;
&lt;Match idRef=&quot;Keyword_ssn&quot;
/&gt;
&lt;Any minMatches=&quot;0&quot;
Keywords maxMatches=&quot;0&quot;&gt;
&lt;Match
idRef=&quot;Func_unformatted_ssn&quot; /&gt;
&lt;/Any&gt;
KEYWO RD_SSN
&lt;/Pattern&gt;
&lt;/Entity&gt;
Social Security
Social Security#
Soc Sec
SSN
SSNS
SSN#
SS#
SSID
 DLP policy templates Exchange 2013
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use data loss prevention (DLP ) policy templates to get started with your DLP solution in Microsoft
Exchange 2013. A DLP policy template is a model for a policy. You can select a template to begin the process of
building your own customized DLP policy. Within your DLP policy, you can customize the rules to ensure that it
meets your business needs for data loss prevention. Several policy templates are supplied by Microsoft, but these
are not the only way to implement a data loss prevention solution in Exchange.
Looking for management tasks related to DLP policy templates? See DLP Procedures.

Extend the templates and information types to meet your needs

You can incorporate sensitive-content definitions and policy templates from Microsoft Partners or from files that
you develop yourself as an addition to the DLP policy templates, information types, and rules already provided in
Exchange 2013. Presented here are several ways in which you can add your own unique DLP content and extend
DLP functionality. The templates already provided by Microsoft are a convenient method to get started with a DLP
solution. In order to extend the DLP features with your own unique DLP policy template files, you must
understand the XML schema requirements for policy templates that are created independent of Exchange. To learn
more about the Exchange Management Shell cmdlets associated with DLP policy templates, see cmdlets related to
Get-DlpPolicyTemplate in Messaging Policy and Compliance Cmdlets. Furthermore, you can define your own
sensitive content types after you understand the format and procedure to incorporate them. To learn more about
the Exchange Management Shell cmdlets associated with DLP policy templates, see cmdlets related to
Get-ClassificationRuleCollection in Messaging Policy and Compliance Cmdlets.

Cau t i on

You should turn on your DLP policies in test mode before enforcing them in your production environment. During
such tests, we recommended that you configure sample user mailboxes and send test messages that invoke your
test policies in order to confirm the results.
Create your own new DLP policy template or your own sensitive information types in a classification rule
package
You can create a DLP policy template file apart from Exchange that meets the specific XML schema definition
provided by Microsoft and then import the file into your system so that you can create DLP policies from it. By
creating your own template files, you can define your own model for DLP policies that Microsoft has not already
provided. This is different than creating a DLP policy by using the Exchange admin center, which typically happens
after policy templates are available. If you create a policy template independent of Exchange, you will need to
import it before you can use it to scan messages. You can also create your own sensitive information definitions
apart from those defined by Microsoft in Exchange. There is a separate XML schema definition for DLP policy
template files and classification rule packages. To get started with this, see the following information:

Define your own DLP templates and information types

Import a custom DLP policy template from a file

Include DLP functionality with existing transport rules

You can incorporate DLP detection capabilities with traditional transport rules without creating a new DLP policy.
If you have created a complex set of rules in a previous version of Exchange, and you want to duplicate them or
add sensitive information detection in Exchange 2013, then you can use the transport rules editor in the Exchange
admin center or the Exchange management shell to incorporate these two features. To get started with this, see the
following information:
Transport Rules
Transport rules
Manage transport rules in Exchange 2013
Messaging Policy and Compliance Cmdlets
Use DLP policies created by Microsoft
Numerous DLP policies are supplied by Microsoft. This is the easiest way to get started with a DLP solution that is
flexible and simple to implement. You can always use the provided policies as a starting point and customize them
further to meet your requirements. To get started with this, see the following information:
DLP policy templates supplied in Exchange 2013
Create a DLP policy from a template

For more information

Data loss prevention
 DLP policy templates supplied in Exchange 2013
5/30/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can use data loss prevention (DLP ) policy templates as a starting point
for building DLP policies that help you meet your specific regulatory and business policy needs. You can modify
the templates to meet the specific needs of your organization.
Cau t i on

You should enable your DLP policies in test mode before running them in your production environment. During
such tests, it is recommended that you configure sample user mailboxes and send test messages that invoke your
test policies in order to confirm the results. > Use of these policies does not ensure compliance with any
regulation. After your testing is complete, make the necessary configuration changes in Exchange so the
transmission of information complies with your organization's policies. For example, you might need to configure
TLS with known business partners or add more restrictive transport rule actions, such as adding rights protection
to messages that contain a certain type of data.

Templates available for DLP

The following table lists the DLP policy templates in Exchange. To learn more about customizing these templates
to create DLP policies, see Manage DLP policies.

TEMPLATE DESCRIPTION

Australia Financial Data Helps detect the presence of information commonly

considered to be financial data in Australia, including credit
cards, and SWIFT codes.

Australia Health Records Act (HRIP Act) Helps detect the presence of information commonly
considered to be subject to the Health Records and
Information Privacy (HRIP) act in Australia, like medical
account number and tax file number.

Australia Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
Australia, like tax file number and driver's license.

Australia Privacy Act Helps detect the presence of information commonly

considered to be subject to the privacy act in Australia, like
driver's license and passport number.

Canada Financial Data Helps detect the presence of information commonly

considered to be financial data in Canada, including bank
account numbers and credit cards.

Canada Health Information Act (HIA) Helps detect the presence of information subject to Canada
Health Information Act (HIA) for Alberta, including data like
passport numbers and health information.
TEMPLATE DESCRIPTION

Canada Personal Health Act (PHIPA) - Ontario Helps detect the presence of information subject to Canada
Personal Health Information Protection Act (PHIPA) for
Ontario, including data like passport numbers and health
information.

Canada Personal Health Information Act (PHIA) - Manitoba Helps detect the presence of information subject to Canada
Personal Health Information Act (PHIA) for Manitoba,
including data like health information.

Canada Personal Information Protection Act (PIPA) Helps detect the presence of information subject to Canada
Personal Information Protection Act (PIPA) for British
Columbia, including data like passport numbers and health
information.

Canada Personal Information Protection Act (PIPEDA) Helps detect the presence of information subject to Canada
Personal Information Protection and Electronic Documents
Act (PIPEDA), including data like passport numbers and
health information.

Canada Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
Canada, like health ID number and social insurance number.

France Data Protection Act Helps detect the presence of information commonly
considered to be subject to the Data Protection Act in France,
like the health insurance card number.

France Financial Data Helps detect the presence of information commonly

considered to be financial information in France, including
information like credit card, account information, and debit
card numbers.

France Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
France, including information like passport numbers.

Germany Financial Data Helps detect the presence of information commonly

considered to be financial data in Germany like EU debit card
numbers.

Germany Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
Germany, including information like driver's license and
passport numbers.

Israel Financial Data Helps detect the presence of information commonly

considered to be financial data in Israel, including bank
account numbers and SWIFT codes.

Israel Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
Israel, like national ID number.
TEMPLATE DESCRIPTION

Israel Protection of Privacy Helps detect the presence of information commonly

considered to be subject to the Protection of Privacy in Israel,
including information like bank account numbers or national
ID.

Japan Financial Data Helps detect the presence of information commonly

considered to be financial information in Japan, including
information like credit card, account information, and debit
card numbers.

Japan Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
Japan, including information like driver's license and passport
numbers.

Japan Protection of Personal Information Helps detect the presence of information subject to Japan
Protection of Personal Information, including data like
resident registration numbers.

PCI Data Security Standard (PCI DSS) Helps detect the presence of information subject to PCI Data
Security Standard (PCI DSS), including information like credit
card or debit card numbers.

Saudi Arabia - Anti-Cyber Crime Law Helps detect the presence of information commonly
considered to be subject to the Anti-Cyber Crime Law in
Saudi Arabia, including international bank account numbers
and SWIFT codes.

Saudi Arabia Financial Data Helps detect the presence of information commonly
considered to be financial data in Saudi Arabia, including
international bank account numbers and SWIFT codes.

Saudi Arabia Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
Saudi Arabia, like national ID number.

U.K. Access to Medical Reports Act Helps detect the presence of information subject to United
Kingdom Access to Medical Reports Act, including data like
National Health Service numbers.

U.K. Data Protection Act Helps detect the presence of information subject to United
Kingdom Data Protection Act, including data like national
insurance numbers.

U.K. Financial Data Helps detect the presence of information commonly

considered to be financial information in United Kingdom,
including information like credit card, account information,
and debit card numbers.

U.K. Personal Information Online Code of Practice (PIOCP) Helps detect the presence of information subject to United
Kingdom Personal Information Online Code of Practice,
including data like health information.
 TEMPLATE DESCRIPTION

U.K. Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
United Kingdom, including information like driver's license and
passport numbers.

U.K. Privacy and Electronic Communications Regulations Helps detect the presence of information subject to United
Kingdom Privacy and Electronic Communications Regulations,
including data like financial information.

U.S. Federal Trade Commission (FTC) Consumer Rules Helps detect the presence of information subject to U.S.
Federal Trade Commission (FTC) Consumer Rules, including
data like credit card numbers.

U.S. Financial Data Helps detect the presence of information commonly

considered to be financial information in United States,
including information like credit card, account information,
and debit card numbers.

U.S. Gramm-Leach-Bliley Act (GLBA) Helps detect the presence of information subject to Gramm-
Leach-Bliley Act (GLBA), including information like social
security numbers or credit card numbers.

U.S. Health Insurance Act (HIPAA) Helps detect the presence of information subject to United
States Health Insurance Portability and Accountability Act
(HIPAA),including data like social security numbers and health
information.

U.S. Patriot Act Helps detect the presence of information commonly subject
to U.S. Patriot Act, including information like credit card
numbers or tax identification numbers.

U.S. Personally Identifiable Information (PII) Data Helps detect the presence of information commonly
considered to be personally identifiable information (PII) in
the United States, including information like social security
numbers or driver's license numbers.

U.S. State Breach Notification Laws Helps detect the presence of information subject to U.S. State
Breach Notification Laws, including data like social security
and credit card numbers.

U.S. State Social Security Number Confidentiality Laws Helps detect the presence of information subject to U.S. State
Social Security Number Confidentiality Laws, including data
like social security numbers.

For more information

Data loss prevention
Create a DLP policy from a template
Sensitive Information Types Inventory
 Policy templates from Microsoft partners in Exchange
2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The data loss prevention (DLP ) features can help you identify and monitor many categories of sensitive
information. As you configure your DLP polices, you have the option to import a file from a source outside
Microsoft Exchange to use as a DLP policy template. Microsoft partner companies can develop and distribute
these types of templates. This topic will be updated with a link to help you find these companies once they are
available.
DLP policy template files that can be imported are XML documents that contain instructions for scanning and
analyzing message data. These templates can contain new sensitive information definitions in classification rule
packages, or they can utilize rule packages that exist within Exchange already. The XML documents must adhere to
a Microsoft-defined XML schema definition. For more information about the schema definition, see Define your
own DLP templates and information types.

For more information

Data loss prevention
Import a custom DLP policy template from a file
 DLP procedures
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can begin using a data loss prevention (DLP ) solution in your messaging environment by using the following
procedures. To learn about concepts and objectives for DLP, see Data loss prevention.
Create a DLP policy from a template Information to help you configure a Microsoft-supplied, pre-built set of
policy rules. Policy templates are an easy way to get started with managing message data that is associated with
several common legal and regulatory requirements.
Create a custom DLP policy Information to help you configure policy rules to meet the specific needs of your
organization which may not be covered in one of the pre-existing DLP templates. The rule conditions that are
available to you in a single policy include all the traditional transport rules in addition to the new sensitive
information types.
Import a custom DLP policy template from a file Information to help you import a file that contains policy
information settings. Policies that are created independent of Exchange as XML files must meet specific format
requirements in order to work correctly.
Manage DLP policies Information to help you view, change, or remove existing data loss prevention policies.
View DLP policy detection reports Track policy violations.

NOTE
Data Loss Prevention is a premium feature that requires an Enterprise Client Access License (CAL).

For more information

Manage policy tips
Create incident reports for DLP policy detections
Learn more about modes for DLP policies and rules
 Manage DLP policies in Exchange 2013
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can view, change, or remove existing data loss prevention (DLP ) policies in Microsoft Exchange, using the
Exchange admin center (EAC ) or the Exchange Management Shell.
For additional management tasks related to DLP, see DLP Procedures.
For more information about the Exchange Management Shell, see Exchange Management Shell.

What do you need to know before you begin?

Estimated time to complete each procedure: 15-60 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Data loss prevention (DLP )" entry in the Messaging policy and compliance
permissions topic.
For any DLP policy, you can select one of three modes:
Enforce: Rules within the policy are evaluated for all messages and supported file types. Mail flow
can be disrupted if data is detected that meets the conditions of the policy. All actions described
within the policy are taken.
Test DLP policy with Policy Tips: Rules within the policy are evaluated for all messages and
supported file types. Mail flow will not be disrupted if data is detected that meets the conditions of
the policy. That is, messages are not blocked. If Policy Tips are configured, they are shown to users.
Test DLP policy without Policy Tips: Rules within the policy are evaluated for all messages and
supported file types. Mail flow will not be disrupted if data is detected that meets the conditions of
the policy. That is, messages are not blocked. If Policy Tips are configured, they are not shown to
users.
An individual rule within a DLP policy can have its own mode settings. When the mode of a policy is
different than the mode of a rule within that policy, the rule setting has priority and will be evaluated
according to its mode.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

View the details of an existing DLP policy

You may need to view the rules and actions of an existing DLP policy that you have already established for your
organization. This can be useful if you experience unexpected mail flow issues or if your organization changes the
way sensitive information needs to be monitored.
Use the EAC to view the details within an existing DLP policy
1. In the EAC, navigate to Compliance management > Data loss prevention.
2. Double-click one of the policies that appear in your list of policies, or highlight one item and click Edit .
3. On the Edit DLP policy page, click Rules.

TIP
You can create a DLP policy and leave it in a non-activated or disabled mode. In this mode, a policy is not enforced and you
can change any predicates, actions, or values associated with its rules before you test or begin enforcing it.

Use the Shell to view the details within an existing DLP policy
This example returns information about the fictitious DLP policy named Employee Numbers. The command is
piped to the Format-List cmdlet to display the detailed configuration of the specified DLP policy.

Get-DlpPolicy "Employee Numbers" | Format-List

For syntax and parameter information, see Get-DlpPolicy.

Change a DLP policy

You can change an existing DLP policy by modifying either the name of the policy or the rules that govern the
effects of the policy. An example rule change might include adding custom disclaimer text to a message body and
RMS protection for messages sent within a specific domain and that are detected to have sensitive information. If
you are using DLP policy templates, keep in mind that these are only one of the features in Exchange 2013 that
can help you design and apply a robust policy and compliance system for your messaging environment.
Use the EAC to change an existing DLP policy
1. In the EAC, navigate to Compliance management > Data loss prevention.
2. Double-click one of the template-based policies that appear in your list of policies or highlight one item
and click Edit .
3. On the Edit DLP policy page, click Rules.
4. To change an existing rule, highlight the rule and click Edit .
5. To add a new blank rule that you can fully customize, click New .
6. To add a rule about sender notification, blocking messages, or allowing overrides, click the arrow next to
the New icon.
7. To remove a rule, highlight the rule and click Delete .
8. Click Save to finish modifying the policy and save your changes.
Use the Shell to change an existing DLP policy
You can specify the action and notification level of a policy using the Exchange Management Shell. This example
sets the mode for a fictitious DLP policy named Employee Numbers so that the actions are not enforced and
notification messages are not displayed.

Set-DlpPolicy "Employee Numbers" -Mode Audit

For syntax and parameter information, see Set-DlpPolicy.

Delete a DLP policy
You can permanently remove a DLP policy using the EAC. Once you've deleted a policy, it will no longer be
enforced and none of the rules and actions will be saved.
Alternatively, you can set the operational state or mode of a policy to Test DLP policy without Policy Tips. This
stops it from being enforced in your message environment, but preserves the detailed configuration settings of
the policy itself. This can be useful if there is a possibility that you will need to enforce the policy again in the
future.
Use the EAC to delete an existing DLP policy
1. In the EAC, navigate to Compliance management > Data loss prevention.
2. Select the policy you want to remove in your list of policies, and then click Delete .
Use the Shell to delete an existing DLP policy
This example removes the fictitious DLP policy named Employee Numbers.

Remove-DlpPolicy "Employee Numbers"

For syntax and parameter information, see Remove-DlpPolicy.

For more information

Data loss prevention
Policy Tips
 Create a DLP policy from a template in Exchange
2013
5/30/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange, you can use data loss prevention (DLP ) policy templates to help meet the messaging
policy and compliance needs of your organization. These templates contain pre-built sets of rules that can help
you manage message data that is associated with several common legal and regulatory requirements. To see a list
of all the templates supplied by Microsoft, see DLP policy templates supplied in Exchange 2013. Example DLP
templates that are supplied can help you manage:
Gramm-Leach-Bliley Act (GLBA) data
Payment Card Industry Data Security Standard (PCI-DSS )
United States Personally Identifiable Information (U.S. PII)
You can customize any of these DLP templates or use them as-is. DLP policy templates are built on top of
transport rules that include new conditions or predicates and actions. DLP policies support the full range of
traditional transport rules, and you can add the additional rules after a DLP policy has been established.
For more information about policy templates, see DLP policy templates in Exchange 2013.
To learn more about transport rule capabilities, see Transport rules in Exchange 2013.
Once you have started enforcing a policy, you can learn about how to observe the results by reviewing View DLP
policy detection reports.
Cau t i on

You should enable your DLP policies in test mode before running them in your production environment. During
such tests, it is recommended that you configure sample user mailboxes and send test messages that invoke your
test policies in order to confirm the results.

What do you need to know before you begin?

Estimated time to complete: 30 minutes
Ensure that Exchange Server is set up as described in Planning and Deployment.
Configure both administrator and user accounts within your organization and validate basic mail flow.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Data loss prevention (DLP )" entry in the Messaging policy and compliance
permissions topic
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Use the EAC to configure a DLP policy from a template
1. In the EAC, navigate to Compliance management > Data loss prevention, and then click Add .

NOTE
You can also select this action if you click the arrow next to the Add icon and select New DLP policy from
template from the drop down menu.

2. On the Create a new DLP policy from a template page, complete the following fields:
a. Name: Add a name that will distinguish this policy from others.
b. Description: Add an optional description that summarizes this policy.
c. Choose a template: Select the appropriate template to begin creating a new policy.
d. More options: Select the mode or state. The new policy is not fully enabled until you specify that it
should be. The default mode for a policy is test without notifications.
e. Click Save to finish creating the policy.

NOTE
In addition to the rules within a specific template, your organization may have additional expectations or company policies
that apply to regulated data within your messaging environment. Exchange 2013 makes it easy for you to change the basic
template in order to add actions so that your Exchange messaging environment complies with your own requirements.

You can modify policies by editing the rules within them once the policy has been saved in your Exchange 2013
environment. An example rule change might include making specific people exempt from a policy or sending a
notice and blocking message delivery if a message is found to have sensitive content. For more information about
editing policies and rules, see Manage DLP policies.
You have to navigate to the specific policy's rule set on the Edit DLP policy page and use the tools available on
that page in order to change a DLP policy you have already created in Exchange 2013.
Some policies allow the addition of rules that invoke RMS for messages. You must have RMS configured on the
Exchange server before adding the actions to make use of these types of rules.
For any of the DLP policies, you can change the rules, actions, exceptions, enforcement time period or whether
other rules within the policy are enforced and you can add your own custom conditions for each.

For more information

Data loss prevention
DLP policy templates in Exchange 2013
 Create a custom DLP policy in Exchange 2013
5/30/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

A custom data loss prevention (DLP ) policy allows you to establish conditions, rules, and actions that can help
meet the specific needs of your organization, and which may not be covered in one of the pre-existing DLP
templates.
The rule conditions that are available to you in a single policy include all the traditional transport rules in addition
to the sensitive information types presented in Sensitive Information Types Inventory. For more information
about transport rules, Transport rules in Exchange 2013.
Cau t i on

You should enable your DLP policies in test mode before running them in your production environment. During
such tests, it is recommended that you configure sample user mailboxes and send test messages that invoke your
test policies in order to confirm the results. for more information about testing, see Test a transport rule in
Exchange 2013.
For additional management tasks related to creating a custom DLP policy, see DLP procedures.

What do you need to know before you begin?

Estimated time to complete: 60 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Data loss prevention (DLP )" entry in the Messaging policy and compliance
permissions topic.
In order to create a new custom DLP policy, you must follow the installation instructions for Exchange
Server. For more information about deployment, see Planning and Deployment.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

NOTE
Due to the variances in customer environments, Microsoft Customer Support Services (CSS) cannot participate in the
development or testing of custom Regular Expression scripts ("RegEx scripts"). For RegEX custom script development, testing
and debugging, customers will need to rely upon internal IT resources. Alternatively, customers may choose to use an
external consulting resource such as Microsoft Consulting Services (MCS). Regardless of the script development resource,
CSS EXO and EOP support engineers are not available to assist customers with custom RegEx script inquiries.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create a custom DLP policy without any existing rules
1. In the EAC, navigate to Compliance management > Data loss prevention. Any existing policies that
you have configured are shown in a list.
2. Click the arrow that is beside the Add icon, and select New custom policy.

IMPORTANT
If you click Add icon instead of the arrow, you will create a new policy based on a template. For more information
about using templates, see Create a DLP policy from a template.

3. On the New custom policy page, complete the following fields:

a. Name Add a name that will distinguish this policy from others.
b. Description Add an optional description that summarizes this policy.
c. Choose a state Select the mode or state for this policy. The new policy is not fully enabled until you
specify that it should be. The default mode for a policy is test without notifications.
d. Click Save to finish creating the new policy reference information. The policy is added to the list of
all policies that you have configured, although there are not yet any rules or actions associated with
this new custom policy.
e. Double-click the policy that you just created or select it and click Edit .
f. On the Edit DLP policy page, click Rules.
Click Add to add a new blank rule. You can establish conditions using all the traditional transport
rules in addition to the sensitive information types.
In order to avoid confusion, supply a unique name for each part of your policy or rule when you
have the option to provide your own character string. There are several options additional options
available to you:
a. Click the arrow that is beside the Add icon to add a rule about sender notification or
allowing overrides.
b. To remove a rule, highlight the rule and click Delete .
c. Click More options to add additional conditions and actions for this rule including time-
bound limits of enforcement or effects on other rules in this policy.
g. Click Save to finish modifying the policy and save your changes.
DLP policy templates are one type of feature Microsoft Exchange that can help you design and apply a robust
policy and compliance system for your messaging environment. For more information about compliance features,
see Messaging policy and compliance.

For more information

Data loss prevention
Transport rules in Exchange 2013
Integrating sensitive information rules with transport rules
 Import a custom DLP policy template from a file in
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can manage sensitive information through DLP policies by importing a file that contains policy information
settings. DLP policy templates can be developed independent of Exchange as XML files. However, they must
meet specific format requirements in order to work correctly. Alternatively, policies that are exported from a
previous version of Exchange can be imported into Microsoft Exchange Server 2013.
Cau t i on

You should enable your DLP policies in test mode before running them in your production environment. During
such tests, it is recommended that you configure sample user mailboxes and send test messages that invoke your
test policies in order to confirm the results.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Data loss prevention (DLP )" entry in the Messaging policy and compliance
permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to import a custom DLP policy template from a file
Use the following procedure to import a custom DLP policy template from a file. In order to avoid confusion,
supply a unique name for each part of your policy or rule when you have the option to provide your own name.
1. In the EAC, navigate to Compliance management > Data loss prevention.
2. Click the arrow that is next to the Add icon, then click Import policy.
3. On the Import policy page, complete the following fields:
4. Select the file to import Add the name of the policy file you want to install.
5. Name Add a name that will distinguish this policy from others.
6. Description Optionally, add a description that summarizes this policy.
7. More options Select the mode or state for this policy. The new policy is not fully enabled until you specify
that it should be. The default mode for a policy is test without notifications.
8. Click Next to validate and import the policy.
Use the Shell to import a custom DLP policy template from a file
This example imports a custom DLP policy template file in the file C:\My Documents\DLP Backup.xml. Importing
a DLP policy collection from an XML file removes or overwrites all pre-existing DLP policies that were defined in
your organization. Make sure that you have a backup of your current DLP policy collection before you import and
overwrite your current DLP policies.

Import-DlpPolicyCollection -FileData ([Byte[]]$(Get-Content -Path " C:\My Documents\DLP Backup.xml " -

Encoding Byte -ReadCount 0))

For more information

Data loss prevention
 View DLP policy detection reports
5/28/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Data loss prevention (DLP ) policy detection management broadly defines the activities that an organization
performs in order to identify, investigate, and resolve DLP policy violations. In order to manage incidents, you
need access to information that identifies what was detected by your DLP policies. This detection information is
integrated with existing Microsoft Exchange Server 2013 data and log formats so that you can leverage an existing
rich system of data to manage your mail flow incidents.
For information about creating an incident report along with a single policy detection event, see Create incident
reports for DLP policy detections. For more information about message logs, see Track messages with delivery
reports.

NOTE
Exchange 2013: DLP is a premium feature that requires an Exchange Enterprise Client Access License (CAL). For more
information about CALs and server licensing, see Exchange Server Licensing.

Audit information
Data related to DLP detection management in Exchange is integrated into the message tracking logs, also known
as delivery reports. The capabilities reuse much of the existing logging framework available in the system. For
general information, including understanding the structure of the message tracking log files, please review existing
content in Understanding Message Tracking or Track messages with delivery reports .
The delivery report is a detailed log of all message activity as messages are transferred to and from a computer
that is running the Transport service on a Mailbox server. The message tracking log can be accessed through the
Exchange Management Shell by using the Get-MessageTrackingLog cmdlet. DLP data is integrated into the
delivery report following existing data formats and conventions.

Data logging format

Message tracking logs contain data from the agents involved in processing the mail flow content. For DLP, the
transport rule agent (TRA) is used to invoke deep message content scanning and to apply the policies defined as
part of the ETRs. The existing AgentInfo Event is used to add DLP related entries in the message tracking log.
The agent name will be TRA or Transport Rule Agent in the AgentInfo event. A single AgentInfo event will be
logged per message describing the DLP processing applied to the message. The CustomData field of the
message tracking log entry field is where the DLP data logged by the transport rule agent will appear. This field
may contain multiple entries: one data classification and client information line for each data classification found in
the message, one rule line for each rule that applies to the message, and one health monitoring line for each rule
that exceeds the load or execution time threshold.
An example of the DLP log entry is displayed here. The output has been formatted to display strings in separate
lines with new lines between.
Source: AGENT
EventId: AGENTINFO
CustomData: S:TRA=DC|dcid=41BFDBC6C9D811E0816A3CD34824019B|count=10|conf=77;
S:TRA=DC|dcid=C7ECCBA0CA0011E0B6C00B124924019B|count=3|conf=81;
S:TRA=CI|sndOverride=or|just=Business Reason;
S:TRA=CI|sndOverride=fp;
S:TRA=ETR|ruleId=FC2AA60C9D811E0AFC076D34824019B|dlpid=1B81CC82C9DB11E09052C5D64824019
B|st=2010-11-03
15:30T|action=PrependSubject|action=Encrypt|sev=2|mode=audit|dcid=41BFDBC6C9D811E0816A3CD348240
19B|sndOverride=or;
S:TRA=ETR|ruleId=AB2AA60C9D811E0AFC076D34824019B|dlpid=1B81CC82C9DB11E09052C5D64824019
B|st=2010-11-03
15:30T|action=Encrypt|sev=1|mode=enabled|dcid=C7ECCBA0CA0011E0B6C00B124924019B|sndOverride=fp;
S:TRA=ETRP|ruleId=C27D21EECA0311E0BCB896154924019B|LoadW=200|LoadC=100|ExecW=5500|ExecC=
200;
The Transport Rule Agent requires grouping of the rule ID, DLP Policy ID (optional), last modified date, action,
severity, mode, detected data classification (optional), and sender override (optional) based on rule ID (indicated
by "TRA=ETR" in the log line). It also requires the data classification ID, count, and confidence level of
classifications to be grouped by classification name (indicated by "TRA=DC" in the log line).
Additional groupings include data classification ID, sender override (optional), and override justification (optional)
based on data classification ID for all classifications that were detected on the client (indicated by "TRA=CI" in the
log line). The Transport Rule Agent also requires the rule ID, load Wall clock (optional), load CPU clock (optional),
execution Wall clock (optional), and execution CPU clock (optional) be grouped by rule ID for all rules that exceed
the load or execution Wall or CPU clock thresholds (indicated by "TRA=ETRP" in the log line).
The following is a complete list of the data fields. All data in the MTL is type string. Format column describes how
to recognize each field in the Message Tracking Log. Optional Field column specifies what fields might not be
logged when a rule matches. DLP Specific column shows what fields are specific to the DLP feature.

Field name Description Format Optional field DLP specific

TRA Transport Rule TRA=DC, ETR, CI, Mandatory No

Agent; type or ETRP
AgentName

DC Data TRA=DC Optional Yes

Classification;
type groupName

ETR Exchange TRA=ETR Mandatory No

Transport Rule;
type groupName

CI Client TRA=CI Optional Yes

Information, type
groupName
ETRP Exchange TRA=ETRP Optional No
Transport Rule
Performance;
type groupName

dcid ID of the Data dcid=GUID Optional Yes

Classification

count Count of the count=Integer Optional Yes

Data
Classification

conf Confidence level conf=Integer Optional Yes

of the Data (Percent)
Classification

sndOverride Sender override; sndOverride=or Optional Yes

the field is or fp
optional.
Where "or"
In the TRA=CI represents
line, when field is override and "fp"
set to "or" means false
signifies the data positive. The
classification was sndOverride field
overridden. If the is present when
field is set to "fp" an end-user had
signifies the data reported either
classification was an override or
reported as a false positive for a
false positive. rule.
In the TRA=ETR
line, when the
field is set to "or"
signifies the rule
or part of the rule
was overridden. If
the field is set to
"fp" signifies the
rule or part of the
rule was reported
as a false positive.
just Justification; the just=IW input Optional Yes
field is optional justification string
and only available
when the sender Justification field
override field is is only logged
equal to "or" in when end user
the TRA=CI line. reports an
Justification text override.
provided by the
end user as the
reason the data
classification
should be
overridden.

ruleId ID for a rule ruleId=GUID Mandatory No

dlpId ID for a DLP dlpId=GUID Optional Yes

Policy. The field is
optional; if there
is no dlpId then
the rule doesn't
belong to a DLP
Policy.

st Last Modified st=UTC date- Mandatory No

Date of a rule time

action Action taken by a action=single Mandatory No

rule; could have action
multiple actions
per rule If there are
multiple actions
applied for a rule,
there will be
multiple action
fields.

sev Audit severity of sev=1, 2, or 3 Optional No

the rule
Where 1
represents low, 2
is medium, and 3
means high.

mode State of the rule mode=audit, Mandatory No

when it was hit auditandnotify, or
(enforcement, enforcement
audit, or
auditandnotify).

loadW Load Wall Clock; loadW=time in Optional No

the field is ms
optional
 loadC Load CPU Clock; loadC=time in ms Optional No
the field is
optional

execW Execute Wall execW=time in Optional No

Clock; the field is ms
optional

execC Execute CPU execC=time in ms Optional No

Clock; the field is
optional

message-id ID of the message-id=ID of Mandatory No

message message

date-time Date and time date-time=UTC Mandatory No

the message was date-time
sent in universal
time

sender-address Email address sender- Mandatory No

specified in the address=Email
sender field address

recipient-address Email address(es) recipient- Mandatory No

of the message's address=Email
recipient(s) address

message-subject Data found in the message- Mandatory No

subject field of subject=end-user
the message input subject
string

For more information

Data loss prevention
Create incident reports for DLP policy detections
Track messages with delivery reports
 Create incident reports for DLP policy detections
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Exchange Server 2013, you can establish an action to create an incident report within a DLP policy rule set.
Additionally, you can indicate to whom the report should be sent and what to do with the original message. The
incident report can contain any of the following information.

Content of an incident management report

The Generate Incident Report action enables users to send incident reports to an incident management
mailbox. A single incident report will be generated for each message only if the Generate Incident Report action
is applied within a policy.
The following is a complete list of the line names in the incident report template. The format column describes
how to recognize each field in the report. The optional field column specifies what fields might not be in the
Report for each rule match. The DLP specific column shows what fields exist as a result of the DLP feature.

Line name Description Format Optional field DLP specific

Message-Id ID of the original Message-Id: ID of Mandatory No

sent message message

Sender True sender of Sender: Email Mandatory No

the original address of sender
message

Subject Subject of the Subject: end-user Mandatory No

original message input subject
string
To Recipient or To: Email address Mandatory No
recipients of the of recipient
original message
Each To line will
only contain a
single recipient,
and there can be
up to 10
recipients
displayed in the
Incident Report. If
there are
additional
recipients, the
next To line will
display the
remaining
number of
recipients.

CC CC email address CC: Email address Optional No

of the original of CC recipient
message; the line
is optional
Each CC line will
only contain a
single CC email
address, and
there can only be
up to 10 CC
email addresses
that are displayed
in the Incident
Report. If there
are additional CC
addresses, the
next CC line will
display the
remaining
number of CC
email addresses.
BCC BCC email BCC: Email Optional No
address of the address of BCC
original message; recipient
the line is
optional
Each BCC line will
only contain a
single BCC email
address, and
there can only be
up to 10 BCC
addresses that
are displayed in
the Incident
Report. If there
are additional
BCC email
addresses, the
following BCC line
will display the
remaining
number of BCC
email addresses.

Severity Audit severity of Severity: Low, Optional No

the rule hit; Medium, or High
displays the
highest severity if
multiple rules
were hit.

Override Displays if an Override: Yes, Optional Yes

override was Justification: IW
reported for the input justification
message, and the string
justification of the
override if
provided.

False Positive Displays if a false False Positive: Yes Optional Yes

positive was
reported for the
message.
Data Classification Detected data Data Optional Yes
classifications Classification:
found in the sensitive
original message; information type,
the line is Count: instances
optional. of the sensitive
information
Each data found in the
classification line message,
will only contain a Confidence:
single detected percent value,
classification Recommended
along with its Minimum
count, confidence, Confidence:
and percent value
recommended
minimum
confidence level.
Up to 5 detected
classifications will
be displayed in
the Incident
Report. If the
detected
classification was
an affinity, the
count value does
not apply and will
not be shown.

Rule Hit Displays all the Rule Hit: rule Mandatory No

rules that hit the name, DLP Policy:
original message. DLP Policy name
if applicable,
Includes the Action: single
name of the rule action, Data
that was hit, the Classification:
DLP Policy sensitive
(optional) that information type,
the rule resides Definition: rule
in, action(s) that definition if
were taken on applicable
the message
because of the
rule, data
classification(s) in
the rule that
caused the rule to
hit, and the
definition of the
rule.
 ID Match Displays the ID Match: Optional Yes
matched data sensitive
classification, the information type,
exact matched Value: actual
content from the value of the
message, and the sensitive data,
primary evidence Context: text
of the data around the
classification sensitive data in
match; the line is the message
optional.

For more information

View DLP policy detection reports
Data loss prevention
 Define your own DLP templates and information
types in Exchange 2013
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can develop data loss prevention (DLP ) policy templates as XML files independent of Microsoft Exchange
Server 2013 and then import them using the Exchange admin center or the Exchange management shell. This
section describes the process and details of authoring and tuning DLP XML files for use within a DLP solution.
You are not required to develop your own DLP XML files because the Exchange admin center provides a way for
you to get started quickly with existing DLP policy templates and transport rules in order to scan messages.
Looking for management tasks related to DLP policy templates? See DLP procedures.

NOTE
Exchange 2013: DLP is a premium feature that requires an Exchange Enterprise Client Access License (CAL). For more
information about CALs and server licensing, see Exchange Server Licensing.

IMPORTANT
It's beyond the scope of this documentation to recommend a business model or information about file packaging or
deployment guidelines for the sensitive information rules or to discuss how such rules would be distributed. Furthermore,
this documentation does not discuss protection mechanisms, such as encryption, for custom developed rules, nor does it
discuss how such mechanism would be employed.

Extend the information types to meet your needs

The following sections describe concepts and the XML schema definition that you must understand in order to
begin creating your own XML files for both DLP policy templates and sensitive information rule packages that
can be imported into Exchange 2013 and used as DLP policies.
DLP in Microsoft Exchange helps you to apply organizational-specific policy to sensitive information. A key factor
in the strength of a DLP solution is the ability to correctly identify confidential or sensitive information that may
be unique to the organization, regulatory needs, geography, or other aspects of business. Although Microsoft has
provided policy templates and sensitive information types within the product for you to get started, your unique
business needs can require a custom data loss prevention solution. For this reason, Microsoft provides a way for
you to create and import your own DLP policy templates or your own sensitive information definitions within
classification rule packages. An accurate DLP solution relies on configuring the correct set of rules for the
sensitive information detection engine that provide high degree of protection while minimizing false positives
and negatives.

Develop your own DLP policy templates

You can write your own DLP policy template XML file and import it. This approach to extending the DLP solution
provided in Exchange will allow you to build DLP policies that closely match your DLP requirements.
Managing custom templates and their related policies is similar to managing the DLP policies that you create
based on Microsoft-supplied templates. In a typical DLP policy lifecycle, you would do the following:
1. Create your own DLP policy template, a custom XML file. To learn more, see Developing DLP policy
template files.
2. Import your custom template. To learn more, see Import a custom DLP policy template from a file.
3. Create a DLP Policy based on your custom template. To learn more, see Create a DLP policy from a
template.
4. Update your custom template by repeating steps 1 and 2.
5. Remove your custom template. To learn more, see Remove-DlpPolicyTemplate.
For more information about the XML schema definition and concepts related to developing your own templates,
see Developing DLP policy template files.

Develop your own sensitive information types and matching logic in

classification rule packages
You can write your own sensitive information definitions in a classification rule package, which is an XML file, and
import it as part of your DLP solution. The sensitive information detection engine provides the deep content
analysis capabilities for identifying sensitive information like credit card numbers, social security numbers, and
company intellectual property. The engine is controlled by a configurable set of instructions, or rules, for scanning
and analyzing the content. The rules are combined together into a classification rule package, an XML document
that adheres to a standardized rules package XML schema definition. Here's how you can develop your own.
1. Create your own sensitive information types, a custom XML file. To learn more, see Developing sensitive
information rule packages.
2. Import your sensitive information type. To learn more, see New -ClassificationRuleCollection.
3. Create custom template based on your information types. To learn more, see Developing sensitive
information rule packages
4. Update your custom template by repeating steps 1 and 2.
5. Remove your custom template. To learn more, see Remove-ClassificationRuleCollection
For more information about the rule packages, see Developing sensitive information rule packages and Matching
methods and techniques for rule packages.
Understanding rule types in rule packages
The rules within a rule package configure the process for detecting well-defined content characteristics; for
example, rules for finding a driver's license number. Two main rule types are available: Entity and Affinity.
Entity rules are targeted toward well-defined (and oftentimes regulated) identifiers such as U.S. social security
numbers. An Entity is represented by a collection of countable patterns. A pattern defines a collection of matches
with an explicit primary match identifier. An example Entity is a driver's license.
Affinity rules are targeted toward a certain type of document such as a corporate financial statement. An Affinity
is represented as a collection of independent evidences. Evidence is an aggregation of required matches within
certain proximity. An example of an Affinity is the U.S. Sarbanes-Oxley Act.

For more information

Data loss prevention
Import a custom DLP policy template from a file
New -ClassificationRuleCollection
Transport Rules Exchange Server 2013
Sensitive Information Types Inventory
 Developing DLP policy template files in Exchange
2013
6/14/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

This overview explains the components of an XML schema definition for data loss prevention (DLP ) policy
template files and also provides an XML -format example policy file. It will be helpful to understand the overall
DLP architecture and rule-development process before you begin. For more information, see Data loss prevention
and Define your own DLP templates and information types.
In order to make data loss prevention solutions easy to adopt and manage, a conceptual model known as DLP
policies and policy templates is introduced in Microsoft Exchange Server 2013. DLP policy templates provide a
preliminary design for your intended DLP policy. In order to be valuable, a DLP policy template must encapsulate
all the directives and data objects that are required to meet a specific policy objective, such as a regulation or
business need. The template is not environment-specific. It is simply a definition or model of a policy that can be
provided as part of the product configuration or supplied by independent software vendors and partners. DLP
policies on the other hand, are run-time instantiations of the templates that are specific to the deployment
environment. Your existing messaging policy framework can incorporate DLP policies through the use of
transport rules. Transport rules provide great flexibility in adapting and expressing the richness of your DLP
solutions.

Policy template sources and structure

DLP policy templates are typically influenced from multiple sources such as server-based processing directives,
client computer policies, or other policy constructs as shown in the following image:

Simple management operations are available for DLP policy templates though both the Exchange Management
Shell and Internet-based interfaces, such as the Exchange admin center, which include Import, Export, Deletion and
Query capabilities. A DLP policy is created by referencing a DLP policy template as part of the creation process.
These referenced DLP policy templates may be references to ones installed in the system, which are stored in
active directory domain services, or be provided as input directly from externally supplied policies.
DLP policy templates are represented as XML documents. A single XML schema is used for policies provided
within Exchange and externally also. The conceptual structure of the XML document is represented in the table
below, which shows the major elements. The set of policy component definitions help you achieve a specific policy
objective such as a regulation or business need.

STRUCTURAL ELEMENT MEANING OR EXAMPLE

Publisher Microsoft or Partner

 STRUCTURAL ELEMENT MEANING OR EXAMPLE

Version 15.0.1.0

Policy Name PCI-DSS

Description The PCI-DSS DLP policy helps detect the presence of

information subject to PCI Data Security Standard (PCI DSS),
including information like credit card or debit card numbers.
Use of this policy does not ensure compliance with any
regulation. After your testing is complete, make the necessary
configuration changes in Exchange so the transmission of
information complies with your organization's policies.
Examples include configuring TLS with known business
partners or adding more restrictive transport rule actions,
such as adding rights protection to messages that contain this
type of data.

Metadata Tags to describe the local regulation, country or region,

keywords and more.

Set of policy constructs Transport rule definitions, such as conditions and actions.
Email client behavior definitions that control client experience
through interactive notifications.
Optionally, configuration references that need to be
coordinated with client environment-specific settings.

Set of data classifications Specifies classification entities or affinities.

Entities have count and confidence; affinities only have a
confidence.
Comes with its own set of properties and classification
schema.

Policy template format definition

DLP Policy templates are expressed as XML documents which adhere to the following schema. Note that the XML
is case-sensitive. For instance, dlpPolicyTemplates will work, but DlpPolicyTemplates won't work.
 <?xml version="1.0" encoding="UTF-8"?>
<dlpPolicyTemplates>
<dlpPolicyTemplate id="F7C29AEC-A52D-4502-9670-141424A83FAB" mode="Audit" state="Enabled"
version="15.0.2.0">
<contentVersion>4</contentVersion>
<publisherName>Microsoft</publisherName>
<name>
<localizedString lang="en">PCI-DSS</localizedString>
</name>
<description>
<localizedString lang="en">Detects the presence of information subject to Payment Card Industry Data
Security Standard (PCI-DSS) compliance requirements.</localizedString>
</description>
<keywords></keywords>
<ruleParameters></ruleParameters>
<ruleParameters/>
<policyCommands>
<!-- The contents below are applied/executed as rules directly in PS - -->
<commandBlock>
<![CDATA[ new-transportRule "PCI-DSS: Monitor Payment Card Information Sent To Outside" -DlpPolicy
"%%DlpPolicyName%%" -SentToScope NotInOrganization -SetAuditSeverity High -MessageContainsDataClassifications
@{Name="Credit Card Number"; MinCount="1" } -Comments "Monitors payment card information sent to outside the
organization as part of the PCI-DSS DLP Policy."]]>
</commandBlock>
<commandBlock>
<![CDATA[ new-transportRule "PCI-DSS: Monitor Payment Card Information Sent To Within" -DlpPolicy
"%%DlpPolicyName%%" -Comments "Monitors payment card information sent inside the organization as part of the
PCI-DSS DLP Policy." -SentToScope InOrganization -SetAuditSeverity Low -MessageContainsDataClassifications
@{Name="Credit Card Number"; MinCount="1" } ]]>
</commandBlock>
</policyCommands>
<policyCommandsResources></policyCommandsResources>
</dlpPolicyTemplate>
</dlpPolicyTemplates>

If a parameter you include in your XML file for any element includes a space, the parameter has to be surrounded
by double quotes or it will not work properly. In the example below, the parameter that follows -SentToScope is
acceptable and does not include double quotes because it is one continuous string of characters without a space.
However, the parameter provided for - Comments will not appear in the Exchange admin center because there are
no double quotes and it includes spaces.

<CommandBlock><![CDATA[ new-transportRule "PCI-DSS: Monitor Payment Card Information Sent To Within" -

DlpPolicy "PCI-DSS" -Comments Monitors payment card information sent inside the organization -SentToScope
InOrganization -SetAuditSeverity Low -MessageContainsDataClassifications @{Name="Credit Card Number";
MinCount="1" } ]]> </CommandBlock>

localizedString Element
The template format offers the capability to localize strings in the template which may be presented to the end-
user, for example as part of selecting which DLP policy templates are installed. The localizedString element can be
used to supply multiple definitions for the Name and Description fields.
ruleParameters Node
This is an optional set of parameters that need to be supplied during the template instantiation phase when
creating a DLP policy to map to deployment specific objects. For example an actual distribution group that is
available in the deployment.
dlpPolicyTemplate Element
This is the root element for the DLP policy template and is required for every template. Available attributes are
shown in the following table:
 ATTRIBUTE NAME REQUIRED? DESCRIPTION

Version Yes The version number used in this DLP

policy template document.

State No Optional default configuration for the

state of the policy.

Mode No Optional default configuration for the

mode of the policy.

Id No A GUID to uniquely identify this DLP

policy template definition in the
following format:"A29C69BF-4F98-
47F1-9A99-5771DFD2C27F".

Child elements include the following sequence of elements.

CHILD ELEMENT (MINIMUM, MAXIMUM) DESCRIPTION

PublisherName (1, 1) Meta data for the template's publisher

Name (1, 1) Localizable name for this template.

Description (1, 1) Localizable description for this template.

Keywords (1, 1) List of keywords that applies to this

template. A template may have an
empty list of keywords.

RuleParameters (0, 1) List of template parameters that are

used in the policy definition.

PolicyCommands (0, 1) List of Transport rule definitions for this

policy. This is an optional element.

DLP Policy Template: PolicyCommands

This part of the policy template contains the list of the Exchange Management Shell commands that are used to
instantiate the policy definition. The import process will execute each of the commands as part of the instantiation
process. Sample policy commands are provided here.

<PolicyCommands>
<!-- The contents below are applied/executed as rules directly in PS - -->
<CommandBlock> <![CDATA[ new-transportRule "PCI-DSS: Monitor Payment Card Information Sent To Outside" -
DlpPolicy "PCI-DSS" -SentToScope NotInOrganization -SetAuditSeverity High -MessageContainsDataClassifications
@{Name="Credit Card Number"; MinCount="1" } -Comments "Monitors payment card information sent to outside the
organization as part of the PCI-DSS DLP policy."]]></CommandBlock>
<CommandBlock><![CDATA[ new-transportRule "PCI-DSS: Monitor Payment Card Information Sent To Within" -
DlpPolicy "PCI-DSS" -Comments "Monitors payment card information sent inside the organization as part of the
PCI-DSS DLP policy." -SentToScope InOrganization -SetAuditSeverity Low -MessageContainsDataClassifications
@{Name="Credit Card Number"; MinCount="1" } ]]> </CommandBlock>
</PolicyCommands>

The format of the cmdlets is the standard Exchange Management Shell cmdlet syntax for the cmdlets used. The
commands are executed in sequence. It is possible for each of the command nodes to contain a script block which
would be composed of multiple commands. Below is example that illustrates how to embed classification rule pack
inside of a dlp policy template, and installing the rule pack as part of the policy creation process. The classification
rule pack is embedded in the policy template, and then passed as a parameter to the cmdlet in the template:

<CommandBlock>
<![CDATA[
$rulePack = [system.Text.Encoding]::Unicode.GetBytes('<?xml version="1.0" encoding="utf-8"?>
<rulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
<RulePack id="c3f021a3-c265-4dc2-b3a7-41a1800bf518">
<Version major="1" minor="0" build="0" revision="0"/>
<Publisher id="e17451d3-9648-4117-a0b1-493a6d5c73ad"/>
<Details defaultLangCode="en-us">
<LocalizedDetails langcode="en-us">
<PublisherName>Contoso</PublisherName>
<Name>Contoso Sample Rule Pack</Name>
<Description>This is a sample rule package</Description>
</LocalizedDetails>
</Details>
</RulePack>
<Rules>
<Entity id="7cc35258-6b35-4415-baff-a76d1a018980" patternsProximity="300" recommendedConfidence="85"
workload="Exchange">
<Pattern confidenceLevel="85">
<IdMatch idRef="Regex_Contoso" />
<Any minMatches="1">
<Match idRef="Regex_conf" />
</Any>
</Pattern>
</Entity>
<Regex id="Regex_Contoso">(?i)(\bContoso\b)</Regex>
<Regex id="Regex_conf">(?i)(\bConfidential\b)</Regex>
<LocalizedStrings>
<Resource idRef="7cc35258-6b35-4415-baff-a76d1a018980">
<Name default="true" langcode="en-us">
Confidential Information Rule
</Name>
<Description default="true" langcode="en-us">
Sample rule pack - Detects Contoso confidential information
</Description>
</Resource>
</LocalizedStrings>
</Rules>
</RulePackage>
')
New-ClassificationRuleCollection -FileData $rulePack
New-TransportRule -name "customEntity" -DlpPolicy "%%DlpPolicyName%%" -SentToScope NotInOrganization -
MessageContainsDataClassifications @{Name="Confidential Information Rule"} -SetAuditSeverity High]]>
</CommandBlock>

Child elements include the following ordered sequence of elements.

CHILD ELEMENT (MINIMUM, MAXIMUM) DESCRIPTION

CommandBlock (1, n) A command block that is executed in

the PowerShell. The command blocks
are each executed in sequence.

For more information

Data loss prevention
Define your own DLP templates and information types
Import a custom DLP policy template from a file
 Developing sensitive information rule packages in
Exchange 2013
6/14/2019 • 15 minutes to read • Edit Online

Applies to: Exchange Server 2013

The XML schema and guidance in this topic will help you get started creating your own basic data loss prevention
(DLP ) XML files that define your own sensitive information types in a classification rule package. After you have
created a well-formed XML file, you can import it by using either the Exchange admin center or the Exchange
management shell in order to help create a Microsoft Exchange Server 2013 DLP solution. An XML file that is a
custom DLP policy template can contain the XML that is your classification rule package. For an overview about
defining your own DLP templates as XML files, see Define your own DLP templates and information types.

Overview of the rule authoring process

The rule authoring process is made up of the following general steps.
1. Prepare a set of test documents representative of their target environment. Key characteristics to consider
for the set of test documents include: A subset of the documents contain the entity or affinity for which the
rule is being authored, and a subset of the documents do not contain the entity or affinity for which the rule
is being authored.
2. Identify the rules that meet acceptance requirements (precision and recall) to identify qualifying content.
This may require the development of multiple conditions within a rule, bound with Boolean logic, which
together satisfy the minimum match requirements to identify target documents.
3. Establish the recommended confidence level for the rules based on the acceptance requirements (precision
and recall). The recommended confidence element can be thought of as the default confidence level for the
rule.
4. Validate the rules by instantiating a policy with them and monitoring the sample test content. Based on the
results, adjust the rules, or the confidence level to maximize the detected content while minimizing false
positives and negatives. Continue the cycle of validation and rule adjustments until a satisfactory level of
content detection is reached for both positive and negative samples.
For information about the XML schema definition for policy template files, see Developing DLP policy template
files.

Rule description
Two main Rule types can be authored for the DLP sensitive information detection engine: Entity and Affinity. The
Rule type chosen is based on the type of processing logic that should be applied to the processing of the content
as described in the previous sections. The rule definitions are configured in an XML document in the format
described by the standardized Rules XSD. The rules describe both the type of content to match and the confidence
level that the described match represents the target content. Confidence level specifies the probability for the
Entity to be present if a Pattern is found in the content or the probability for the Affinity to be present if Evidence is
found in the content.

Basic rule structure

The Rule definition is constructed from three main components:
1. Entity defines the matching and counting logic for that rule
2. Affinity defines the matching logic for the rule
3. Localized Strings localization for rule names and their descriptions
Three additional supporting elements are used that define the details of the processing and referenced within the
main components: Keyword, Regex, and Function. By using references, a single definition of the supporting
elements, like a social security number, can be used to in multiple Entity or Affinity rules. The basic rule structure in
XML format can be seen as follows.

<?xml version="1.0" encoding="utf-8"?>

<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
<RulePack id="DAD86A92-AB18-43BB-AB35-96F7C594ADAA">
<Version major="1" minor="0" build="0" revision="0"/>
<Publisher id="619DD8C3-7B80-4998-A312-4DF0402BAC04"/>
<Details defaultLangCode="en-us">
<LocalizedDetails langcode="en-us">
<PublisherName>DLP by EPG</PublisherName>
<Name>CSO Custom Rule Pack</Name>
<Description>This is a rule package for a EPG demo.</Description>
</LocalizedDetails>
</Details>
</RulePack>
<Rules>
<!-- Employee ID -->
<Entity id="E1CC861E-3FE9-4A58-82DF-4BD259EAB378" patternsProximity="300" recommendedConfidence="75">
<Pattern confidenceLevel="75">
<IdMatch idRef="Regex_employee_id" />
<Match idRef="Keyword_employee" />
</Pattern>
</Entity>
<Regex id="Regex_employee_id">(\s)(\d{9})(\s)</Regex>
<Keyword id="Keyword_employee">
<Group matchStyle="word">
<Term>Identification</Term>
<Term>Contoso Employee</Term>
</Group>
</Keyword>
<LocalizedStrings>
<Resource idRef="E1CC861E-3FE9-4A58-82DF-4BD259EAB378">
<Name default="true" langcode="en-us">
Employee ID
</Name>
<Description default="true" langcode="en-us">
A custom classification for detecting Employee ID's
</Description>
</Resource>
</LocalizedStrings>
</Rules>
</RulePackage>

Entity rules
Entity Rules are targeted towards well defined identifiers, such as Social Security Number, and are represented by
a collection of countable patterns. Entity Rules returns a count and the confidence level of a match, where Count is
the total number of instances of the entity that were found and the Confidence Level is the probability that the
given entity exists in the given document. Entity contains the "id" attribute as its unique identifier. The identifier is
used for localization, versioning, and querying. The Entity id must be a GUID and should not be duplicated in
other entities or affinities. It is referenced in the localized strings section.
Entity rules contains optional patternsProximity attribute (default = 300) which is used when applying Boolean
logic to specify the adjacency of multiple patterns required to satisfy the match condition. Entity element contains
1 or more child Pattern elements, where each pattern is a distinct representation of the Entity like Credit Card
Entity or Driver's License Entity. The Pattern element has a required attribute of confidenceLevel which represents
the pattern's precision based on sample dataset. Pattern element can have three child elements:
1. IdMatch - This is required.
2. Match
3. Any
If any of the Pattern elements return "true," the Pattern is satisfied. The count for the Entity element equals the
sum of all detected Pattern counts.

where k is the number of Pattern elements for the Entity.

A Pattern element must have exactly one IdMatch element. IdMatch represents the identifier that the Pattern is to
match, for example a credit card number or ITIN number. The Count for a pattern is the number of IdMatches
matched with the Pattern element. IdMatch element anchors the proximity window for the Match elements.
Another optional sub-element of the Pattern element is the Match element which represents corroborative
evidence that is required to be matched to support finding the IdMatch element. For example, the higher
confidence rule may require that, in addition to finding a credit card number, additional artifacts exist in the
document, within a proximity window of the credit card, like address and name. These additional artifacts would
be represented through the Match element or Any element (these are described in detail in Matching Methods
and Techniques section). Multiple Match elements can be included in a Pattern definition which can be included
directly in the Pattern element or combined using the Any element to define matching semantics. It returns true if
a match is found in the proximity window anchored around the IdMatch content.
Both the IdMatch and Match elements do not define the details of what content needs to be matched but instead
reference it through the idRef attribute. This promotes reusability of definitions in multiple Pattern constructs.

<Entity id="..." patternsProximity="300" >

<Pattern confidenceLevel="85">
<IdMatch idRef="FormattedSSN" />
<Any minMatches="1">
<Match idRef="SSNKeyword" />
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>
</Pattern>
<Pattern confidenceLevel="65">
<IdMatch idRef="UnformattedSSN" />
<Match idRef="SSNKeyword" />
<Any minMatches="1">
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>
</Pattern>
</Entity>

The Entity id element, represented in the previous XML by "..." should be a GUID and it is referenced in the
Localized Strings section.
Entity pattern proximity window
Entity holds optional patternsProximity attribute value (integer, default = 300) used to find the Patterns. For each
pattern the attribute value defines the distance (in Unicode characters) from the IdMatch location for all other
Matches specified for that Pattern. The proximity window is anchored by the IdMatch location, with the window
extending to the left and right of the IdMatch.

The example below illustrates how the proximity window affects the matching algorithm where the SSN IdMatch
element requires at least 1 of address, name or date corroborating matches. Only SSN1 and SSN4 match because
for SSN2 and SSN3, either no or only partial corroborating evidence is found within the proximity window.

Note that the message body and each attachment are treated as independent items. This means that the proximity
window does not extend beyond the end of each of these items. For each item (attachment or body), both the
idMatch and corroborative evidence needs to reside within each.
Entity confidence level
Entity element's confidence level is the combination of all the satisfied Pattern's confidence levels. They are
combined using the following equation:

where k is the number of Pattern elements for the Entity and a Pattern that does not match returns a confidence
level of 0.
Referring back to the example entity element structure code sample, if both patterns are matched, the entity's
confidence level is 94.75% based on the following calculation:
CL Entity = 1-[(1-CL Pattern1) x (1-CL Pattern1)]
= 1-[(1-0.85) x (1-0.65)]
= 1-(0.15 x 0.35)
= 94.75%
Similarly, if only the second pattern matches, the Entity's confidence level is 65% based on the following
calculation:
CL Entity = 1 - [(1 - CL Pattern1) X (1 - CL Pattern1)]
= 1 - [(1 - 0) X (1 - 0.65)]
= 1 - (1 X 0.35)
= 65%
These confidence values are assigned in the rules for individual patterns based on the set of test documents
validated as part of the rule authoring process.
Affinity rules
Affinity rules are targeted towards content without well-defined identifiers, for example Sarbanes-Oxley or
corporate financial content. For this content no single consistent identifier can be found and instead the analysis
requires determining if a collection of evidence is present. Affinity rules do not return a count, instead they return
if found and the associated confidence level. Affinity content is represented as a collection of independent
evidences. Evidence is an aggregation of required matches within certain proximity. For Affinity rule, the proximity
is defined by the evidencesProximity attribute (default is 600) and the minimum confidence level by the
thresholdConfidenceLevel attribute.
Affinity rules contains the id attribute for its unique identifier that is used for localization, versioning and querying.
Unlike Entity rules, because Affinity rules do not rely on well-defined identifiers, they do not contain the IdMatch
element.
Each Affinity rule contains one or more child Evidence elements which define the evidence that is to be found and
the level of confidence contributing to the Affinity rule. The affinity is not considered found if the resulting
confidence level is below the threshold level. Each Evidence logically represents corroborative evidence for this
"type" of document and the confidenceLevel attribute is the precision for that Evidence on the test dataset.
Evidence elements have one or more of Match or Any child elements. If all child Match and Any elements match,
the Evidence is found and the confidence level is contributed to the rules confidence level calculation. The same
description applies to the Match or Any elements for Affinity rules as for Entity rules.

<Affinity id="..."
evidencesProximity="1000"
thresholdConfidenceLevel="65">
<Evidence confidenceLevel="40">
<Any>
<Match idRef="AssetsTerms" />
<Match idRef="BalanceSheetTerms" />
<Match idRef="ProfitAndLossTerms" />
</Any>
</Evidence>
<Evidence confidenceLevel="40">
<Any minMatches="2">
<Match idRef="TaxTerms" />
<Match idRef="DollarAmountTerms" />
<Match idRef="SECTerms" />
<Match idRef="SECFilingFormTerms" />
<Match idRef="DollarTotalRegex" />
</Any>
</Evidence>
</Affinity>

Affinity proximity window

The proximity window for Affinity is calculated differently than for Entity patterns. Affinity proximity follows a
sliding window model. The affinity proximity algorithm attempts to find the maximum number of matching
evidences in the given window. Evidences in the proximity window must have a confidence level greater than the
threshold defined for the Affinity rule to be found.

Affinity confidence level

Confidence level for the Affinity equals the combination of found Evidences within the proximity window for the
Affinity rule. While similar to the confidence level of Entity rule, the key difference is the application of proximity
window. Similar to the Entity rules, Affinity element's confidence level is the combination of all the satisfied
Evidence confidence levels, but for Affinity rule it only represents the highest combination of Evidence elements
found within the proximity window. The Evidence confidence levels are combined using the following equation:

where k is the number of Evidence elements for the Affinity matched within the proximity window.
Referring back to Figure 4 Example Affinity rule structure, if all three evidences are matched within the proximity
sliding window, the affinity confidence level is 85.6% based on the calculation below. This exceeds the Affinity rule
threshold of 65 which results in the rule matching.
CL Affinity = 1 - [(1 - CL Evidence 1) X (1 - CL Evidence 2) X (1 - CL Evidence 2)]
= 1 - [(1 - 0.6) X (1 - 0.4) X (1 - 0.4)]
= 1 - (0.4 X 0.6 X 0.6)
= 85.6%

Using the same example rule definition, if only the first evidence matches because the second Evidence is outside
of the proximity window, the highest Affinity confidence level is 60% based on the calculation below and the
Affinity rule does not match since the threshold of 65 was not met.
CL Affinity = 1 - [(1 - CL Evidence 1) X (1 - CL Evidence 2) X (1 - CL Evidence 2)]
= 1 - [(1 - 0.6) X (1 - 0) X (1 - 0) ]
= 1 - (0.4 X 1 X 1)
= 60%

Tuning confidence levels

One of the key aspects of the rule authoring process is the tuning of confidence levels for both Entity and Affinity
rules. After creating the rule definitions, run the rule against the representative content and collect the accuracy
data. Compare the returned results for each pattern or evidence against the expected results for the test
documents.

If the rules meet acceptance requirements, that is, the Pattern or Evidence has a confidence rate above an
established threshold (e.g. 75%), the match expression is complete and it can be moved to the next step.
If the Pattern or Evidence do not meet the confidence level, then re-author it (e.g. add more corroborative
evidence; remove or add additional Patterns/Evidences; etc.) and repeat this step.
Next, tune the confidence level for each Pattern or Evidence in your rules based on the results from the previous
step. For each Pattern or Evidence, aggregate the number of True Positives (TP ), subset of the documents that
contain the entity or affinity for which the rule is being authored and that resulted in a match and the number of
False Positives (FP ), a subset of documents that do not contain the entity or affinity for which the rule is being
authored and that also returned a match. Set confidence level for each Pattern/Evidence using the following
calculation:
Confidence Level = True Positives / (True Positives + False Positives)

PATTERN OR EVIDENCE TRUE POSITIVES FALSE POSITIVES CONFIDENCE LEVEL

P1 or E1 4 1 80%

P2 or E2 2 2 50%

Pn or En 9 10 47%

Using local languages in your XML file

The rule schema supports storing of localized name and description for each of Entity and Affinity elements. Each
Entity and Affinity element must contain a corresponding element in the LocalizedStrings section. To localize each
element, include a Resource element as a child of the LocalizedStrings element to store name and descriptions for
multiple locales for each element. The Resource element includes a required idRef attribute which matches the
corresponding idRef attribute for each element that is being localized. The Locale child elements of the Resource
element contains the localized name and descriptions for each specified locale.

<LocalizedStrings>
<Resource idRef="guid">
<Locale langcode="en-US" default="true">
<Name>affinity name en-us</Name>
<Description>
affinity description en-us
</Description>
</Locale>
<Locale langcode="de">
<Name>affinity name de</Name>
<Description>
affinity description de
</Description>
</Locale>
</Resource>
</LocalizedStrings>

Classification rule pack XML schema definition

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:mce="http://schemas.microsoft.com/office/2011/mce"
targetNamespace="http://schemas.microsoft.com/office/2011/mce"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
id="RulePackageSchema">
<xs:simpleType name="LangType">
<xs:simpleType name="LangType">
<xs:union memberTypes="xs:language">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value=""/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="GuidType" final="#all">
<xs:restriction base="xs:token">
<xs:pattern value="[0-9a-fA-F]{8}\-([0-9a-fA-F]{4}\-){3}[0-9a-fA-F]{12}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RulePackageType">
<xs:sequence>
<xs:element name="RulePack" type="mce:RulePackType"/>
<xs:element name="Rules" type="mce:RulesType">
<xs:key name="UniqueRuleId">
<xs:selector xpath="mce:Entity|mce:Affinity"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:key name="UniqueProcessorId">
<xs:selector xpath="mce:Regex|mce:Keyword"></xs:selector>
<xs:field xpath="@id"/>
</xs:key>
<xs:key name="UniqueResourceIdRef">
<xs:selector xpath="mce:LocalizedStrings/mce:Resource"/>
<xs:field xpath="@idRef"/>
</xs:key>
<xs:keyref name="ReferencedRuleMustExist" refer="mce:UniqueRuleId">
<xs:selector xpath="mce:LocalizedStrings/mce:Resource"/>
<xs:field xpath="@idRef"/>
</xs:keyref>
<xs:keyref name="RuleMustHaveResource" refer="mce:UniqueResourceIdRef">
<xs:selector xpath="mce:Entity|mce:Affinity"/>
<xs:field xpath="@id"/>
</xs:keyref>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="RulePackType">
<xs:sequence>
<xs:element name="Version" type="mce:VersionType"/>
<xs:element name="Publisher" type="mce:PublisherType"/>
<xs:element name="Details" type="mce:DetailsType">
<xs:key name="UniqueLangCodeInLocalizedDetails">
<xs:selector xpath="mce:LocalizedDetails"/>
<xs:field xpath="@langcode"/>
</xs:key>
<xs:keyref name="DefaultLangCodeMustExist" refer="mce:UniqueLangCodeInLocalizedDetails">
<xs:selector xpath="."/>
<xs:field xpath="@defaultLangCode"/>
</xs:keyref>
</xs:element>
<xs:element name="Encryption" type="mce:EncryptionType" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="id" type="mce:GuidType" use="required"/>
</xs:complexType>
<xs:complexType name="VersionType">
<xs:attribute name="major" type="xs:unsignedShort" use="required"/>
<xs:attribute name="minor" type="xs:unsignedShort" use="required"/>
<xs:attribute name="build" type="xs:unsignedShort" use="required"/>
<xs:attribute name="revision" type="xs:unsignedShort" use="required"/>
</xs:complexType>
<xs:complexType name="PublisherType">
<xs:attribute name="id" type="mce:GuidType" use="required"/>
</xs:complexType>
<xs:complexType name="LocalizedDetailsType">
<xs:sequence>
 <xs:sequence>
<xs:element name="PublisherName" type="mce:NameType"/>
<xs:element name="Name" type="mce:RulePackNameType"/>
<xs:element name="Description" type="mce:OptionalNameType"/>
</xs:sequence>
<xs:attribute name="langcode" type="mce:LangType" use="required"/>
</xs:complexType>
<xs:complexType name="DetailsType">
<xs:sequence>
<xs:element name="LocalizedDetails" type="mce:LocalizedDetailsType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="defaultLangCode" type="mce:LangType" use="required"/>
</xs:complexType>
<xs:complexType name="EncryptionType">
<xs:sequence>
<xs:element name="Key" type="xs:normalizedString"/>
<xs:element name="IV" type="xs:normalizedString"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="RulePackNameType">
<xs:restriction base="xs:token">
<xs:minLength value="1"/>
<xs:maxLength value="64"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="NameType">
<xs:restriction base="xs:normalizedString">
<xs:minLength value="1"/>
<xs:maxLength value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="OptionalNameType">
<xs:restriction base="xs:normalizedString">
<xs:minLength value="0"/>
<xs:maxLength value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="RestrictedTermType">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="512"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RulesType">
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element name="Entity" type="mce:EntityType"/>
<xs:element name="Affinity" type="mce:AffinityType"/>
</xs:choice>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="Regex" type="mce:RegexType"/>
<xs:element name="Keyword" type="mce:KeywordType"/>
</xs:choice>
<xs:element name="LocalizedStrings" type="mce:LocalizedStringsType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EntityType">
<xs:sequence>
<xs:element name="Pattern" type="mce:PatternType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="mce:GuidType" use="required"/>
<xs:attribute name="patternsProximity" type="mce:ProximityType" use="required"/>
<xs:attribute name="recommendedConfidence" type="mce:ProbabilityType"/>
<xs:attribute name="workload" type="mce:WorkloadType"/>
</xs:complexType>
<xs:complexType name="PatternType">
<xs:sequence>
<xs:element name="IdMatch" type="mce:IdMatchType"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="Match" type="mce:MatchType"/>
 <xs:element name="Match" type="mce:MatchType"/>
<xs:element name="Any" type="mce:AnyType"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="confidenceLevel" type="mce:ProbabilityType" use="required"/>
</xs:complexType>
<xs:complexType name="AffinityType">
<xs:sequence>
<xs:element name="Evidence" type="mce:EvidenceType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="mce:GuidType" use="required"/>
<xs:attribute name="evidencesProximity" type="mce:ProximityType" use="required"/>
<xs:attribute name="thresholdConfidenceLevel" type="mce:ProbabilityType" use="required"/>
<xs:attribute name="workload" type="mce:WorkloadType"/>
</xs:complexType>
<xs:complexType name="EvidenceType">
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element name="Match" type="mce:MatchType"/>
<xs:element name="Any" type="mce:AnyType"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="confidenceLevel" type="mce:ProbabilityType" use="required"/>
</xs:complexType>
<xs:complexType name="IdMatchType">
<xs:attribute name="idRef" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="MatchType">
<xs:attribute name="idRef" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="AnyType">
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element name="Match" type="mce:MatchType"/>
<xs:element name="Any" type="mce:AnyType"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="minMatches" type="xs:nonNegativeInteger" default="1"/>
<xs:attribute name="maxMatches" type="xs:nonNegativeInteger" use="optional"/>
</xs:complexType>
<xs:simpleType name="ProximityType">
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ProbabilityType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="WorkloadType">
<xs:restriction base="xs:string">
<xs:enumeration value="Exchange"/>
<xs:enumeration value="Outlook"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RegexType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="id" type="xs:token" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="KeywordType">
<xs:sequence>
<xs:element name="Group" type="mce:GroupType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:token" use="required"/>
</xs:complexType>
 </xs:complexType>
<xs:complexType name="GroupType">
<xs:sequence>
<xs:choice>
<xs:element name="Term" type="mce:TermType" maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="matchStyle" default="word">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="word"/>
<xs:enumeration value="string"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="TermType">
<xs:simpleContent>
<xs:extension base="mce:RestrictedTermType">
<xs:attribute name="caseSensitive" type="xs:boolean" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="LocalizedStringsType">
<xs:sequence>
<xs:element name="Resource" type="mce:ResourceType" maxOccurs="unbounded">
<xs:key name="UniqueLangCodeUsedInNamePerResource">
<xs:selector xpath="mce:Name"/>
<xs:field xpath="@langcode"/>
</xs:key>
<xs:key name="UniqueLangCodeUsedInDescriptionPerResource">
<xs:selector xpath="mce:Description"/>
<xs:field xpath="@langcode"/>
</xs:key>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ResourceType">
<xs:sequence>
<xs:element name="Name" type="mce:ResourceNameType" maxOccurs="unbounded"/>
<xs:element name="Description" type="mce:DescriptionType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="idRef" type="mce:GuidType" use="required"/>
</xs:complexType>
<xs:complexType name="ResourceNameType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="default" type="xs:boolean" default="false"/>
<xs:attribute name="langcode" type="mce:LangType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="DescriptionType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="default" type="xs:boolean" default="false"/>
<xs:attribute name="langcode" type="mce:LangType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>

For more information

Data loss prevention
Define your own DLP templates and information types
 Matching methods and techniques for rule packages
in Exchange 2013
5/30/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic describes techniques for matching pattern and evidence elements within a data loss prevention (DLP )
XML file that is designed to contain your own custom sensitive information type rule package. After you have
created a well-formed XML file, you can import the file by using the Exchange admin center (EAC ) or Exchange
Management Shell in order to help create your Microsoft Exchange Server 2013 DLP solution. Before you can
make use of the matching methods described here, you should already have a DLP XML file started. For more
information about defining your own DLP templates and XML files, see Define your own DLP templates and
information types.

The Match element

The Match element is used within the Pattern and Evidence elements to represents the underlying keyword,
regex or function that is to be matched. The definition of the match itself is stored outside of the Rule element and
is referenced through the idRef required attribute. Multiple Match elements can be included in a Pattern
definition which can be included directly in the Pattern element or combined using the Any element to define
matching semantics.

<?xml version="1.0" encoding="utf-8"?>

<Rules packageId="...">
...
<Entity id="...">
<Pattern confidenceLevel="85">
<IdMatch idRef="FormattedSSN" />
<Match idRef="USDate" />
<Match idRef="USAddress" />
</Pattern>
</Entity>
...
<Keyword id="FormattedSSN "> ... </Keyword>
<Regex id=" USDate "> ... </Regex>
<Regex id="USAddress"> ... </Regex>
...
</Rules>

Defining keyword-based matches

A common Rule requirement is to match based on well-known keyword string expressions. This is accomplished
by using the Keyword element. The Keyword element has an "id" attribute that is used as a reference in the
corresponding Entity or Affinity rules. A single Keyword element can be referenced in multiple Entity and Affinity
rules.
The matching can be performed using either an exact match or word match based algorithms. Exact match uses a
case-sensitive algorithm that searches for the text in the specified language. Word match applies a matching
algorithm based on word boundaries. The terms to be matched can be included inline in the Keyword definition by
using the Term sub-element.
 TIP
Use the constant based match style over regex for better efficiency and performance. Use regex matching only in cases where
constant based matches are not sufficient and flexibility of regular expressions is required.

<Keyword id="Word_Example">
<Group matchStyle="word">
<Term>card verification</Term>
<Term>cvn</Term>
<Term>cid</Term>
<Term>cvc2</Term>
<Term>cvv2</Term>
<Term>pin block</Term>
<Term>security code</Term>
</Group>
</Keyword>
...
<Keyword id="String_Example">
<Group matchStyle="string">
<Term>card</Term>
<Term>pin</Term>
<Term>security</Term>
</Group>
</Keyword>

Defining regular expression based matches

Another common method of matching is based on regular expressions. The flexibility of regular expression
matching makes this a common choice for implementing matches for data such as driver's license numbers,
addresses. Common regular expression syntax is used to define the regex patterns. The table here provides
examples of some of the most common regular expression tokens available.

TIP
Use the constant based match style over regex for better efficiency and performance. Use regex matching only in cases where
constant based matches are not sufficient and flexibility of regular expressions is required.

SYMBOL MEANING

c Match the literal character c once,

unless it is one of the special characters.

^ Match the beginning of a line.

. Match any character that isn't a new

line.

$ Match the end of a line.

Logical OR between expressions.

() Group sub-expressions.

[] Define a character class.

 SYMBOL MEANING

* Match the preceding expression zero or

more times.

+ Match the preceding expression one or

more times.

? Match the preceding expression zero or

one time.

{n} Match the preceding expression n

times.

{n,} Match the preceding expression at least

n times.

{n, m} Match the preceding expression at least

n times and at most m times.

\d Match a digit.

\D Match a character that is not a digit.

\w Match an alpha character, including the

underscore.

\W Match a character that is not an alpha

character.

\s Match a whitespace character (any of \t,

\n, \r, or \f).

\S Match a non-whitespace character.

\t Tab.

\n New line.

\r Carriage return.

\f Form feed.

\m Escape m, where m is one of the meta , (), [], *, +, ?, , or /.

characters described above: ^, ., $,

The Regex element has an "id" attribute that is used as a reference in the corresponding Entity or Affinity rules. A
single Regex element can be referenced in multiple Entity and Affinity rules. The Regex expression is defined as the
value of the Regex element.
 <Regex id="CCRegex">
\bcc\#\s|\bcc\#\:\s
</Regex>
...
<Regex id="ItinFormatted">
(?:^|[\s\,\:])(?:9\d{2})[- ](?:[78]\d[-
]\d{4})(?:$|[\s\,]|\.\s)
</Regex>
...
<Regex id="NorthCarolinaDriversLicenseNumber">
(^|\s|\:)(\d{1,8})($|\s|\.\s)
</Regex>

Combining multiple match elements

A common technique to increase the matching confidence is to define semantics between multiple Match
elements, for example that one or more of the matches need to occur. The Any element allows the definition of the
logic based between multiple matches. The Any element can be used as sub-element in the Pattern element. It
contains one or more Match children elements and defines the logic of matches between them. See below for XML
code examples for the Any elements with all matches, "not" logic, and exact match count.
Optional minMatches attribute can be used (default = 1) to define the minimum number of Match elements that
must be met to satisfy a match. Similarly, optional maxMatches attribute can be used (default = number of children
Match elements) to define the maximum number of Match elements that must be met to satisfy a match. These
conditions are combined using logical operators based on the usage of the minMatches and maxMatches
attributes, allowing following semantics:
Matching all children Match elements
Not matching any children Match elements
Matching an exact subset of any children Match elements

<Any minMatches="3" maxMatches="3">

<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>

<Any maxMatches="0">
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>

<Any minMatches="1" maxMatches="1">

<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>

Increasing confidence level with more evidence

For entity base rules, another option of increasing confidence is to define multiple Pattern elements, each with
increasing number of corroborative evidence. This is achieved by using minMatches and maxMatches for Any
element to create independent patterns with increasing confidence level based on increasing number of
corroborative evidence. For example:
if one piece of corroborative evidence is found: confidence level is 65%
if two pieces: confidence level is 75%
if three pieces: confidence level is 85%

<Entity id="..." patternsProximity="300" >

<Pattern confidenceLevel="65">
<IdMatch idRef="UnformattedSSN" />
<Any maxMatches="1">
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>
</Pattern>
<Pattern confidenceLevel="75">
<IdMatch idRef="UnformattedSSN" />
<Any minMatches="2" maxMatches="2">
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>
</Pattern>
<Pattern confidenceLevel="85">
<IdMatch idRef="UnformattedSSN" />
<Any minMatches="3">
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>
</Pattern>
</Entity>

Example: US Social Security rule

This section includes an introduction description for authoring of a rule matching a US Social Security number.
First, start with a description of how we identify content that contains social security number. A Social Security
Number is found if:
1. Regex matches a formatted SSN (and it's in the valid SSN range)
2. Corroborative Evidence one of the following must occur nearby:
3. Keyword match {Social Security, Soc Sec, SSN, SSNS, SSN#, SS#, SSID }
4. Text representing a US address
5. Text representing a date
6. Text representing a name
Next, translate the description into the Rule schema representation:
 <Entity id="a44669fe-0d48-453d-a9b1-2cc83f2cba77"
patternsProximity="300" RecommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="FormattedSSN" />
<Any minMatches="1">
<Match idRef="SSNKeywords" />
<Match idRef="USDate" />
<Match idRef="USAddress" />
<Match idRef="Name" />
</Any>
</Pattern>
</Entity>

For more information

Data loss prevention
Define your own DLP templates and information types
Import a custom DLP policy template from a file
 Customize the built-in DLP sensitive information
types in Exchange 2013
5/30/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

When looking for sensitive information in email, you need to describe that information in what's called a rule. Data
loss prevention (DLP ) includes a pack of 51 rules for the most-common sensitive information types that you can
use right away. To use these rules, you have to include them in a policy. You might find that you want to adjust
these built-in rules to meet your organization's specific needs, and you can do that by creating a custom sensitive
information type. This topic shows you how to customize the XML file that contains the existing rule collection to
detect a wider range of potential credit-card information.
You can take this example and apply it to other built-in sensitive information types. For a list of default sensitive
information types and XML definitions, see the Sensitive information types inventory topic.
This topic guides you through the following sections for XML rule customizations:
Export the XML file of the current rules
Find the rule that you want to modify in the XML
Modify the XML and create a new sensitive information type
Remove the corroborative evidence requirement from a sensitive information type
Look for keywords that are specific to your organization
Upload your rule
To learn what the different parts of rules are and what they do, check out the Term glossary at the end of this topic.

Export the XML file of the current rules

To export the XML, you need to use the Exchange Management Shell. For more information, see Exchange
Management Shell.
1. In the Exchange Management Shell, type Get-ClassificationRuleCollection to display your organization's
rules on screen. If you haven't created your own, you'll only see the default, built-in rules, labeled "Microsoft
Rule Package."
2. Store your organization's rules in a in a variable by typing
$ruleCollections = Get-ClassificationRuleCollection . Storing something in a variable makes it easily
available later in a format that works for remote PowerShell commands.
3. Make a formatted XML file with all that data by replacing "C:\custompath\ with a real file path and typing
Set-Content -Path "C:\custompath\exportedRules.xml" -Encoding Byte -Value
$ruleCollections.SerializedClassificationRuleCollection
. (Set-content is the part of the cmdlet that writes the XML to the file.)

Find the rule that you want to modify in the XML

The cmdlets above exported the entire rule collection, which includes the 51 default rules we provide. Next you'll
need to look specifically for the Credit Card Number rule that you want to modify.
1. Use a text editor to open the XML file that you exported in the previous section.
2. Scroll down to the <Rules> tag, which is the start of the section that contains the DLP rules. (Because this
XML file contains the information for the entire rule collection, it contains other information at the top that
you need to scroll past to get to the rules.)
3. Look for Func_credit_card to find the Credit Card Number rule definition. (In the XML, rule names can't
contain spaces, so the spaces are usually replaced with underscores, and rule names are sometimes
abbreviated. An example of this is the U.S. Social Security number rule, which is abbreviated "SSN." The
Credit Card Number rule XML should look like the following code sample.

<Entity id="50842eb7-edc8-4019-85dd-5a5c1f2bb085"
patternsProximity="300" recommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="Func_credit_card" />
<Any minMatches="1">
<Match idRef="Keyword_cc_verification" />
<Match idRef="Keyword_cc_name" />
<Match idRef="Func_expiration_date" />
</Any>
</Pattern>
</Entity>

Now that you have located the Credit Card Number rule definition in the XML, you can customize the rule's XML
to meet your needs. (For a refresher on the XML definitions, see the Term glossary at the end of this topic.)

Modify the XML and create a new sensitive information type

First, you need to create a new sensitive information type because you can't directly modify the default rules. You
can do a wide variety of things with custom sensitive information types, which are outlined in Developing sensitive
information rule packages. For this example, we'll keep it simple and only remove corroborative evidence and add
keywords to the Credit Card Number rule.
All XML rule definitions are built on the following general template. You need to copy and paste the Credit Card
Number definition XML in the template, modify some values (notice the ". . ." placeholders in the following
example), and then upload the modified XML as a new rule that can be used in policies.
 <?xml version="1.0" encoding="utf-8"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
<RulePack id=". . .">
<Version major="1" minor="0" build="0" revision="0" />
<Publisher id=". . ." />
<Details defaultLangCode=". . .">
<LocalizedDetails langcode=" . . . ">
<PublisherName>. . .</PublisherName>
<Name>. . .</Name>
<Description>. . .</Description>
</LocalizedDetails>
</Details>
</RulePack>

<Rules>
<!-- Paste the Credit Card Number rule definition here.-->
<LocalizedStrings>
<Resource idRef=". . .">
<Name default="true" langcode=" . . . ">. . .</Name>
<Description default="true" langcode=". . ."> . . .</Description>
</Resource>
</LocalizedStrings>
</Rules>
</RulePackage>

Now, you have something that looks similar to the following XML. Because rule packages and rules are identified
by their unique GUIDs, you need to generate two GUIDs: one for the rule package and one to replace the GUID for
the Credit Card Number rule. (The GUID for the entity ID in the following code sample is the one for our built-in
rule definition, which you need to replace with a new one.) There are several ways to generate GUIDs, but you can
do it easily in PowerShell by typing [guid]::NewGuid() .
 <?xml version="1.0" encoding="utf-8"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
<RulePack id="8aac8390-e99f-4487-8d16-7f0cdee8defc">
<Version major="1" minor="0" build="0" revision="0" />
<Publisher id="8d34806e-cd65-4178-ba0e-5d7d712e5b66" />
<Details defaultLangCode="en">
<LocalizedDetails langcode="en">
<PublisherName>Contoso Ltd.</PublisherName>
<Name>Financial Information</Name>
<Description>Modified versions of the Microsoft rule package</Description>
</LocalizedDetails>
</Details>
</RulePack>

<Rules>
<Entity id="db80b3da-0056-436e-b0ca-1f4cf7080d1f"
patternsProximity="300" recommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="Func_credit_card" />
<Any minMatches="1">
<Match idRef="Keyword_cc_verification" />
<Match idRef="Keyword_cc_name" />
<Match idRef="Func_expiration_date" />
</Any>
</Pattern>
</Entity>
<LocalizedStrings>
<Resource idRef="db80b3da-0056-436e-b0ca-1f4cf7080d1f">
<!-- This is the GUID for the preceding Credit Card Number entity because the following text is for that
Entity. -->
<Name default="true" langcode="en-us">Modified Credit Card Number</Name>
<Description default="true" langcode="en-us">Credit Card Number that looks for additional keywords,
and another version of Credit Card Number that doesn't require keywords (but has a lower confidence level)
</Description>
</Resource>
</LocalizedStrings>
</Rules>
</RulePackage>

Remove the corroborative evidence requirement from a sensitive

information type
Now that you have a new sensitive information type that you're able to upload to your Exchange environment, the
next step is to make the rule more specific. Modify the rule so that it only looks for a 16-digit number that passes
the checksum but doesn't require additional (corroborative) evidence (for example keywords). To do this, you need
to remove the part of the XML that looks for corroborative evidence. Corroborative evidence is very helpful in
reducing false positives because usually there are certain keywords or an expiration date near the credit card
number. If you remove that evidence, you should also adjust how confident you are that you found a credit card
number by lowering the confidenceLevel, which is 85 in the example.

<Entity id="db80b3da-0056-436e-b0ca-1f4cf7080d1f" patternsProximity="300"

<Pattern confidenceLevel="85">
<IdMatch idRef="Func_credit_card" />
</Pattern>
</Entity>

Look for keywords that are specific to your organization

You might want to require corroborative evidence but want different or additional keywords, and perhaps you
want to change where to look for that evidence. You can adjust the patternsProximity to expand or shrink the
window for corroborative evidence around the 16-digit number. To add your own keywords, you need to define a
keyword list and reference it within your rule. The following XML adds the keywords "company card" and
"Contoso card" so that any message that contains those phrases within 150 characters of a credit card number will
be identified as a credit card number.

<Rules>
<! -- Modify the patternsProximity to be "150" rather than "300." -->
<Entity id="db80b3da-0056-436e-b0ca-1f4cf7080d1f" patternsProximity="150" recommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="Func_credit_card" />
<Any minMatches="1">
<Match idRef="Keyword_cc_verification" />
<Match idRef="Keyword_cc_name" />
<!-- Add the following XML, which references the keywords at the end of the XML sample. -->
<Match idRef="My_Additional_Keywords" />
<Match idRef="Func_expiration_date" />
</Any>
</Pattern>
</Entity>
<!-- Add the following XML, and update the information inside the <Term> tags with the keywords that you want
to detect. -->
<Keyword id="My_Additional_Keywords">
<Group matchStyle="word">
<Term caseSensitive="false">company card</Term>
<Term caseSensitive="false">Contoso card</Term>
</Group>
</Keyword>

Upload your rule

To upload your rule, you need to do the following.
1. Save it as an .xml file with Unicode encoding. This is important because the rule won't work if the file is
saved with a different encoding.
2. Connect to the Exchange Management Shell.
3. Replace \C:\custompath\ with a real file path and run the following command:

New-ClassificationRuleCollection -FileData (Get-Content -Path "C:\custompath\MyNewRulePack.xml " -

Encoding Byte)

4. To confirm, type Y, and then press Enter.

5. Verify that your new rule was uploaded by typing Get-DataClassification, which now displays the name of
your rule.
To start using the new rule to detect sensitive information, you need to add the rule to a DLP policy. To learn how
to add the rule to a policy, see Manage DLP policies.

Term glossary
These are the definitions for the terms you encountered during this procedure.

TERM DEFINITION
 TERM DEFINITION

Entity Entities are what we call sensitive information types, such as

credit card numbers. Each entity has a unique GUID as its ID.
If you copy a GUID and search for it in the XML, you'll find the
XML rule definition and all the localized translations of that
XML rule. You can also find this definition by locating the
GUID for the translation and then searching for that GUID.

Functions The XML file references Func_credit_card, which is a function

in compiled code. Functions are used to run complex regexes
and verify that checksums match for our built-in rules.)
Because this happens in the code, some of the variables don't
appear in the XML file.

IdMatch This is the identifier that the pattern is to trying to match (for
example, a credit card number). You can read more about this
and about the Match tags in Entity rules.

Keyword lists The XML file also references keyword_cc_verification and

keyword_cc_name, which are lists of keywords from which
we are looking for matches within the patternsProximity for
the entity. These aren't currently displayed in the XML.

Pattern The pattern contains the list of what the sensitive type is
looking for. This includes keywords, regexes, and internal
functions (that perform tasks like verifying checksums).
Sensitive information types can have multiple patterns with
unique confidences. This is useful when creating a sensitive
information type that returns a high confidence if
corroborative evidence is found and a lower confidence if little
or no corroborative evidence is found.

Pattern confidenceLevel This is the level of confidence that the DLP engine found a
match. This level of confidence is associated with a match for
the pattern if the pattern's requirements are met. This is the
confidence measure you should consider when using
Exchange transport rules (ETRs).

patternsProximity When we find what looks like a credit card number pattern,
patternsProximity is the proximity around that number
where we'll look for corroborative evidence.

recommendedConfidence This is the confidence level we recommend for this rule. The
recommended confidence applies to entities and affinities. For
entities, this number is never evaluated against the
confidenceLevel for the pattern. It's merely a suggestion to
help you choose a confidence level if you want to apply one.
For affinities, the confidenceLevel of the pattern must be
higher than the recommendedConfidence number for an
ETR action to be invoked. The recommendedConfidence is
the default confidence level used in ETRs that invokes an
action. If you want, you can manually change the ETR to be
invoked based off the pattern's confidence level, instead.

For more information

How DLP rules are applied to evaluate messages
Create a custom DLP policy
Sensitive information types inventory
 Export DLP sensitive information types from
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can view or change the details within your DLP policies without using the Exchange admin center (EAC ) or
Exchange Management Shell cmdlets by exporting the policies, saving them as an XML file, and modifying that
XML file. Typically you would then import the XML file back into Exchange. In this way, policies can be edited
independent of Exchange. However, they must meet specific format requirements, also referred to as XML schema,
in order to work correctly.
For additional management tasks related to DLP, see Manage DLP policies.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
The EAC doesn't provide a way to export DLP policies or templates to an external file. To use the Shell, see
Open the Exchange Management Shell.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Data loss prevention (DLP )" entry in the Messaging policy and compliance
permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Exchange Management Shell to export the DLP sensitive information types
This example exports all DLP sensitive information types along with their attributes to an XML file in the path
C:\My Documents\exportedInformationTypes.xml. We recommend making a backup copy of your current DLP
sensitive information types collection. One way to achieve this is to export and then immediately copy and rename
the same XML file.
1. Open the Exchange Management Shell.
2. Type Get-ClassificationRuleCollection, and your organization's sensitive information types should display on
screen. If you haven't created any sensitive information types of your own, you'll only see the default, built-in
sensitive information types collection, labeled "Microsoft Rule Package."
3. Store the sensitive information types in a variable by typing $ruleCollections = Get-
ClassificationRuleCollection.
4. Now make a formatted XML file with all that data by typing Set-Content -path "C:\My
Documents\exportedRules.xml" -Encoding Byte -Value
$ruleCollections.SerializedClassificationRuleCollection..
You can now edit the XML file to adjust the policies as needed. To learn how to customize the built-in sensitive
information types, see Customize the built-in DLP sensitive information types. For details on importing policies
back into Exchange, see Import a custom DLP policy template from a file.

For more information

Sensitive information types inventory
Customize the built-in DLP sensitive information types
Import a custom DLP policy template from a file
 Policy Tips in Exchange 2013
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can help to prevent your organization's Microsoft Outlook, Outlook Web App (OWA), and OWA for Devices
email users from inappropriately sending sensitive information by creating data loss prevention (DLP ) policies
that include Policy Tip notification messages. Similar to MailTips that were introduced in Microsoft Exchange
Server 2010, Policy Tip notification messages are displayed to users in Outlook while they are composing an
email message. Policy Tip notification messages only show up if something about the sender's email message
seems to violate a DLP policy that you have in place and that policy includes a rule to notify the sender when the
conditions that you establish are met. Watch this video to learn more.
Policy Tips
In order to show Policy Tips to your email senders, your rules must include the Notify the sender with a Policy
Tip action. You can add this in the rules editor from the Exchange admin center. For more information, see
Manage policy tips.
The transport rule agent that enforces DLP policies does not differentiate between email message attachments,
body text, or subject lines while evaluating messages and the conditions within your policies. For example, if a
user creates an email message that includes a credit card number in the body of the message and then attempts
to address the message to a recipient outside your organization, then a Policy Tip notification message can be
shown to that user in Outlook or Outlook Web App reminding them of your enterprise's expectations for such
information. However, this type of notification will only show up if you have configured a DLP policy that restricts
the example actions described; in this case adding an external email alias to the header of a message with credit
card data. There is a great variety of conditions, actions, and exceptions you can choose from while creating DLP
policies. This variety allows you to tailor your data loss prevention efforts in a way that meets your specific
organization's needs.
Any time you use either the notify sender action or an override action within a rule, we recommend that you also
include the condition that the message was sent from within your organization. You can do this by using the
policy rules editor to add the following condition: The sender is located... > inside the organization. Learn
more about changing existing DLP policies at Manage DLP policies. This is a best practice recommendation
because the notify sender action is applied as part of your company's message creation experience. The senders
referred to by the action are the authors of messages within your company. The user interaction presented by
Policy Tips cannot be acted upon by your users for incoming messages and will be ignored when the sender is
located outside your organization. You can apply DLP policies to scan incoming messages and take a variety of
actions, but when you do this, don't add the notify sender action.
If email senders in your organization who are in the act of composing a message are made aware of your
organizational expectations and standards in real time through Policy Tip notifications, then they are less likely to
violate standards that your organization wants to enforce.

NOTE
DLP is a premium feature that requires an Exchange Enterprise Client Access License (CAL). For more information about
CALs and server licensing, see Exchange Server Licensing.
If your organization is using Exchange 2013 SP1, Policy Tips are available to people sending mail from Outlook 2013,
Outlook Web App, or OWA for Devices. However, if your organization is currently using Exchange 2013, Policy Tips are only
available to people sending email from Outlook 2013.
Default text for Policy Tips and rule options
You have a range of possible options when you add sender notification rules to DLP policies. When you add a
rule to notify the sender by using the Notify the sender with a Policy Tip action within a DLP policy, you can
choose how restrictive to be. The notification options in the following table are available. For general information
about editing policies, see Manage DLP policies. For specific information about creating Policy Tips, see Manage
policy tips.

DEFAULT POLICY TIP NOTIFICATION

NOTIFICATION RULE MEANING MESSAGE THAT OUTLOOK USERS WILL SEE

Notify only Similar to MailTips, this causes an This message may contain sensitive
informative Policy Tip notification content. All recipients must be
message about a policy violation. A authorized to receive this content.
sender can prevent this type of tip
from showing up by using a Policy Tip
options dialog box that can be
accessed in Outlook.

Reject message The message will not be delivered until This message may contain sensitive
the condition is no longer present. The content. Your organization won't allow
sender is provided with an option to this message to be sent until that
indicate that their email message does content is removed.
not contain sensitive content. This is
also known as a false-positive override.
If the sender indicates this, then
Outlook will allow the message to leave
the outbox so that the user's report
may be audited, but Exchange will
block the message from being sent.

Reject unless false positive override The result with this notification rule is Before the sender selects an option
similar to the Reject message to override: This message may
notification rule. However, if you select contain sensitive content. Your
this then Exchange will allow the organization won't allow this message
message to be sent to the intended to be sent until that content is
recipient, instead of blocking the removed.
message. After the sender selects an option
override: Your feedback will be
submitted to your administrator when
the message is sent.

Reject unless silent override The message will not be delivered until Before the sender selects an option
the condition is no longer present or to override: This message may
the sender indicates an override. The contain sensitive content. Your
sender is provided with an option to organization won't allow this message
indicate that they wish to override the to be sent until that content is
policy. removed.
After the sender selects an option
override: You have overridden your
organization's policy for sensitive
content in this message. Your action
will be audited by your organization.
 DEFAULT POLICY TIP NOTIFICATION
NOTIFICATION RULE MEANING MESSAGE THAT OUTLOOK USERS WILL SEE

Reject unless explicit override The result with this notification rule is Before the sender selects an option
similar to the Reject unless silent to override: This message may
override notification rule, except that contain sensitive content. Your
in this case when the sender attempts organization won't allow this message
to override the policy, they are required to be sent until that content is
to provide a justification for overriding removed.
the policy. After the sender selects an option
override: You have overridden your
organization's policy for sensitive
content in this message. Your action
will be audited by your organization.

Customize your Policy Tip notification messages

To customize the text of a Policy Tip notification that email senders see in their email program, select Manage
Policy Tips on the Data Loss Prevention page. In order for any of your custom text to appear, a DLP policy rule
must include the Notify the sender with a Policy Tip action. Add the action to a rule by using the DLP rules
editor.
For procedures that explain how to create your own Policy Tips, see Manage policy tips. The custom text that you
create can replace the default text shown in the previous table.

POLICY TIP NOTIFICATION ACTIONS AND SETTINGS MEANING

Notify the sender Your text only appears when a Notify the sender, but allow
them to send action is initiated.

Allow the sender to override Your text only appears when the following actions are
initiated: Block the message unless it's a false positive,
Block the message, but allow the sender to override and
send.

Block the message Your text only appears when a Block the message action is
initiated.

Link to compliance URL The compliance URL is a link to a web page where you can
explain your compliance and override policies. This link is
displayed in the Policy Tip when a user clicks the More
details link.

For more information

Data loss prevention
Manage DLP policies
Manage policy tips
 Manage policy tips in Exchange 2013
6/18/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

Policy Tips are informative notices that are displayed to email senders while they're composing a message. The
purpose of the Policy Tip is to educate users that they might be violating the business practices or policies that you
are enforcing with the data loss prevention (DLP ) policies that you have established. The following procedures will
help you begin using Policy Tips. Watch this video to learn more.
Policy Tips

What do you need to know before you begin?

Estimated time to complete each procedure: 30 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Data loss prevention (DLP )" entry in the Messaging policy and compliance
permissions topic.
Policy Tips will only show up for email senders when the following conditions are met:
1. Sender's message client program is Microsoft Outlook 2013. If your organization has deployed
Exchange 2013 SP1, Policy Tips also show up in Outlook Web App and OWA for Devices.
2. A transport rule exists that invokes Policy Tip notifications. You can create such a transport rule by
configuring a DLP policy that includes the action Notify the sender with a Policy Tip.
3. The content of a message header, message body, or message attachment that is scanned by your
transport agent meets the conditions established within the DLP policies or rules that also include
Policy Tip notification rules. Put another way, the Policy Tip only shows up for end-users if they do
something that causes the associated rule to take action.
The default Policy Tip notification text that is built into the system will be shown if you don't use the Policy
Tip settings feature to customize your Policy Tip text. To learn more about the default text, see Policy Tips.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Create or modify a notify-only Policy Tip

This procedure results in an informational Policy Tip being shown to an email sender when the conditions of a
specific rule are met. In Microsoft Outlook, the sender can prevent this tip from showing up by using a Policy Tip
options dialog box. To configure custom Policy Tip text, see the Create custom Policy Tip notification text section
later in this article.
Use the EAC to configure notify-only Policy Tips
1. In the EAC, go to Compliance management > Data loss prevention.
 2. Double-click one of the policies that appear in your list of policies or highlight one item and select Edit .
3. On the Edit DLP policy page, select Rules.
4. To add Policy Tips to an existing rule, highlight the rule and select Edit .
To add a new blank rule that you can fully customize, select Add and then select Create a new rule.
5. In Apply this rule if, select, The message contains sensitive information. This condition is required.
6. Select , select the sensitive information types, select Add, select OK, and then select OK.
7. In the Do the following box, select Notify the sender with a Policy Tip, and select an option in the
Choose whether the message is blocked or can be sent drop-down list, and then select OK.
8. If you want to add additional conditions or actions, at the bottom of the window, select More options.
Note: You can only use the following conditions:
SentTo (The recipient is)
SentToScope (The recipient is located)
From (The sender is)>
FromMemberOf (The sender is a member of )
FromScope (The sender is located)
You can't use the following actions:
RejectMessageReasonText (Reject the message and include an explanation)
RejectMessageEnhancedStatusCode (Reject the message with the enhanced status code of )
DeletedMessage (Delete the message without notifying anyone)
9. In the Choose a mode for this rule list, select whether you want the rule to be enforced. We recommend
testing the rule first.
10. Select Save to finish modifying the rule and save your changes.
How do you know this worked?
To verify that you have successfully created a Policy Tip that will only notify a sender, do the following:
1. In the EAC, go to Compliance management > Data loss prevention.
2. Select the policy that you expect to contain a notification message.
3. Select Edit and then select Rules.
4. Select the specific rule that you expect to contain a notification message.
5. Confirm that your Notify the sender action appears in the lower portion of the rule summary.

Create or modify a block-message Policy Tip

This procedure results in a Policy Tip being shown to an email sender that indicates a message is rejected and it
will not be delivered until the problematic condition is no longer present. The sender is provided with an option to
indicate that their email message does not contain the problematic condition. This is also known as a false-positive
override. If the sender indicates this, then the message can leave the outbox and the user's report may be audited.
However, Exchange will block the message from being sent.
Use the EAC to configure block-message Policy Tips
1. In the EAC, go to Compliance management > Data loss prevention.
2. Double-click one of the policies that appear in your list of policies or highlight one item and select Edit .
3. On the Edit DLP policy page, select Rules.
4. To add Policy Tips to an existing rule, highlight the rule and select Edit .
5. To add a new blank rule that you can fully customize, select Add .
6. To add an action that will reveal a Policy Tip, select More options... and then select the Add action button.
7. From the drop down list, select Notify the sender with a Policy Tip and then select Block the message.
8. Select OK, then select Save to finish modifying the rule and save your changes.
How do you know this worked?
To verify that you have successfully created a reject message Policy Tip, do the following:
1. In the EAC, go to Compliance management > Data loss prevention.
2. Select one time to highlight the policy that you expect to contain a notification message.
3. Select Edit and then select Rules.
4. Select one time to highlight the specific rule that you expect to contain a notification message.
5. Confirm that your Notify the sender that the message can't be sent action appears in the lower
portion of the rule summary.

Create or modify a block-unless-override Policy Tip

There are four options for Policy Tips that can reject messages or prevent messages from leaving the sender's
outbox. To learn more about these options, see Policy Tips.
Use the EAC to configure block-unless override Policy Tips
1. In the EAC, go to Compliance management > Data loss prevention.
2. Double-select one of the policies that appear in your list of policies or highlight one item and select Edit .
3. On the edit DLP policy page, select Rules.
4. To add Policy Tips to an existing rule, highlight the rule and select Edit .
To add a new blank rule that you can fully customize, select Add and then select More options....
5. To add the action that will reveal a Policy Tip, Select the Add action button.
6. From the drop down list, select Notify the sender with a Policy Tip and then select Block the message,
but allow the sender to override and send.
7. Select OK, then select Save to finish modifying the rule and save your changes.
How do you know this worked?
To verify that you have successfully created a reject unless override Policy Tip, do the following:
1. In the EAC, go to Compliance management > Data loss prevention.
2. Select one time to highlight the policy that you expect to contain a notification message.
3. Select Edit and then select Rules.
4. Select one time to highlight the specific rule that you expect to contain a notification message.
5. Confirm that your Block the message, but allow the sender to override and send action appears in
the lower portion of the rule summary.

Create custom Policy Tip notification text

This optional procedure will help you to customize the Policy Tip notification text that email senders see in their
email program. If you do this, your custom Policy Tip notification text will not appear unless you also configure a
DLP policy rule with an action that will cause the notification to appear. Keep in mind that there are default system
Policy Tip notifications that can be shown if you do not customize your Policy Tip notification text. To learn more
about the default text, see Policy Tips.
Use the EAC to create and manage custom Policy Tip notification text
1. In the EAC, go to Compliance management > Data loss prevention.
2. Select Policy Tip settings .
3. To add a new Policy Tip with your own customized message, select Add . For more information about the
action choices available, see Policy Tips.
To modify an existing Policy Tip, highlight the tip and select Edit .
To delete an existing Policy Tip, highlight it and select Delete and then confirm your action.
4. Select Save to finish modifying the Policy Tip and save your changes.
5. Select Close to finish managing your Policy Tips and save your changes.
Use the Shell to create custom Policy Tip notification text
The following example creates a new English-language Policy Tip that will block a message from being sent. The
text of this custom Policy Tip is changed to the following value: "This message appears to contain restricted
content and will not be delivered."

New-PolicyTipConfig -Name en\Reject -Value "This message appears to contain restricted content and will not be
delivered."

For more information about DLP cmdlets, see Messaging Policy and Compliance Cmdlets.
Use the Shell to modify custom Policy Tip notification text
The following example modifies an existing English-language, notify-only Policy Tip. The text of this custom Policy
Tip is changed to "Sending bank account numbers in email is not recommended."

Set-PolicyTipConfig en\NotifyOnly "Sending bank account numbers in email is not recommended."

For more information about DLP cmdlets, see Messaging Policy and Compliance Cmdlets.
How do you know this worked?
To verify that you have successfully created custom Policy Tip text, do the following:
1. In the EAC, go to Compliance management > Data loss prevention.
2. Select Policy Tip settings .
3. Select Refresh .
4. Confirm that your action, locale and text for that locale appear in the list.
For more information
Data loss prevention
Policy Tips
Transport rules
Exchange 2010 MailTips
 Document Fingerprinting
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Information workers in your organization handle many kinds of sensitive information during a typical day.
Document Fingerprinting makes it easier for you to protect this information by identifying standard forms that are
used throughout your organization. This topic describes the concepts behind Document Fingerprinting. If you'd
like to learn how to create a document fingerprint, see Protect form data with document fingerprinting.

Basic scenario for Document Fingerprinting

Document Fingerprinting is a Data Loss Prevention (DLP ) feature that converts a standard form into a sensitive
information type, which you can use to define transport rules and DLP policies. For example, you can create a
document fingerprint based on a blank patent template and then create a DLP policy that detects and blocks all
outgoing patent templates with sensitive content filled in. Optionally, you can set up Policy Tips to notify senders
that they might be sending sensitive information, and the sender should verify that the recipients are qualified to
receive the patents. This process works with any text-based forms used in your organization. Additional examples
of forms that you can upload include:
Government forms
Health Insurance Portability and Accountability Act (HIPAA) compliance forms
Employee information forms for Human Resources departments
Custom forms created specifically for your organization
Ideally, your organization already has an established business practice of using certain forms to transmit sensitive
information. After you upload an empty form to be converted to a document fingerprint and set up a
corresponding policy, the DLP agent will detect any documents in outbound mail that match that fingerprint.

How Document Fingerprinting works

You've probably already guessed that documents don't have actual fingerprints, but the name helps explain the
feature. In the same way that a person's fingerprints have unique patterns, documents have unique word patterns.
When you upload a file, the DLP agent identifies the unique word pattern in the document, creates a document
fingerprint based on that pattern, and uses that document fingerprint to detect outbound documents containing
the same pattern. That's why uploading a form or template creates the most effective type of document fingerprint.
Everyone who fills out a form uses the same original set of words and then adds his or her own words to the
document. As long as the outbound document isn't password protected and contains all the text from the original
form, the DLP agent can determine if the document matches the document fingerprint.
The following example shows what happens if you create a document fingerprint based on a patent template, but
you can use any form as a basis for creating a document fingerprint.
Example of a patent document matching a document fingerprint of a patent template
The patent template contains the blank fields "Patent title," "Inventors," and "Description" and descriptions for each
of those fields, that's the word pattern. When you upload the original patent template, it's in one of the supported
file types and in plain text. The DLP agent uses an algorithm to convert this word pattern into a document
fingerprint, which is a small Unicode XML file containing a unique hash value representing the original text, and
the fingerprint is saved as a data classification in Active Directory. (As a security measure, the original document
itself isn't stored on the service; only the hash value is stored, and the original document can't be reconstructed
from the hash value.) The patent fingerprint then becomes a sensitive information type that you can associate with
a DLP policy. After you associate the fingerprint with a DLP policy, the DLP agent detects any outbound emails
containing documents that match the patent fingerprint and deals with them according to your organization's
policy. For example, you might want to set up a DLP policy that prevents regular employees from sending
outgoing messages containing patents. The DLP agent will use the patent fingerprint to detect patents and block
those emails. Alternatively, you might want to let your legal department to be able to send patents to other
organizations because it has a business need for doing so. You can allow specific departments to send sensitive
information by creating exceptions for those departments in your DLP policy, or you can allow them to override a
policy tip with a business justification. For more detailed information about creating DLP policy rules and
exceptions, see DLP procedures, and to learn more about setting up policy tips that users can override, see Manage
policy tips.

Supported file types

Document Fingerprinting supports the same file types that are supported in transport rules. For a list of supported
file types, see Use transport rules to inspect message attachments in Office 365. One quick note about file types:
neither transport rules nor Document Fingerprinting supports the .dotx file type, which can be confusing because
that's a template file in Word. When you see the word "template" in this and other Document Fingerprinting topics,
it refers to a document that you have established as a standard form, not the template file type.

Limitations of document fingerprinting

The Document Fingerprinting DLP agent won't detect sensitive information in the following cases:
Password protected files
Files that contain only images
Documents that don't contain all the text from the original form used to create the document fingerprint

For more information

Protect form data with document fingerprinting
Integrating sensitive information rules with transport rules
DLP procedures
 Protect form data with document fingerprinting in
Exchange 2013
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

If your organization uses forms to collect sensitive information, users might try emailing those forms to outside
contacts, which creates a security risk. Data loss prevention (DLP ) in Exchange helps you protect that information
by detecting it with Document Fingerprinting. To use document fingerprinting, simply upload a blank form, such as
an intellectual property document, government form, or other standard form used in your organization. Then, add
the resulting document fingerprint to a DLP policy or transport rule. Here's how.

Document Fingerprinting

Use the EAC to create a document fingerprint

1. In the Exchange admin center EAC, go to compliance management > data loss prevention.
2. Click Manage document fingerprints.
3. On the document fingerprints page, click New to create a new document fingerprint.
4. Give the document fingerprint a Name and Description. (The name you choose will appear in the sensitive
information types list.)
5. To upload a form, click Add .
6. Choose a form, and click Open. (Make sure that the file you upload contains text, isn't password protected,
and is in one of the file types that are supported in transport rules. For a list of supported file types, see File
Types That Are Supported In Transport Rules. Otherwise, you'll get an error when you try creating the
fingerprint.) Repeat for any additional files you want to add to the document list for this document
fingerprint. You can also add or remove files from this document fingerprint later if you want.
7. Click Save.
The document fingerprint is now part of your sensitive information types, and you can add it to a DLP policy or
add it to a transport rule via the The message contains sensitive information... condition.

For more information about adding rules to a DLP policy, see the "Change a DLP policy" section of Manage DLP
policies, and for more information about modifying transport rules, see Integrating sensitive information rules with
transport rules. If you want to create a new policy, see Create a DLP policy from a template.

Use the Shell to create a classification rule package based on document

fingerprinting
TIP
Even though you can create and modify classification rule packages in the Shell, you might find that creating document
fingerprints is a little simpler in the EAC. We recommend you try it there before trying this procedure in the Shell.

DLP uses classification rule packages to detect sensitive content in messages. To create a classification rule package
based on a document fingerprint, use the New-Fingerprint and New-DataClassification cmdlets. Because the
results of New-Fingerprint aren't stored outside the data classification rule, you always run New-Fingerprint
and New-DataClassification or Set-DataClassification in the same PowerShell session. The following example
creates a new document fingerprint based on the file C:\My Documents\Contoso Employee Template.docx. You
store the new fingerprint as a variable so you can use it with the New-DataClassification cmdlet in the same
PowerShell session.

$Employee_Template = Get-Content "C:\My Documents\Contoso Employee Template.docx" -Encoding byte

$Employee_Fingerprint = New-Fingerprint -FileData $Employee_Template -Description "Contoso Employee Template"

Now, let's create a new data classification rule named "Contoso Employee Confidential" that uses the document
fingerprint of the file C:\My Documents\Contoso Customer Information Form.docx.

$Employee_Template = Get-Content "C:\My Documents\Contoso Customer Information Form.docx" -Encoding byte

$Customer_Fingerprint = New-Fingerprint -FileData $Customer_Form -Description "Contoso Customer Information
Form"
New-DataClassification -Name "Contoso Customer Confidential" -Fingerprints $Customer_Fingerprint -Description
"Message contains Contoso customer information."

You can now use the Get-DataClassification cmdlet to find all DLP data classification rule packages, and in this
example, "Contoso Customer Confidential" is part of the data classification rule packages list.
Finally, add the "Contoso Customer Confidential" data classification rule package to a DLP policy.

New-TransportRule -Name "Notify :External Recipient Contoso confidential" -NotifySender NotifyOnly -Mode
Enforce -SentToScope NotInOrganization -MessageContainsDataClassification @{Name=" Contoso Customer
Confidential"}
The DLP agent now detects documents that match the Contoso Customer Form.docx document fingerprint.
For syntax and parameter information, see New -Fingerprint, New -DataClassification, Set-DataClassification, and
Get-DataClassification.

For more information

Document Fingerprinting
Manage DLP policies
Integrating sensitive information rules with transport rules
 Information Rights Management
6/14/2019 • 16 minutes to read • Edit Online

Applies to: Exchange Server 2013

Every day, information workers use e-mail to exchange sensitive information such as financial reports and data,
legal contracts, confidential product information, sales reports and projections, competitive analysis, research and
patent information, and customer and employee information. Because people can now access their e-mail from
just about anywhere, mailboxes have transformed into repositories containing large amounts of potentially
sensitive information. As a result, information leakage can be a serious threat to organizations. To help prevent
information leakage, Microsoft Exchange Server 2013 includes Information Rights Management (IRM ) features,
which provide persistent online and offline protection of e-mail messages and attachments.

What is information leakage?

Leakage of potentially sensitive information can be costly for an organization and have wide-ranging impact on
the organization and its business, employees, customers, and partners. Local and industry regulations increasingly
govern how certain types of information are stored, transmitted, and secured. To avoid violating applicable
regulations, organizations must protect themselves against intentional, inadvertent, or accidental information
leakage.
The following are some consequences resulting from information leakage:
Financial damage: Depending on the size, industry, and local regulations, information leakage may result
in financial impact due to loss of business or due to fines and punitive damages imposed by courts or
regulatory authorities. Public companies may also risk losing market capitalization due to adverse media
coverage.
Damage to image and credibility: Information leakage can damage an organization's image and
credibility with customers. Moreover, depending on the nature of communication, leaked e-mail messages
can potentially be a source of embarrassment for the sender and the organization.
Loss of competitive advantage: One of the most serious threats from information leakage is the loss of
competitive advantage in business. Disclosure of strategic plans or disclosure of merger and acquisition
information can potentially lead to loss of revenue or market capitalization. Other threats include loss of
research information, analytical data, and other intellectual property.

Traditional solutions to information leakage

Although traditional solutions to information leakage may protect initial access to data, they often don't provide
constant protection. The following table lists some traditional solutions and their limitations.
Traditional solutions
SOLUTION DESCRIPTION LIMITATIONS
 SOLUTION DESCRIPTION LIMITATIONS

Transport Layer Security (TLS) TLS is an Internet standard protocol TLS only protects the SMTP session
used to secure communications between two SMTP hosts. In other
over a network by means of words, TLS protects information in
encryption. In a messaging motion, and it doesn't provide
environment, TLS is used to secure protection at the message-level or
server/server and client/server for information at rest. Unless the
communications. messages are encrypted using
another method, messages in the
By default, Exchange 2010 uses TLS sender's and recipients' mailboxes
for all internal message transfers. remain unprotected. For e-mail
Opportunistic TLS is also enabled sent outside the organization, you
by default for sessions with external can require TLS only for the first
hosts. Exchange first attempts to hop. After a remote SMTP host
use TLS encryption for the session, outside your organization receives
but if a TLS connection can't be the message, it can relay it to
established with the destination another SMTP host over an
server, Exchange uses SMTP. You unencrypted session. Because TLS
can also configure domain security is a transport layer technology, it
to enforce mutual TLS with external can't provide control over what the
organizations. recipient does with the message.

E-mail encryption Users can use technologies such as Users decide whether a message
S/MIME to encrypt messages. gets encrypted. There are
additional costs of a public key
infrastructure (PKI) deployment,
with the accompanying overhead of
certificate management for users
and protection of private keys.
After a message is decrypted,
there's no control over what the
recipient can do with the
information. Decrypted information
can be copied, printed, or
forwarded. By default, saved
attachments aren't protected.
Messages encrypted using
technologies such as S/MIME can't
be accessed by your organization.
The organization can't inspect
message content, and therefore
can't enforce messaging policies,
scan messages for viruses or
malicious content, or take any
other action that requires accessing
the content.

Finally, traditional solutions often lack enforcement tools that apply uniform messaging policies to prevent
information leakage. For example, a user sends a message containing sensitive information and marks it as
Company Confidential and Do Not Forward. After the message is delivered to the recipient, the sender or the
organization no longer has control over the information. The recipient can willfully or inadvertently forward the
message (using features such as automatic forwarding rules) to external e-mail accounts, subjecting your
organization to substantial information leakage risks.

IRM in Exchange 2013

In Exchange 2013, you can use IRM features to apply persistent protection to messages and attachments. IRM
uses Active Directory Rights Management Services (AD RMS ), an information protection technology in Windows
Server 2008 and later. With the IRM features in Exchange 2013, your organization and your users can control the
rights recipients have for e-mail. IRM also helps allow or restrict recipient actions such as forwarding a message
to other recipients, printing a message or attachment, or extracting message or attachment content by copying
and pasting. IRM protection can be applied by users in Microsoft Outlook or Microsoft Office Outlook Web App,
or it can be based on your organization's messaging policies and applied using transport protection rules or
Outlook protection rules. Unlike other e-mail encryption solutions, IRM also allows your organization to decrypt
protected content to enforce policy compliance.
AD RMS uses extensible rights markup language (XrML )-based certificates and licenses to certify computers and
users, and to protect content. When content such as a document or a message is protected using AD RMS, an
XrML license containing the rights that authorized users have to the content is attached. To access IRM -protected
content, AD RMS -enabled applications must procure a use license for the authorized user from the AD RMS
cluster.

NOTE
In Exchange 2013, the Prelicensing agent attaches a use license to messages protected using the AD RMS cluster in your
organization. For more details, see Prelicensing later in this topic.

Applications used to create content must be RMS -enabled to apply persistent protection to content using
AD RMS. Microsoft Office applications, such as Word, Excel, PowerPoint and Outlook are RMS -enabled and can
be used to create and consume protected content.
IRM helps you do the following:
Prevent an authorized recipient of IRM -protected content from forwarding, modifying, printing, faxing,
saving, or cutting and pasting the content.
Protect supported attachment file formats with the same level of protection as the message.
Support expiration of IRM -protected messages and attachments so they can no longer be viewed after the
specified period.
Prevent IRM -protected content from being copied using the Snipping Tool in Microsoft Windows.
However, IRM can't prevent information from being copied using the following methods:
Third-party screen capture programs
Use of imaging devices such as cameras to photograph IRM -protected content displayed on the screen
Users remembering or manually transcribing the information
To learn more about AD RMS, see Active Directory Rights Management Services.

AD RMS rights policy templates

AD RMS uses XrML -based rights policy templates to allow compatible IRM -enabled applications to apply
consistent protection policies. In Windows Server 2008 and later, the AD RMS server exposes a Web service that
can be used to enumerate and acquire templates. Exchange 2013 ships with the Do Not Forward template. When
the Do Not Forward template is applied to a message, only the recipients addressed in the message can decrypt
the message. The recipients can't forward the message, copy content from the message, or print the message. You
can create additional RMS templates on the AD RMS server in your organization to meet your IRM protection
requirements.
IRM protection is applied by applying an AD RMS rights policy template. Using policy templates, you can control
permissions that recipients have on a message. Actions such as replying, replying to all, forwarding, extracting
information from a message, saving a message, or printing a message can be controlled by applying the
appropriate rights policy template to the message.
For more information about rights policy templates, see AD RMS Policy Template Considerations.
For more information about creating AD RMS rights policy templates, see AD RMS Rights Policy Templates
Deployment Step-by-Step Guide.

Applying IRM protection to messages

In Exchange 2010, IRM protection can be applied to messages using the following methods:
Manually by Outlook users: Your Outlook users can IRM -protect messages with the AD RMS rights
policy templates available to them. This process uses the IRM functionality in Outlook, and not Exchange.
However, you can use Exchange to access messages, and you can take actions (such as applying transport
rules) to enforce your organization's messaging policy. For more information about using IRM in Outlook,
see Introduction to IRM for email messages.
Manually by Outlook Web App users: When you enable IRM in Outlook Web App, users can IRM -
protect messages they send, and view IRM -protected messages they receive. In Exchange 2013 Cumulative
Update 1 (CU1), Outlook Web App users can also view IRM -protected attachments using Web-Ready
Document Viewing. For more information about IRM in Outlook Web App, see Information Rights
Management in Outlook Web App.
Manually by Windows Mobile and Exchange ActiveSync device users: In the release to
manufacturing (RTM ) version of Exchange 2010, users of Windows Mobile devices can view and create
IRM -protected messages. This requires users to connect their supported Windows Mobile devices to a
computer and activate them for IRM. In Exchange 2010 SP1, you can enable IRM in Microsoft Exchange
ActiveSync to allow users of Exchange ActiveSync devices (including Windows Mobile devices) to view,
reply to, forward, and create IRM -protected messages. For more information about IRM in Exchange
ActiveSync, see Information Rights Management in Exchange ActiveSync.
Automatically in Outlook 2010 and later: You can create Outlook protection rules to automatically IRM -
protect messages in Outlook 2010 and later. Outlook protection rules are deployed automatically to
Outlook 2010 clients, and IRM -protection is applied by Outlook 2010 when the user is composing a
message. For more information about Outlook protection rules, see Outlook protection rules.
Automatically on Mailbox servers: You can create transport protection rules to automatically IRM -
protect messages on Exchange 2013 Mailbox servers. For more information about transport protection
rules, see Transport protection rules.

NOTE
IRM protection isn't applied again to messages that are already IRM-protected. For example, if a user IRM-protects a
message in Outlook or Outlook Web App, IRM protection isn't applied to the message using a transport protection
rule.

Scenarios for IRM protection

Scenarios for IRM protection are described in the following table.
Scenarios for IRM protection
 SENDING IRM-PROTECTED MESSAGES SUPPORTED REQUIREMENTS

Within the same on-premises Yes For requirements, see IRM

Exchange 2013 deployment Requirements later in this topic.

Between different forests in an on- Yes For requirements, see Configuring

premises deployment AD RMS to Integrate with Exchange
Server 2010 Across Multiple
Forests.

Between an on-premises Exchange Yes Use an on-premises

2013 deployment and a cloud- AD RMS server.
based Exchange organization
Export the trusted
publishing domain from
your on-premises AD RMS
server.
Import the trusted
publishing domain in your
cloud-based organization.

To external recipients No Exchange 2010 doesn't include a

solution for sending IRM-protected
messages to external recipients in a
non-federated organization.
AD RMS offers solutions using trust
policies. You can configure a trust
policy between your AD RMS
cluster and Microsoft account
(formerly known as Windows Live
ID). For messages sent between
two organizations, you can create a
federated trust between the two
Active Directory forests using
Active Directory Federation Services
(AD FS). To learn more, see
Understanding AD RMS Trust
Policies.

Decrypting IRM-protected messages to enforce messaging policies

To enforce messaging policies and for regulatory compliance, you must be able to access encrypted message
content. To meet eDiscovery requirements due to litigation, regulatory audits, or internal investigations, you must
also be able to search encrypted messages. To help with these tasks, Exchange 2013 includes the following IRM
features:
Transport decryption: To apply messaging policies, transport agents such as the Transport Rules agent
should have access to message content. Transport decryption allows transport agents installed on Exchange
2013 servers to access message content. For more information, see Transport decryption.
Journal report decryption: To meet compliance or business requirements, organizations can use
journaling to preserve messaging content. The Journaling agent creates a journal report for messages
subject to journaling and includes metadata about the message in the report. The original message is
attached to the journal report. If the message in a journal report is IRM -protected, journal report
decryption attaches a cleartext copy of the message to the journal report. For more information, see
 Journal report decryption .
IRM decryption for Exchange Search: With IRM decryption for Exchange Search, Exchange Search can
index content in IRM -protected messages. When a discovery manager performs an In-Place eDiscovery
search, IRM -protected messages that have been indexed are returned in search results. For more
information, see In-Place eDiscovery.

NOTE
In Exchange 2010 SP1 and later, members of the Discovery Management role group can access IRM-protected
messages returned by a discovery search and residing in a discovery mailbox. To enable this functionality, use the
EDiscoverySuperUserEnabled parameter with Set-IRMConfiguration cmdlet. For more information, see Configure
IRM for Exchange Search and In-Place eDiscovery.

To enable these decryption features, Exchange servers must have access to the message. This is accomplished by
adding the Federation mailbox, a system mailbox created by Exchange Setup, to the super users group on the
AD RMS server. For details, see Add the Federation Mailbox to the AD RMS Super Users Group.

Prelicensing
To view IRM -protected messages and attachments, Exchange 2013 automatically attaches a prelicense to
protected messages. This prevents the client from having to make repeated trips to the AD RMS server to retrieve
a use license, and enables offline viewing of IRM -protected messages and attachments. Prelicensing also allows
IRM -protected messages to be viewed in Outlook Web App. When you enable IRM features, prelicensing is
enabled by default.

IRM agents
In Exchange 2013, IRM functionality is enabled using transport agents in the Transport service on Mailbox
servers. IRM agents are installed by Exchange Setup on a Mailbox server. You can't control IRM agents using the
management tasks for transport agents.

NOTE
In Exchange 2013, IRM agents are built-in agents. Built-in agents aren't included in the list of agents returned by the Get-
TransportAgent cmdlet. For more information, see Transport agents.

The following table lists the IRM agents implemented in the Transport service on Mailbox servers.
IRM agents in the Transport service on Mailbox servers
AGENT EVENT FUNCTION

RMS Decryption agent OnEndOfData (SMTP) and Decrypts messages to allow access
OnSubmittedMessage to transport agents.

Transport Rules agent OnRoutedMessage Flags messages that match rule

conditions in a transport protection
rule to be IRM-protected by the
RMS Encryption agent.
 AGENT EVENT FUNCTION

RMS Encryption agent OnRoutedMessage Applies IRM protection to

messages flagged by the Transport
Rules agent and re-encrypts
transport decrypted messages.

Prelicensing agent OnRoutedMessage Attaches a prelicense to IRM-

protected messages.

Journal Report Decryption agent OnCategorizedMessage Decrypts IRM-protected messages

attached to journal reports and
embeds cleartext versions along
with the original encrypted
messages.

For more information about transport agents, see Transport agents.

IRM requirements
To implement IRM in your Exchange 2013 organization, your deployment must meet the requirements described
in the following table.
IRM requirements
SERVER REQUIREMENTS
SERVER REQUIREMENTS

AD RMS cluster Operating system Windows Server 2012,

Windows Server 2008 R2 or Windows Server 2008
SP2 with the hotfix Active Directory Rights
Management Services role in Windows Server
2008 is required.
Service connection point Exchange 2010 and
AD RMS-aware applications use the service
connection point registered in Active Directory to
discover an AD RMS cluster and URLs. AD RMS
allows you to register the service connection point
from within AD RMS Setup. If the account used to
set up AD RMS isn't a member of the Enterprise
Admins security group, service connection point
registration can be performed after setup is
complete. There is only one service connection
point for AD RMS in an Active Directory forest.
Permissions Read and Execute permissions to
the AD RMS server certification pipeline (
ServerCertification.asmx file on AD RMS
servers) must be assigned to the following:
Exchange Servers group or individual
Exchange servers
AD RMS Service group on AD RMS servers
By default, the ServerCertification.asmx file is
located in the
\inetpub\wwwroot\_wmcs\certification\ folder
on AD RMS servers. For details, see Set
Permissions on the AD RMS Server Certification
Pipeline.
AD RMS super users To enable transport
decryption, journal report decryption, IRM in
Outlook Web App, and IRM for Exchange Search,
you must add the Federation mailbox, a system
mailbox created by Exchange 2013 Setup, to the
super users group on the AD RMS cluster. For
details, see Add the Federation Mailbox to the AD
RMS Super Users Group.

Exchange Exchange 2010 or later is required.

The hotfix FIX: ArgumentNullException exception
error message when a .NET Framework 2.0 SP2-
based application tries to process a response with
zero-length content to an asynchronous ASP.NET
Web service request: "Value cannot be null" is
recommended for Microsoft .NET Framework 2.0
SP2.

Outlook Users can IRM-protect messages in Outlook.

Beginning with Outlook 2003, AD RMS templates
for IRM-protecting messages is supported.
Outlook protection rules are an Exchange 2010
and Outlook 2010 feature. Previous versions of
Outlook don't support this feature.
 SERVER REQUIREMENTS

Exchange ActiveSync Devices supporting Exchange ActiveSync protocol

version 14.1, including Windows Mobile devices,
can support IRM in Exchange ActiveSync. The
mobile e-mail application on a device must
support the RightsManagementInformation tag
defined in Exchange ActiveSync protocol version
14.1. In Exchange 2013, IRM in Exchange
ActiveSync allows users with supported devices to
view, reply to, forward, and create IRM-protected
messages without requiring the user to connect
the device to a computer and activate it for IRM.
For details, see Information Rights Management in
Exchange ActiveSync.

NOTE
AD RMS cluster is the term used for an AD RMS deployment in an organization, including a single server deployment.
AD RMS is a Web service. It doesn't require that you set up a Windows Server failover cluster. For high availability and load-
balancing, you can deploy multiple AD RMS servers in the cluster and use Network Load Balancing.

IMPORTANT
In a production environment, installing AD RMS and Exchange on the same server isn't supported.

Exchange 2013 IRM features support Microsoft Office file formats. You can extend IRM protection to other file
formats by deploying custom protectors. For more information about custom protectors, see Information
Protection and Control Partners in Independent Software Vendors.

Configuring and testing IRM

You must use the Exchange Management Shell to configure IRM features in Exchange 2013. To configure
individual IRM features, use the Set-IRMConfiguration cmdlet. You can enable or disable IRM for internal
messages, transport decryption, journal report decryption, Exchange Search, and Outlook Web App. For more
information about configuring IRM features, see Information Rights Management procedures.
After you set up an Exchange 2013 server, you can use the Test-IRMConfiguration cmdlet to perform end-to-end
tests of your IRM deployment. These tests are useful to verify IRM functionality immediately after initial IRM
configuration and on an ongoing basis. The cmdlet performs the following tests:
Inspects IRM configuration for your Exchange 2013 organization.
Checks the AD RMS server for version and hotfix information.
Verifies whether an Exchange server can be activated for RMS by retrieving a Rights Account Certificate
(RAC ) and client licensor certificate.
Acquires AD RMS rights policy templates from the AD RMS server.
Verifies that the specified sender can send IRM -protected messages.
Retrieves a super user use license for the specified recipient.
Acquires a prelicense for the specified recipient.
Extend Rights Management with the Rights Management connector
The Microsoft Rights Management connector (RMS connector) is an optional application that enhances data
protection for your Exchange 2013 server by employing cloud-based Microsoft Rights Management services.
Once you install the RMS connector, it provides continuous data protection during the lifespan of the information
and because these services are customizable, you can define the level of protection you need. For example, you
can limit email message access to specific users or set view -only rights for certain messages.
To learn more about the RMS connector and how to install it, see Rights Management connector.
 Transport protection rules
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Email messages and attachments increasingly contain business critical information such as product specifications,
business strategy documents, and financial data, or personally identifiable information (PII) such as contact details,
social security numbers, credit card numbers, and employee records. There are a number of industry-specific and
local regulations in many parts of the world that govern the collection, storage, and disclosure of PII.
To help protect sensitive information, organizations create messaging policies that provide guidelines about how
to handle this information. In Microsoft Exchange Server 2013, you can use transport protection rules to
implement these messaging policies by inspecting message content, encrypting sensitive email content, and using
rights management to control access to the content.
For management tasks related to managing IRM, see Information Rights Management procedures.

Transport protection rules and AD RMS

Transport protection rules allow you to use transport rules to IRM -protect messages by applying an Active
Directory Rights Management Services (AD RMS ) rights policy template.

NOTE
AD RMS is an information protection technology that works with Rights Management Service (RMS)-enabled applications
and clients to protect sensitive information online and offline. To use IRM protection in an on-premise Exchange deployment,
Exchange 2013 requires an on-premises deployment of AD RMS running on Windows Server 2008 or later.

AD RMS uses XML -based policy templates to allow compatible IRM -enabled applications to apply consistent
protection policies. In Windows Server 2008 and later, the AD RMS server exposes a Web service that can be
used to enumerate and acquire templates. Exchange 2013 ships with the Do Not Forward template.
When the Do Not Forward template is applied to a message, only the recipients addressed in the message can
decrypt the message. The recipients can't forward the message to anyone else, copy content from the message, or
print the message.
Additional RMS templates can be created in the on-premises AD RMS deployment to meet rights protection
requirements in your organization.

IMPORTANT
If a rights policy template is removed from the AD RMS server, you must modify any transport protection rules that use the
removed template. If a transport protection rule continues to use a rights policy template that's been removed, the AD RMS
server will fail to license the content to any of the recipients, and a non-delivery report (NDR) will be delivered to the sender.
In Windows Server 2008 and later, rights policy templates can be archived instead of deleted. Archived templates can still be
used to license content, but when you create or modify a transport protection rule, archived templates aren't included in the
list of templates.

For more information about creating AD RMS templates, see AD RMS Rights Policy Templates Deployment Step-
by-Step Guide.
Automatic protection using transport protection rules
Messages containing business critical information or PII can be identified by using a combination of transport rule
conditions, including regular expressions to identify text patterns such as social security numbers. Organizations
require different levels of protection for sensitive information. Some information may be restricted to employees,
contractors, or partners; while other information may be restricted only to full-time employees. The desired level
of protection can be applied to messages by applying an appropriate rights policy template. For example, users
may mark messages or email attachments as Company Confidential. As illustrated in the following figure, you can
create a transport protection rule to inspect message content for the words "Company Confidential", and
automatically IRM -protect the message.
For more information about creating transport rules to enforce rights protection, see Create a Transport
Protection Rule.

Persistent protection of email attachments

Users send business critical information and PII in email attachments using common Microsoft Office file formats
such as Microsoft Office Word, Excel, and PowerPoint. All of these file formats support persistent protection via
IRM, and you can make sure that the business critical information and PII in these documents are properly
protected. Transport protection rules apply the same protection to email messages and attachments in supported
file formats.

Transport rules agent and encryption agent

When you use transport protection rules to IRM -protect messages based on rule conditions, the Transport Rules
agent on the Transport service inspects messages. If they meet all the conditions and none of the exceptions, it
flags the message to be IRM -protected. The Encryption agent, a built-in transport agent that fires on the
OnRoutedMessage event, actually applies IRM protection to the message. The Encryption agent acts on
messages only if IRM is enabled for internal messages. For more information about enabling IRM, see Enable or
Disable IRM for Internal Messages.
When the transport service is restarted, and it processes the first message that requires IRM encryption, the
Encryption agent must be able to reach an AD RMS server in the organization. For subsequent messages, the
agent doesn't need to contact the AD RMS server. Upon failure to encrypt a message due to transient conditions,
Exchange retries the message three times at 10-minute intervals. After three retries, if the message can't be
encrypted, it isn't delivered to recipients. An NDR is sent to the sender. We recommend that you plan your
AD RMS deployment for high availability to make sure message flow isn't impacted.
When planning to use transport protection rules, you must consider the type of information you want to protect
and plan on creating rules accordingly. In Exchange 2013, transport rules have a large number of predicates that
allow you to inspect message content, including supported attachments, message headers, sender and recipient
addresses, their Active Directory attributes such as department, distribution group membership, and management
relationships of the sender with recipients. For more details about transport rule predicates available in Exchange
2013, see Transport rule conditions (predicates).
You must also consider the messaging traffic in your organization, and the number of messages that will be
protected using transport protection rules. Applying IRM protection to a large number of messages requires more
resources on the Mailbox server. Additionally, protecting a large number of messages or all messages also impacts
the client experience, particularly for Microsoft Outlook users.
 Outlook protection rules
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Every day, information workers exchange sensitive information by email, including financial reports and data,
customer and employee information, and confidential product information and specifications. In Microsoft
Exchange Server 2013, Microsoft Outlook, and Microsoft Office Outlook Web App, users can apply Information
Rights Management (IRM ) protection to messages by applying an Active Directory Rights Management Services
(AD RMS ) rights policy template. This requires an AD RMS deployment in the organization. For more information
about AD RMS, see Active Directory Rights Management Services.
However, when left to the discretion of users, messages may be sent in clear text without IRM protection. In
organizations that use email as a hosted service, there's a risk of information leakage as a message leaves the client
and is routed and stored outside the boundaries of an organization. Although email hosting companies may have
well-defined procedures and checks to help mitigate the risk of information leakage, after a message leaves the
boundary of an organization, the organization loses control of the information. Outlook protection rules can help
protect against this type of information leakage.
For management tasks related to managing IRM, see Information Rights Management procedures.

Automatic IRM protection in Outlook

In Exchange 2013, Outlook protection rules help your organization protect against the risk of information leakage
by automatically applying IRM -protection to messages in Exchange 2013. Messages are IRM -protected before
they leave the Outlook client. This protection is also applied to any attachments using supported file formats.
When you create Outlook protection rules on an Exchange 2013 server, the rules are automatically distributed to
Outlook 2010 by using Exchange Web Services. For Outlook 2010 to apply the rule, the AD RMS rights policy
template you specify must be available on users' computers.

IMPORTANT
If a rights policy template is removed from the AD RMS server, you must modify any Outlook protection rules that use the
removed template. If an Outlook protection rule continues to use a rights policy template that's been removed, and
transport decryption is enabled in the organization, the Decryption agent will fail to decrypt the message protected with a
template that's no longer available. If transport decryption is configured as mandatory, the Transport service will reject the
message and send a non-delivery report (NDR) to the sender. For more details about transport decryption, see Transport
decryption. For more details about AD RMS rights policy templates, see AD RMS Policy Template Considerations.
In Windows Server 2008 and later, rights policy templates can be archived instead of deleted. Archived templates can still be
used to license content, but when you create or modify an Outlook protection rule, archived templates aren't included in the
list of templates.

Outlook protection rules are similar to transport protection rules. Both are applied based on message conditions,
and both protect messages by applying an AD RMS rights protection template. However, transport protection
rules are applied in the Transport service on the Mailbox server by the Transport Rules agent. Outlook protection
rules are applied in Outlook 2010, before the message leaves the user's computer. Messages protected by an
Outlook protection rule enter the transport pipeline with IRM protection already applied. Additionally, messages
protected with an Outlook protection rule are also saved in an encrypted format in the Sent Items folder of the
sender's mailbox.
 NOTE
If transport decryption is enabled in your Exchange organization, messages that are IRM-protected by an Outlook protection
rule using the AD RMS server in your organization can be decrypted by the Decryption agent on Transport service. Message
content can be inspected by the Transport Rules agent and other transport agents installed on the Transport service. For
more details about transport decryption, see Transport decryption.

When you use transport protection rules, users have no indication of whether a message is going to be
automatically protected on the Transport service. When an Outlook protection rule is applied to a message in
Outlook 2010, users know if a message will be IRM -protected. If required, users can also select a different rights
policy template.

Creating Outlook protection rules

To create Outlook protection rules, you must use the New -OutlookProtectionRule cmdlet in the Exchange
Management Shell. For detailed instructions, see Create an Outlook Protection Rule.
When creating a rule, you can specify whether the user can override it, either by removing IRM -protection or by
applying a different AD RMS rights policy template than the one specified in the rule. If a user overrides the IRM
protection applied by an Outlook protection rule, Outlook 2010 inserts the X-MS-Outlook-Client-Rule-Overridden
header in the message, which allows you to determine that the rule was overridden by the user.

Predicates in Outlook protection rules

Outlook protection rules allow you to use three predicates to automatically apply IRM protection in Outlook 2010:
FromDepartment: The FromDepartment predicate looks up the sender's department attribute in Active
Directory and automatically IRM -protects the message if the sender's department matches the department
specified in the rule. For example, you can create an Outlook protection rule to automatically protect all
messages sent by the Research department.
SentTo: Your organization may need to protect messages sent to certain sensitive recipients, such as the All
Company or Finance distribution groups. Using the SentTo predicate, you can create an Outlook protection
rule to automatically IRM -protect messages sent to specified recipients.
SentToScope: The SentToScope predicate allows you to create an Outlook protection rule to automatically
IRM -protect messages sent inside or outside the organization. For example, you can use the SentToScope
predicate with the FromDepartment predicate to IRM -protect messages sent by a particular department to
internal users.
 Transport decryption
5/28/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, Microsoft Outlook 2010 and later, and Microsoft Office Outlook Web App,
users can use Information Rights Management (IRM ) to protect their messages. You can create Outlook
protection rules to automatically apply IRM protection to messages before they're sent from an Outlook 2010
client. You can also create transport protection rules to apply IRM protection to messages in transit that match the
rule conditions. Transport decryption allows access to IRM -protected messaging content to enforce messaging
policies.
For management tasks related to managing IRM, see Information Rights Management procedures.

Limitations of other encryption solutions

If it's critical that your organization protects sensitive information, including high business impact (HBI)
information and personally identifiable information (PII), consider encrypting e-mail messages and attachments.
E -mail encryption solutions such as S/MIME have been available for a long time. These encryption solutions have
seen varying degrees of adoption in organizations of different types. However, such solutions present the
following challenges:
Inability to apply messaging policies: Organizations also face compliance requirements that require
inspection of messaging content to make sure it adheres to messaging policies. However, messages
encrypted with most client-based encryption solutions, including S/MIME, prevent content inspection on
the server. Without content inspection, an organization can't validate that all messages sent or received by
its users comply with messaging policies. For example, to comply with a legal regulation, you've configured
a transport rule to detect PII, such as a social security number, and automatically apply a disclaimer to the
message. If the message is encrypted, the Transport Rules agent on the Transport service can't access
message content, and therefore won't apply the disclaimer. This results in a violation of the policy.
Decreased security: Antivirus software is unable to scan encrypted message content, further exposing an
organization to risk from malicious content such as viruses and worms. Encrypted messages are generally
considered to be trusted by most users, thereby increasing the likelihood of a virus spreading throughout
your organization. For example, you've configured an Outlook protection rule to automatically apply IRM
protection to all messages sent to the All Employees distribution list with the Company Confidential rights
management service (RMS ) template. A user's workstation is infected with a virus that propagates by
automatically using Reply All to reply to messages. If the message carrying the virus is encrypted, the
antivirus scanner can't scan the message.
Impact to custom transport agents: Many organizations develop custom transport agents for different
purposes, such as meeting additional processing requirements for compliance, security, or custom message
routing. Custom transport agents developed by an organization to inspect or modify messages are unable
to process encrypted messages. If the custom transport agents developed by your organization can't access
message content, message encryption may prevent your organization from meeting the goals for which the
custom transport agents are developed.

Using transport decryption for encrypted content

In Exchange 2013, IRM features address these challenges. If messages are IRM -protected, transport decryption
allows you to decrypt them in transit. IRM -protected messages are decrypted by the Decryption agent, a
compliance-focused transport agent.

NOTE
In Exchange 2013, the Decryption agent is a built-in agent. Built-in agents aren't included in the list of agents returned by
the Get-TransportAgent cmdlet. For more details, see Transport agents.

The Decryption agent decrypts the following types of IRM -protected messages:
Messages IRM -protected by the user in Outlook Web App.
Messages IRM -protected by the user in Outlook 2010.
Messages IRM -protected automatically by Outlook protection rules in Exchange 2013 and Outlook 2010.

IMPORTANT
Only messages IRM-protected by the AD RMS server in your organization are decrypted by the Decryption agent.

NOTE
Messages protected in-transit using transport protection rules aren't required to be decrypted by the Decryption agent. The
Decryption agent fires on the OnEndOfData and OnSubmit transport events. Transport protection rules are applied by the
Transport Rules agent, which fires on the OnRoutedMessage event, and IRM-protection is applied by the Encryption agent
on the OnRoutedMessage event. For more information about transport agents and a list of SMTP events on which they
can be registered, see Transport agents.

Transport decryption is performed on the first Exchange 2013 Transport service that handles a message in an
Active Directory forest. If a message is transferred to a Transport service in another Active Directory forest, the
message is decrypted again. After decryption, unencrypted content is available to other transport agents on that
server. For example, the Transport Rules agent on a Transport service can inspect message content and apply
transport rules. Any actions specified in the rule, such as applying a disclaimer or modifying the message in any
other way, can be taken on the unencrypted message. Third-party transport agents, such as antivirus scanners, can
scan the message for viruses and malware. After other transport agents have inspected the message and possibly
made modifications to it, it's encrypted again with the same user rights that it had before being decrypted by the
Decryption agent. The same message isn't decrypted again by other the Transport service on other Mailbox
servers in the organization.
Messages decrypted by the Decryption agent don't leave the Transport service without being encrypted again. If a
transient error is returned when decrypting or encrypting the message, the Transport service retries the operation
twice. After the third failure, the error is treated as a permanent error. If any permanent errors occur, including
when transient errors are treated as permanent errors after retries, the Transport service treats them as follows:
If the permanent error occurs during decryption, a non-delivery report (NDR ) is sent only if transport
decryption is set to Mandatory , and the encrypted message is sent with the NDR. For more details about
the configuration options available for transport decryption, see Configuring Transport Decryption later in
this topic.
If the permanent error occurs during re-encryption, an NDR is always sent without the decrypted message.
 IMPORTANT
Any custom or third-party agents installed on a Transport service have access to the decrypted message. You must consider
the behavior of such transport agents. We recommend that you test all custom and third-party transport agents
thoroughly before you deploy them in a production environment.
After a message is decrypted by the Decryption agent, if a transport agent creates a new message and embeds (attaches)
the original message to the new one, only the new message is protected. The original message, which becomes an
attachment to the new message, doesn't get re-encrypted. A recipient receiving such a message can open the attached
message and take actions such as forwarding or replying, which would bypass rights enforcement.

Configuring transport decryption

Transport decryption is configured by using the Set-IRMConfiguration cmdlet in the Exchange Management
Shell. However, before you configure transport decryption, you must provide Exchange 2013 servers the right to
decrypt content protected by your AD RMS server. This is done by adding the Federation mailbox to the super
users group configured on the AD RMS cluster in your organization.

IMPORTANT
In cross-forest AD RMS deployments where you have an AD RMS cluster deployed in each forest, you must add the
Federation mailbox to the super users group on the AD RMS cluster in each forest to allow the Transport service on an
Exchange 2013 Mailbox server or an Exchange 2010 Hub Transport server to decrypt the messages protected against each
AD RMS cluster.

For details, see Add the Federation Mailbox to the AD RMS Super Users Group.
Exchange 2013 allows two different settings when enabling transport decryption:
Mandatory: When transport decryption is set to Mandatory , the Decryption agent rejects the message and
returns an NDR to the sender if a permanent error is returned when decrypting a message. If your
organization doesn't want a message to be delivered if it can't be successfully decrypted and actions such as
antivirus scanning and transport rules are applied, you must choose this setting.
Optional: When transport decryption is set to Optional, the Decryption agent uses a best-effort approach.
Messages that can be decrypted are decrypted, but messages with a permanent error on decryption are
also delivered. If your organization prioritizes message delivery over messaging policy, you must use this
setting.
For more information about configuring transport decryption, see Enable or Disable Transport Decryption.
 Journal report decryption
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, Information Rights Management (IRM ) allows Microsoft Outlook 2010 and
later and Microsoft Office Outlook Web App users to protect their messages. You can create Outlook protection
rules to automatically apply IRM -protection to messages before they're sent from an Outlook 2010 client. You can
also create transport protection rules to apply IRM protection to messages in transit that match the rule
conditions.
To learn about Outlook protection rules, see Outlook protection rules.

Limitations of standard encryption solutions

If your organization encrypts messages by using traditional solutions such as S/MIME, your records managers
won't be able to inspect or search the encrypted content. Archiving encrypted messages that contain inaccessible
and unsearchable content may not meet business, regulatory, or compliance requirements. When faced with an
electronic discovery (eDiscovery) request, an inability to decrypt, search, and present content from encrypted
messages can be a challenge, and failure to do so may expose your organization to legal and financial risks.
Also, your organization's messaging policies may require journaled messages to be decrypted so the content can
be accessible to eDiscovery tools, automated processes, or records managers who access a journaling mailbox.
Journal report decryption in Exchange 2010 can help you meet these requirements.
To learn more about journaling, see Journaling.

Journal report decryption

Journal report decryption allows you to save a clear-text copy of IRM -protected messages in journal reports,
along with the original, IRM -protected message. If the IRM -protected message contains any supported
attachments that were protected by the Active Directory Rights Management Services (AD RMS ) cluster in your
organization, the attachments are also decrypted.

IMPORTANT
To use journal report decryption, you must have an Exchange Enterprise client access license (CAL). Journal report
decryption only supports premium journaling.

Decryption is performed by the Journal Report Decryption agent, a compliance-focused transport agent. The
Journal Report Decryption agent fires on the OnCategorizedMessage event. Messages protected in-transit using
transport protection rules are already encrypted by the Encryption agent, which fires on the OnRoutedMessage
event, before they get to the Journal Report Decryption agent. The Journal Report Decryption agent decrypts
these messages.

NOTE
In Exchange 2013, the Journal Report Decryption agent is a built-in agent. Built-in agents aren't included in the list of agents
returned by the Get-TransportAgent cmdlet. For more details, see Transport agents.
The agent decrypts the following types of IRM -protected messages:
Messages that were IRM -protected by the user in Outlook Web App.
Messages that were IRM -protected by the user in Outlook 2010.
Messages that were IRM -protected automatically in Outlook 2010 by using Outlook protection rules.
Messages that were IRM -protected automatically in transit by using transport protection rules.

IMPORTANT
Only messages that were IRM-protected by the AD RMS server in your organization are decrypted by the Journal Report
Decryption agent. The agent doesn't decrypt an attachment if it isn't protected at the same time as the message (and
therefore doesn't have the same use license), or if an IRM-protected file is attached to an unprotected message.

Configuring journal report decryption

Journal report decryption is configuredb using the Set-IRMConfiguration cmdlet in the Exchange Management
Shell. However, before you configure journal report decryption, you must assign Exchange 2013 servers the
permissions to decrypt content that's IRM -protected by your AD RMS server. To do this, you add the Federation
mailbox to the super users group configured on your organization's AD RMS cluster. For details, see Add the
Federation Mailbox to the AD RMS Super Users Group.

IMPORTANT
In cross-forest AD RMS deployments where you have an AD RMS cluster deployed in each forest, you must add the
Federation mailbox to the super users group on the AD RMS cluster in each forest to allow Exchange 2013 Transport service
to decrypt the messages protected against each AD RMS cluster.

For details about how to configure journal report decryption, see Enable or Disable Journal Report Decryption.
After you enable journal report decryption, the journaling mailbox may contain journal reports with sensitive
information in an unencrypted form. As a best practice, we recommend that access to the journaling mailbox be
monitored closely and restricted only to authorized individuals. This is a best-practice even if you're not using IRM
protection for e-mail.
 Information Rights Management in Outlook Web
App
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Information workers increasingly use e-mail to exchange sensitive information. To help secure this information,
organizations can use Information Rights Management (IRM ) to apply persistent protection to messaging content.
Prior to Microsoft Exchange Server 2010, effective use of IRM protection was limited to Outlook clients. In
Exchange Server 2007, Microsoft Outlook Web Access users were required to download the Rights Management
add-in for Microsoft Internet Explorer so they could access IRM -protected content.
In Exchange 2013, IRM in Outlook Web App allows your users to access the rich IRM functionality offered by
Exchange to apply persistent IRM -protection to messaging content.
The following IRM functionality is available in Outlook Web App:
Send IRM -protected messages: As shown in the following figure, Outlook Web App users can use the
permissions drop-down list and select a rights policy template to apply to the message. This allows users to
send IRM -protected messages from within Outlook Web App. Messages are IRM -protected by Client
Access servers.

IRM -protected attachments: When users send an IRM -protected message from Outlook Web App, any
files attached to the message also receive the same IRM protection and are protected by using the same
rights policy template as the message. In Exchange 2013, IRM protection is applied to files associated with
Microsoft Office Word, Excel, and PowerPoint, as well as .xps files and e-mail messages. IRM protection is
applied to an attachment only if it's not already IRM -protected. To learn more about Active Directory Rights
Management Services (AD RMS ) rights policy templates, see Information Rights Management.

NOTE
IRM in Outlook Web App protects only the supported file attachments mentioned in this section. Attachments that
use unsupported file formats aren't protected. When Outlook Web App users protect a message and attach a file of
an unsupported type, a notification is displayed informing the users that only supported file types are protected.
 IMPORTANT
IRM protection can't be applied to a message that's already signed or encrypted by using S/MIME. To apply IRM
protection, S/MIME signature and encryption must be removed from the message. The same applies for IRM-
protected messages; users can't sign or encrypt them by using S/MIME.

Read IRM -protected messages: Messages protected by senders using your organization's AD RMS
cluster are rendered in the preview pane in Outlook Web App. No add-ins need to be installed, and the
computer doesn't need to be enrolled in the AD RMS deployment. When a user opens a message or views
it in the preview pane, the message is decrypted by using the use license added by the Pre-licensing agent.
After decryption, the message is displayed in the preview pane. If a pre-license isn't available, Outlook Web
App requests one from the AD RMS server and then renders the message. When reading IRM -protected
attachments in Outlook Web App, Web-Ready Document Viewing isn't available.

NOTE
IRM in Outlook Web App can't prevent users from taking screen captures by using Print Screen functionality in the
way Outlook and other Office applications do. This impacts the EXTRACT right, which prevents message content from
being copied, if specified in the AD RMS rights policy template.

Cross-browser, multiple platform IRM support: IRM in Outlook Web App offers cross-browser, multiple
platform IRM support. IRM in Outlook Web App is supported in all browsers supported by Exchange 2013,
including on Apple Macintosh and Linux operating systems. To learn more about supported browsers and
operating systems, see Outlook Web App Supported Browsers.
WebReady Document Viewing: In Exchange 2013, users can view supported IRM -protected attachments
by using WebReady Document Viewing. This allows users to view supported attachments without having to
download the attachment use the associated application.
Looking for management tasks related to managing IRM? See Information Rights Management procedures.

Enabling IRM in Outlook Web App

To enable IRM in Outlook Web App, you must add the Federation mailbox, a system mailbox created by Exchange
2013 Setup, to the super users group in AD RMS. For details, see Add the Federation Mailbox to the AD RMS
Super Users Group. This allows Exchange 2013 servers to access IRM -protected messages.
You must also enable IRM in Outlook Web App by using the Set-IRMConfiguration cmdlet in the Exchange
Management Shell. This enables IRM in Outlook Web App for your Exchange 2013 organization. You can disable
or enable IRM in Outlook Web App for an Outlook Web App virtual directory. You can also control IRM in
Outlook Web App at the following levels of granularity:
Per-Outlook Web App virtual directory: To enable or disable IRM in Outlook Web App for an Outlook
Web App virtual directory, use the Set-OWAVirtualDirectory cmdlet and set the IRMEnabled parameter
to $false or $true (default). This allows you to disable IRM in Outlook Web App for one virtual directory
on an Exchange 2013 Client Access server, while keeping it enabled on another virtual directory on a
different Client Access server.
Per-Outlook Web App mailbox policy: To enable or disable IRM in Outlook Web App for an Outlook
Web App mailbox policy, use the Set-OWAMailboxPolicy cmdlet and set the IRMEnabled parameter to
$false or $true (default). This allows you to enable IRM in Outlook Web App for one set of users and
disable it for another set of users by assigning them a different Outlook Web App mailbox policy.
For more information, see Enable or Disable Information Rights Management on Client Access Servers.
 Information Rights Management in Exchange
ActiveSync
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Information workers often use e-mail to exchange sensitive information. To help secure this information,
organizations can use Information Rights Management (IRM ) to apply persistent protection to messaging content.
Because mobile devices are increasingly being used to access e-mail, it's important that your mobile device users
be able to create and consume IRM -protected content.

Mobile IRM protection in Exchange 2013

In Exchange 2013, IRM in Microsoft Exchange ActiveSync allows your users to access rich IRM functionality on
any supported Exchange ActiveSync device without having to configure AD RMS permissions or connect the
device to a computer and activate it for IRM. Also, the mobile device doesn't need to be running Windows.
Exchange ActiveSync is licensed by Microsoft to mobile device manufacturers, original equipment manufacturers
(OEMs), and others. For a list of current Exchange ActiveSync licensees, expand the "Exchange ActiveSync
Protocol" section on the Microsoft Technology Licensing page.
Using IRM in Exchange ActiveSync, mobile device users can:
Create IRM -protected messages.
Read IRM -protected messages.
Reply to and forward IRM -protected messages.

Requirements
The following requirements apply:
The Client Access servers in your organization must be running Exchange 2010 SP1 or later.
An AD RMS server must be deployed in your organization.
IRM must be enabled for internal messages. This is a prerequisite for all IRM features in Exchange 2010.
For details, see Enable or Disable IRM for Internal Messages.
IRM must be enabled in the Exchange ActiveSync mailbox policy. You can enable or disable IRM for
different sets of users using different Exchange ActiveSync mailbox policies.
Devices that support Exchange ActiveSync protocol version 14.1, including Windows phones, can support
IRM in Exchange ActiveSync. The device's mobile e-mail application must support the
RightsManagementInformation tag defined in Exchange ActiveSync version 14.1.

Security
When you enable IRM in Exchange ActiveSync, the Client Access server decrypts IRM -protected messages before
providing the messages for access by the supported mobile device. Upon synchronization, IRM -protected
messages reside on the mobile device in an unencrypted format. IRM protection is enforced by the IRM -capable
e-mail client application on the mobile device.
IRM in Exchange ActiveSync doesn't decrypt IRM -protected attachments on the Client Access server. Access to
IRM -protected files is enforced by the application used to create or view the file. For example, on a Windows
phone, IRM protection for Microsoft Office files is enforced by Microsoft Office Mobile. To access IRM -protected
Office files, users must connect the device to a computer and activate Office Mobile with the RMS server.
When enabling IRM in Exchange ActiveSync, we recommend using the Exchange ActiveSync policy settings
shown in the following table to help secure mobile devices.
Exchange ActiveSync policy settings
CONFIGURE USING THE NEW EXCHANGE CONFIGURE USING THE NEW-
SETTING ACTIVESYNC MAILBOX POLICY WIZARD ACTIVESYNCMAILBOXPOLICY CMDLET

Require that the user enter a Select the Require password Set the DevicePasswordEnabled
password to access information on check box. parameter to $true .
their mobile device.

Enable encryption for the mobile Select the Require password Set the RequireDeviceEncryption
device. check box, and then select the parameter to $true .
Require encryption on device
check box.
IMPORTANT
When you set the
RequireDeviceEncryption
parameter to $true , mobile
devices that don't support device
encryption will be unable to
connect.

Don't allow non-provisionable Clear the Allow non- Set the

mobile devices to synchronize with provisionable devices check box. AllowNonProvisionableDevices
the Exchange server. parameter to $false .

To learn more, see Mobile device mailbox policies.

Enabling IRM in Exchange ActiveSync

To enable IRM in Exchange ActiveSync, perform the following tasks:
1. Add the Federation mailbox (a system mailbox created by Exchange 2013 and Exchange 2010 Setup) to the
super users group in AD RMS. This allows Exchange 2013 and Exchange 2010 servers to access IRM -
protected messages. For details, see Add the Federation Mailbox to the AD RMS Super Users Group.
2. Use the Set-IRMConfiguration cmdlet in the Exchange Management Shell to enable IRM on the Client
Access server. This enables IRM in Exchange ActiveSync and IRM in Microsoft Office Outlook Web App for
your organization. For details, see Enable or Disable Information Rights Management on Client Access
Servers.
 Information Rights Management logging
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, Information Rights Management (IRM ) operations are logged in IRM logs.
IRM logs help you monitor and troubleshoot interactions between the Rights Management Services (RMS ) client
on an Exchange 2013 server and the Active Directory Rights Management Services (AD RMS ) cluster in your
organization.
To learn about IRM, see Information Rights Management.
Looking for management tasks related to IRM? See Information Rights Management procedures.

Structure of IRM logs

By default, IRM logs are located in C:\Program Files\Microsoft\Exchange Server\V14\Logging\IRMLogs.
The naming convention for IRM log files is <Process>_<Process identifier or IIS AppPool
identifier>_IRMLOGyyyymmdd-nnnn.log, where:
<Process> = process that creates the log file. For example, on Transport service, this will be EdgeTransport.
<Process identifier or IIS AppPool identifier> = numerical ID of the process.
yyyymmdd = Coordinated Universal Time (UTC ) date when the log file was created.
nnnn = instance number, which starts at 1 for each day.
An example IRM log file name is EdgeTransport_1056_IRMLOG20101201-1.log.
The following table shows the logs generated on different server roles.
Logs on server roles
SERVER ROLE IRM LOG FILE NAME DESCRIPTION

Transport service EdgeTransport_<Process This log is used to record all RMS

identifier>_IRMLOGyyyymmdd-nn transactions made by the transport
nn.log pipeline on Transport service (for
example, transport protection rules
and journal report decryption). The
process identifier (PID) of the
edgetransport.exe process is used
to generate the log file name.

Mailbox msftefd_<Process This log is used to record all RMS

identifier>_IRMLOGyyyymmdd-nn transactions that occur during
nn.log search and index requests.
Exchange 2013 Mailbox servers use
the msftefd.exe process for content
indexing. The PID of the msftefd.exe
process is used to generate the log
file name.
 SERVER ROLE IRM LOG FILE NAME DESCRIPTION

Client Access w3wp_MSExchangeOWAAppOol_IR This log is used to record all

MLOGyyyymmdd-nnnn.log transactions for IRM in Microsoft
Office Outlook Web App.

All Exchange 2013 server roles w3wp_MSExchangePowerShellAppP This log is used to record all IRM
ool_IRMLOGyyyymmdd-nnnn.log RMS transactions issued from
Windows PowerShell, for example,
when issuing the Test-
IRMConfiguration cmdlet.

Logging process
Information is written to the log file until the file size reaches its maximum specified value. When the maximum
size is reached, a log file that has an incremental instance number is created. This process is repeated throughout
the day. Circular logging deletes the oldest log files when the IRM log directory reaches its maximum specified size
or when a log file reaches the maximum age specified in the IRM logging configuration on each server.

Information written to IRM logs

IRM log files are text files that contain data in comma-separated value (CSV ) format. Each IRM log has a header
that contains the following information:
#Software: Name of the software that created the IRM log file. Typically, the value is
Microsoft Exchange Server .

#Version: Version number of the software that created the IRM log file.
#Log-type: Log type value, which is Rms Client Manager Log .
#Date: The UTC date and time when the log file was created. The UTC date and time is represented in the
ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where:
yyyy = year
mm = month
dd = day
T = time designator used to show the start of the time component
hh = hour
mm = minute
ss = second
fff = fractions of a second
Z = Zulu, which is another way to denote UTC
#Fields: Comma-delimited field names used in IRM log files.
The IRM log stores each RMS transaction event on a single line, organized in comma-separated fields. The
following table lists the fields in IRM logs for all server roles that have IRM features enabled.
 FIELD DESCRIPTION

Date-time Lists the UTC timestamp.

Feature Lists the RMS client feature used. Valid values include:
RacClc

Template

Prelicense

UseLicense

Signature verification
ServerInfo

Event-Type Lists the event type. Valid values include:

Acquire An RMS license or template is
requested.
Success An RMS license or template is
acquired successfully.
Exception An error has occurred.
Queued A request is pending.

Tenant-Id Reserved for internal Microsoft use.

Server-url Lists the RMS server URL accessed during the

operation.

Context Used by the calling process to tie multiple RMS

transactions together. Valid values include:
MessageID: <Actual message ID>

MailboxGuid: <Mailbox GUID>

AttachmentFileName: <File name>

Transaction-id Identifies a unique transaction. All events that occur

during one transaction have the same transaction ID.

Managing IRM logs

On each server role that has IRM features enabled, IRM logging is enabled by default. For each server role, you
can modify the following IRM log configuration by using the server role's corresponding Set cmdlet. For example,
to configure IRM logging on a Mailbox server, you use the Set-MailboxServer cmdlet.
Configuration parameters for IRM logs
 PARAMETER DESCRIPTION

IrmLogEnabled Enables logging of IRM transactions. IRM logging is

enabled by default. To disable IRM logging for a server
role, set the parameter to $false .

IrmLogMaxAge Specifies the maximum age for an IRM log file. Files older
than the specified age are deleted. The default value is
30.00:00:00 (30 days).

IrmLogMaxDirectorySize Specifies the maximum size of all IRM logs in the

connectivity log directory. When a directory reaches its
maximum file size, the server deletes the oldest log files
first. The default value is 250 MB .

IrmLogMaxFileSize Specifies the maximum file size for a single log file. When a
file reaches the specified size, a log file is created, and the
instance number is incremented. The default value is
10 MB .

IrmLogPath Specifies the IRM log location. The default path is

%ExchangeInstallPath%Logging\IRMLogs.

For detailed syntax and parameter information, see the following topics:
Set-MailboxServer
Set-ClientAccessServer
Set-TransportService
 Information Rights Management procedures
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Enable or Disable IRM for Internal Messages
Create a Transport Protection Rule
Create an Outlook Protection Rule
Remove an Outlook Protection Rule
Add the Federation Mailbox to the AD RMS Super Users Group
Enable or Disable Transport Decryption
Configure IRM for Exchange Search and In-Place eDiscovery
Enable or Disable Journal Report Decryption
Enable or Disable Information Rights Management on Client Access Servers
Enable or Disable Information Rights Management Logging
 Enable or Disable IRM for Internal Messages
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, Information Rights Management (IRM ) is enabled by default for internal
messages. This allows you to create transport protection rules and Microsoft Outlook protection rules to IRM -
protect messages in transport and on Microsoft Outlook 2010 and later clients. Enabling IRM for internal
messages is a prerequisite for all other IRM features in Exchange Server 2013, such as transport decryption,
journal rule decryption, IRM in Microsoft Office Outlook Web App, and IRM in Microsoft Exchange ActiveSync.

WARNING
Disabling IRM for internal messages disables all IRM features in the Exchange organization. The client-side IRM features in
Outlook (for example, the ability to read, reply to, forward, and create IRM-protected messages using an Active Directory
Rights Management Services (AD RMS) server) aren't affected.

For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Rights protection" entry in the Messaging policy and compliance
permissions topic.
You can't use the Exchange admin center (EAC ) to enable or disable IRM for internal messages. You must
use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable IRM for internal messages

This example enables IRM for internal messages for the Exchange organization.

Set-IRMConfiguration -InternalLicensingEnabled $true

For detailed syntax and parameter information, see Set-IRMConfiguration.

Use the Shell to disable IRM for internal messages

This example disables IRM for internal messages for the Exchange organization.
 Set-IRMConfiguration -InternalLicensingEnabled $false

For detailed syntax and parameter information, see Set-IRMConfiguration.

How do you know this worked?

To verify that you've enabled or disabled IRM for internal messages, use the Get-IRMConfiguration cmdlet to
check the configuration.
 Create a Transport Protection Rule
6/6/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use transport protection rules to apply persistent rights protection to messages based on properties such
as sender, recipient, message subject, and content.

WARNING
Before you create transport rules in your production environment, we recommend creating them in a test environment and
testing them thoroughly. The transport rules created in this topic are examples. You can create transport rules by using the
appropriate transport rule predicates and values based on your requirements.

For additional management tasks related to Information Rights Management (IRM ), see Information Rights
Management procedures.

What do you need to know before you begin?

Estimated time to completion: 2-5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport rules" entry in the Messaging policy and compliance permissions
topic.
A server running Active Directory Rights Management Services (AD RMS ) must be available in your
organization and contain existing RMS templates.
If you configure transport protection rules to protect messages using IRM, and you also use journaling,
consider enabling journal report decryption to allow the Journaling agent to save an unencrypted copy of
the message in the journal report. To learn more, see Journal report decryption .
After you create a transport protection rule, if the rule can't be applied to messages because an AD RMS
server is unavailable, messages will be queued by the Transport service on Mailbox servers. Depending on
the volume of these messages, additional disk space may be consumed on Mailbox servers. Exchange will
attempt to IRM -protect the message three times. After these attempts, if the AD RMS server is unreachable
or the message can't be IRM -protected, a non-delivery report (NDR ) is sent to the sender.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create a transport protection rule

1. Navigate to Mail flow > Rules.
2. In the list view, click New .
3. In New Rule, first click More options, and then complete the following fields:
 Name: Type a name for the transport rule.
Apply this rule if: Select a condition and enter any required values for the condition. To add more
conditions, click Add condition.

IMPORTANT
If you don't select any conditions when creating a transport protection rule, all messages handled by
Exchange 2013 servers with the Transport service in your organization are IRM-protected. IRM-protecting all
messages requires more resources. Therefore, we recommend that you plan your Mailbox server and
AD RMS deployment accordingly.

Do the following: Select Apply rights protection to the message with and then use the Select
RMS template dialog box to select a template.
Except if: (Optional) Click Add exception to specify an exception to the rule.
4. Click Save to create the transport rule.

Use the Shell to create a transport protection rule

To create a transport protection rule, you must have existing RMS templates in your AD RMS deployment.
This example retrieves the available templates from your AD RMS cluster.

Get-RMSTemplate | format-list

For detailed syntax and parameter information, see Get-RMSTemplate.

This example creates the transport protection rule Protect-BusinessCriticalProject. The rule IRM -protects
messages that contain the phrase "Business Critical" in the Subject field with the Do Not Forward
template.

NOTE
The SubjectContainsWords predicate is used in this example. You can use any combination of transport rule
predicates to form the conditions and exceptions for the rule. For information about the available predicates, see
Transport rule conditions (predicates).

New-TransportRule -Name "Protect-BusinessCriticalProject" -SubjectContainsWords "Business Critical" -

ApplyRightsProtectionTemplate "Do Not Forward"

For detailed syntax and parameter information, see New -TransportRule.

How do you know this worked?

To verify that you have successfully created a transport protection rule, do one of the following:
Use the EAC to verify that the rule has been created, and then click Edit to view the rule's properties.
Use the Get-TransportRule cmdlet to retrieve the rule. For an example of how to retrieve a rule, see
Examples in Get-TransportRule.
Using Outlook, Outlook Web App, or a mobile device, send a test message that meets the rule conditions
and check whether the message received by the recipient is IRM -protected.
 Create an Outlook Protection Rule
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Using Microsoft Outlook protection rules, you can protect messages with Information Rights Management (IRM )
by applying an Active Directory Rights Management Services (AD RMS ) template in Outlook 2010 before the
messages are sent.
For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to completion: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Rights protection" entry in the Messaging policy and compliance
permissions topic.
You must have an AD RMS server deployed in the same Active Directory forest as your server running
Microsoft Exchange Server 2013.
If you configure Outlook protection rules to IRM -protect messages, consider enabling transport decryption
to allow transport agents, including the Transport Rules agent, to decrypt and access the message. If you
use journaling, you should also consider enabling journal report decryption to allow the Journaling agent to
save an unencrypted copy of the message in the journal report. For more information, see Journal report
decryption.
You can't use the Exchange admin center (EAC ) to create Outlook protection rules. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to create an Outlook protection rule

This example creates the Outlook protection rule Project Contoso. The rule protects messages sent to the
ContosoPMs distribution group with the AD RMS template Business Critical.

New-OutlookProtectionRule -Name "Project Contoso" -SentTo "[email protected]" -

ApplyRightsProtectionTemplate "Business Critical"

NOTE
When you use the SentTo predicate for an Outlook protection rule and specify a distribution group, only messages
addressed to the distribution group in the To, Cc, or Bcc fields are IRM-protected. IRM protection isn't applied to messages
addressed to individual members of the distribution group.
You can also use the FromDepartment and SentToScope predicates to apply IRM protection to messages sent from
users in the specified department or messages sent to the specified scope ( InOrganization for internal messages,
All for all recipients).

For detailed syntax and parameter information, see New -OutlookProtectionRule.

How do you know this worked?

To verify that you have successfully created an Outlook protection rule, do the following:
Run the Get-OutlookProtectionRule cmdlet to make sure that the rule has been created and to view the
rule's properties. For an example of how to retrieve an Outlook protection rule, see Examples in Get-
OutlookProtectionRule.
Use Outlook 2010 to create a test message that meets the rule's condition and make sure the rule is
triggered on the client.

NOTE
It may take some time for an Outlook protection rule to be available in Outlook.
 Remove an Outlook Protection Rule
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Using Microsoft Outlook protection rules, you can protect messages with Information Rights Management (IRM )
by applying an Active Directory Rights Management Services (AD RMS ) template in Outlook 2010 before the
messages are sent. To prevent an Outlook protection rule from being applied, you can disable the rule. Removing
an Outlook protection rule removes the rule definition from Active Directory.
For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to completion: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Rights protection" entry in the Messaging policy and compliance
permissions topic.
You can't use the Exchange admin center (EAC ) to remove Outlook protection rules. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to remove an Outlook protection rule

This example removes the Outlook protection rule OPR -DG -Finance.

Remove-OutlookProtectionRule -Identity "OPR-DG-Finance"

For detailed syntax and parameter information, see Remove-OutlookProtectionRule.

Use the Shell to remove all Outlook protection rules

This example removes all Outlook protection rules in the Exchange organization.

Get-OutlookProtectionRule | Remove-OutlookProtectionRule

For detailed syntax and parameter information, see Get-OutlookProtectionRule and Remove-
OutlookProtectionRule.

How do you know this worked?

To verify that you have successfully removed an Outlook protection rule, use the Get-OutlookProtectionRule
cmdlet to retrieve Outlook protection rules. For an example of how to retrieve Outlook protection rules, see
Examples in Get-OutlookProtectionRule.
 Add the Federation Mailbox to the AD RMS Super
Users Group
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

For the following Microsoft Exchange Server 2013 Information Rights Management (IRM ) features to be
enabled, you must add the Federation mailbox (a system mailbox created by Exchange 2013 Setup) to the super
users group on your organization's Active Directory Rights Management Services (AD RMS ) cluster:
IRM in Microsoft Office Outlook Web App
IRM in Exchange ActiveSync
Journal report decryption
Transport decryption
You can configure a mail-enabled distribution group as a super users group in AD RMS. Members of the
distribution group are granted an owner use license when they request a license from the AD RMS cluster. This
allows them to decrypt all RMS -protected content published by that cluster. Whether you use an existing
distribution group or create a distribution group and configure it as the super users group in AD RMS, we
recommend that you dedicate the distribution group for this purpose and configure the appropriate settings to
approve, audit, and monitor membership changes.

WARNING
Configuring a super users group in AD RMS allows group members to decrypt IRM-protected content. We recommend
that you take adequate measures to control and monitor group membership and enable auditing to track membership
changes. You can also limit unwanted changes to group membership by configuring the group as a restricted group using
Group Policy. For details, see Restricted Groups Policy Settings.

For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to complete: 15 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Distribution groups" entry in the Recipients Permissions topic.
An AD RMS cluster must be deployed in the Active Directory forest.
If a super users group is already configured on an AD RMS cluster, any modifications to the distribution
group membership can take up to 24 hours to be refreshed by the AD RMS cluster. This is a result of
caching the group membership on the cluster.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
 TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Use the Shell to add the Federation mailbox to a distribution

group
If a distribution group has been created and configured as a super users group in the AD RMS cluster, you can
add the Exchange 2013 Federation mailbox as a member of that group. If a super users group isn't configured,
you must create a distribution group and add the Federation mailbox as a member.
1. Create a distribution group dedicated for use as an AD RMS super users group. For details, see Create
and manage distribution groups.
2. Add the user FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 to the new distribution group.
The Federation mailbox is a system mailbox, and therefore not visible in the EAC. To add it to a
distribution group, you must use the Add-DistributionGroupMember cmdlet from the Shell.
This example adds the Federation mailbox to the ADRMSSuperUsers distribution group.

Add-DistributionGroupMember ADRMSSuperUsers -Member FederatedEmail.4c1f4d8b-8179-4148-93bf-

00a95fa1e042

For detailed syntax and parameter information, see Add-DistributionGroupMember.

Step 2: Use AD RMS to set up a super users group

Perform the following procedure on an AD RMS cluster. The account used to perform this procedure must be a
member of the AD RMS Enterprise Administrators local group on the AD RMS server.
1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.
2. In the console tree, expand Security Policies, and then click Super Users.
3. In the action pane, click Enable Super Users.
4. In the result pane, click Change Super User Group to open the Super Users property sheet.
5. In the Super user group box, type the email address of the distribution group you created in the previous
procedure, or click Browse to select a distribution group.

How do you know this worked?

After you have added the Federation mailbox to a new or existing distribution group, use the Get-
DistributionGroupMember cmdlet to check the membership of the group.
For an example of how to check distribution group membership, see Example 1 in Get-
DistributionGroupMember.
After you have used AD RMS to set up a super users group, you can use the following methods to verify that the
super users group has been configured correctly. Additionally, you can use Test-IRMConfiguration cmdlet to
verify IRM functionality.
Use the AD RMS console to verify that the correct group has been configured as the super users group.
Run the following PowerShell command on an AD RMS server to retrieve the super users group.
IMPORTANT
The ADRMSAdmin PowerShell module is available in Windows Server 2008 R2 and later.

Import-Module ADRMSAdmin
New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost
Get-ItemProperty -Path MyRmsAdmin:\SecurityPolicy\SuperUser
 Enable or Disable Transport Decryption
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Enabling transport decryption allows the Transport Rules agent on Microsoft Exchange Server 2013 Mailbox
servers to access content in messages protected by Information Rights Management (IRM ). As a result, other
transport agents can access message content and possibly make changes to it. For example, the Transport Rules
agent may need to inspect message content and apply transport rules (such as rules that apply a disclaimer to the
message). To successfully decrypt IRM -protected messages, you must add the Federated Delivery mailbox to the
super users group configured on your Active Directory Rights Management Services (AD RMS ) server.

IMPORTANT
Members of the super users group are granted an owner use license when they request a license from the AD RMS cluster.
This allows them to decrypt all RMS-protected content created by that AD RMS cluster.

When enabling transport decryption, you can specify the following settings:
Mandatory: Rejects messages that can't be decrypted and returns a non-delivery report (NDR ) to the
sender.
Optional: Uses a best-effort approach to decryption. If possible, messages are decrypted, but they're
delivered even if decryption fails. This is the default setting.
To learn more about transport decryption, see Transport decryption.
For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to complete: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Rights protection" entry in the Messaging policy and compliance
permissions topic.
An AD RMS server exists in the Active Directory forest and is accessible.
The Federated Delivery mailbox has been added to the AD RMS super users group. For details, see Add the
Federation Mailbox to the AD RMS Super Users Group.
You can't use the Exchange admin center (EAC ) to enable transport decryption. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable transport decryption

This example enables transport decryption for the Exchange 2013 organization. Messages that can't be decrypted
are rejected and an NDR is returned to the sender.

Set-IRMConfiguration -TransportDecryptionSetting Mandatory

For detailed syntax and parameter information, see Set-IRMConfiguration.

Use the Shell to disable transport decryption

This example disables transport decryption for the Exchange 2013 organization.

Set-IRMConfiguration -TransportDecryptionSetting Disabled

For detailed syntax and parameter information, see Set-IRMConfiguration.

How do I know this worked?

To verify that you have enabled or disabled transport decryption, use the Get-IRMConfiguration cmdlet and
check the value of the JournalDecryptionEnabled property.
For an example of how to check the IRM configuration, see Examples in Get-IRMConfiguration.
 Configure IRM for Exchange Search and In-Place
eDiscovery
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can configure Information Rights Management (IRM ) so that Exchange
Search can index IRM -protected messages.
When members of the Discovery Management role group perform an In-Place eDiscovery search, IRM -protected
messages are returned in the search results and copied to the Discovery mailbox specified in the search.
Furthermore, members of the Discovery Management role group can use Outlook Web App to access the IRM -
protected messages that were copied to the Discovery mailbox as a result of the discovery search.

NOTE
Members of the Discovery Management role group can't access IRM-protected messages exported from a Discovery mailbox
to another mailbox or to a .pst file. IRM-protected messages in a Discovery mailbox can be accessed only by using Outlook
Web App.

For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to completion: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Rights protection" entry in the Messaging policy and compliance
permissions topic.
IRM must be configured in your Exchange 2013 organization. To learn more, see Enable or Disable IRM for
Internal Messages.
The Federation mailbox must be added to the Active Directory Rights Management Services (AD RMS )
super users group. To learn more, see Add the Federation Mailbox to the AD RMS Super Users Group.
You can't use the Exchange admin center (EAC ) to configure IRM for Exchange Search and In-Place
eDiscovery. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure IRM for Exchange Search

This example configures IRM to allow Exchange Search to index IRM -protected messages.
 NOTE
By default, the SearchEnabled parameter is set to $true . To disable indexing of IRM-protected messages, set it to $false .
Disabling indexing of IRM-protected messages prevents them from being returned in search results when users search their
mailbox or when discovery managers use In-Place eDiscovery.

Set-IRMConfiguration -SearchEnabled $true

For detailed syntax and parameter information, see Set-IRMConfiguration.

Use the Shell to configure IRM for In-Place eDiscovery

This example enables members of the Discovery Management role group to access IRM -protected messages that
reside in the Discovery mailbox.

NOTE
By default, the EDiscoverySuperUserEnabled parameter is set to $true . To disable access to IRM-protected messages for
members of the Discovery Management role group, set it to $false .

Set-IRMConfiguration -EDiscoverySuperUserEnabled $true

For detailed syntax and parameter information, see Set-IRMConfiguration.

How do you know this worked?

To verify that you have successfully configured IRM for Exchange Search and In-Place eDiscovery, use the Get-
IRMConfigurtaion cmdlet to retrieve the IRM configuration information. For an example of how to retrieve the
IRM configuration, see Examples in Get-IRMConfiguration.
 Enable or Disable Journal Report Decryption
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Enabling journal report decryption allows the Journaling agent to attach a decrypted copy of a rights-protected
message to the journal report. Before you enable journal report decryption, you must add the Federated Delivery
mailbox to the super users group configured on your Active Directory Rights Management Services (AD RMS )
server.
For additional management tasks related to Information Rights Management (IRM ), see Information Rights
Management procedures.

What do you need to know before you begin?

Estimated time to complete: 1 minute
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Rights protection" entry in the Messaging policy and compliance
permissions topic.
Members of the super users group are granted an owner use license when they request a license from the
AD RMS cluster. This allows them to decrypt all RMS -protected content created by that AD RMS cluster.
An AD RMS cluster must be installed in the Active Directory forest.
The Federated Delivery mailbox has been added to an AD RMS super users group. For details, see Add the
Federation Mailbox to the AD RMS Super Users Group.
You can't use the Exchange admin center (EAC ) to enable journal report decryption. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable journal report decryption

This example enables journal report decryption for the Exchange organization.

Set-IRMConfiguration -JournalReportDecryptionEnabled $true

For detailed syntax and parameter information, see Set-IRMConfiguration.

Use the Shell to disable journal report decryption

This example disables journal report decryption for the Exchange organization.

Set-IRMConfiguration -JournalReportDecryptionEnabled $false

For detailed syntax and parameter information, see Set-IRMConfiguration.

How do you know this worked?

To verify that you have enabled or disabled journal report decryption, run the Get-IRMConfiguration cmdlet and
check the value of the JournalDecryptionEnabled property.
For an example of how to check the IRM configuration, see Examples in Get-IRMConfiguration.
 Enable or Disable Information Rights Management
on Client Access Servers
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Enabling Information Rights Management (IRM ) on Client Access servers enables the following features:
Microsoft Office Outlook Web App
IRM in Microsoft Exchange ActiveSync
When IRM is enabled on Client Access servers, Outlook Web App users can IRM -protect messages by applying
an Active Directory Rights Management Services (AD RMS ) template created on your AD RMS cluster. Outlook
Web App users can also view IRM -protected messages and supported attachments. Before you enable IRM on
Client Access servers, you must add the Federation mailbox to the super users group on the AD RMS cluster.

IMPORTANT
Members of the super users group are granted an owner use license when they request a license from the AD RMS cluster.
This allows them to decrypt all RMS-protected content by that cluster.

For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to completion: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Information Rights Management (IRM ) configuration" entry in the
Messaging policy and compliance permissions topic.
An AD RMS cluster must be installed in the Active Directory forest.
The Federation mailbox has been added to the AD RMS super users group. For detailed instructions, see
Add the Federation Mailbox to the AD RMS Super Users Group.
IRM features must be enabled for the organization. For detailed instructions, see Enable or Disable IRM for
Internal Messages.
You can use the Set-IRMConfiguration cmdlet to enable or disable IRM in Outlook Web App and IRM in
Exchange ActiveSync for the entire Exchange organization or at specific levels.
You can control IRM in Outlook Web App at the following levels:
Per-Outlook Web App virtual directory: To enable or disable IRM in Outlook Web App for an
Outlook Web App virtual directory, use the Set-OWAVirtualDirectory cmdlet and set the
IRMEnabled parameter to $false or $true (default). This allows you to disable IRM in Outlook
Web App for one virtual directory on an Exchange 2013 Client Access server, while keeping it
enabled on another virtual directory on a different Client Access server.
Per-Outlook Web App mailbox policy: To enable or disable IRM in Outlook Web App for an
Outlook Web App mailbox policy, use the Set-OWAMailboxPolicy cmdlet and set the IRMEnabled
 parameter to $false or $true (default). This allows you to enable IRM in Outlook Web App for
one set of users and disable it for another set of users by assigning them a different Outlook Web
App mailbox policy.
You can control IRM in Exchange ActiveSync per Exchange ActiveSync mailbox policy. To disable or
enable IRM in Exchange ActiveSync for an Exchange ActiveSync mailbox policy, use the Set-
ActiveSyncMailboxPolicy cmdlet and set the IRMEnabled parameter to $false or $true
(default). This allows you to enable IRM in Exchange ActiveSync for one set of users and disable it
for another set of users by assigning them a different Exchange ActiveSync mailbox policy.
You can't use the Exchange admin center (EAC ) to enable or disable IRM on Client Access servers. You
must use the Shell.

Use the Shell to enable IRM on Client Access servers

This example enables IRM on a Client Access server for an Exchange organization.

Set-IRMConfiguration -ClientAccessServerEnabled $true

For detailed syntax and parameter information, see Set-IRMConfiguration.

Use the Shell to disable IRM on Client Access servers

This example disables IRM on a Client Access server for an Exchange organization.

Set-IRMConfiguration -ClientAccessServerEnabled $false

For detailed syntax and parameter information, see Set-IRMConfiguration.

How do you know this worked?

To verify that you have successfully enabled or disabled IRM on Client Access servers, do the following:
Run the Get-IRMConfiguration cmdlet and check the value of the ClientAccessServerEnabled property.
For an example of how to retrieve the IRM configuration, see Examples in Get-IRMConfiguration.
Use Outlook Web App to create or read an IRM -protected message.
 Enable or Disable Information Rights Management
Logging
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Exchange Server 2013, you can use Information Rights Management (IRM ) logs to monitor and troubleshoot
IRM operations. IRM logging is enabled by default.
IRM logs use the following common set of parameters:
IrmLogEnabled: Enables or disables IRM logging. Default: $true .
IrmLogMaxAge: Specifies the maximum age of IRM log files. Files older than the specified age are deleted.
Default: 30 days.
IrmLogMaxDirectorySize: Specifies the maximum size of the directory that contains IRM logs. When a
directory reaches its maximum file size, the server deletes the oldest log files first. Default: 250 MB.
IrmLogMaxFileSize: Specifies the maximum size of each IRM log file. When a log file reaches the specified
size, a new log file is created. Default: 10 MB.
IrmLogPath: Specifies the location of the IRM log directory. Default: %ExchangeInstallPath%Logging\IRMLogs .
For additional management tasks related to IRM, see Information Rights Management procedures.

What do you need to know before you begin?

Estimated time to complete each procedure: 2-5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Configure IRM logging" entry in the Messaging policy and compliance
permissions topic.
You can't use the Exchange admin center (EAC ) to enable or disable IRM logging on a server. You must use
the Shell
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable IRM logging on a server

This example enables IRM log on a Mailbox server.

Set-TransportService -Identity EXCH01 -IRMLogEnabled $true

For detailed syntax and parameter information, see Set-TransportService.

Use the Shell to disable IRM logging on a server
This example disables IRM logging on a Mailbox server.

Set-TransportService -Identity EXCH01 -IRMLogEnabled $false

For detailed syntax and parameter information, see Set-TransportService.

How do you know this worked?

To verify that you have successfully enabled or disbled IRM logging on a server, run the Get-TransportService
cmdlet to retrieve IRM settings.
This example retrieves all IRM logging properties on the server EXCH01.

Get-TransportService -Identity EXCH01 | Format-List IRMLog*

 S/MIME for message signing and encryption in
Exchange Server
5/21/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a widely accepted method (or more precisely, a
protocol) for sending digitally signed and encrypted messages. S/MIME allows you to encrypt emails and digitally
sign them. When you use S/MIME with an email message, it helps the people who receive that message to be
certain that what they see in their inbox is the exact message that started with the sender. It will also help people
who receive messages to be certain that the message came from the specific sender and not from someone
pretending to be the sender. To do this, S/MIME provides for cryptographic security services such as
authentication, message integrity, and non-repudiation of origin (using digital signatures). It also helps enhance
privacy and data security (using encryption) for electronic messaging. For a more complete background about the
history and architecture of S/MIME in the context of email, see Understanding S/MIME.
As an Exchange administrator, you can enable S/MIME -based security for the mailboxes in your organization. Use
the guidance in the topics linked here along with the Exchange Management Shell to set up S/MIME. To use
S/MIME in supported email clients, the users in your organization must have certificates issued for signing and
encryption purposes and data published to your on-premises Active Directory Domain Service (AD DS ). Your AD
DS must be located on computers at a physical location that you control and not at a remote facility or cloud-
based service somewhere on the internet. For more information about AD DS, see Active Directory Domain
Services.

Supported scenarios and technical considerations

You can set up S/MIME to work with any of the following end points:
Outlook 2010 or later
Outlook Web App (OWA)
Exchange ActiveSync (EAS )
The steps that you follow to set up S/MIME with each of these end points is slightly different. Generally, you will
need to do the following steps:
Install a Windows-based Certification Authority and set up a public key infrastructure to issue S/MIME
certificates. Certificates issued by third-party certificate providers are also supported. For details, see Active
Directory Certificate Services Overview.
Publish the user certificate in an on-premises AD DS account in the UserSMIMECertificate and/or
UserCertificate attributes.
Set up a virtual certificate collection in order to validate S/MIME. This information is used by OWA when
validating the signature of an email and ensuring that it was signed by a trusted certificate.
Set up the Outlook or EAS end point to use S/MIME.

Setup S/MIME with Outlook Web App

Setting up S/MIME with OWA involves the following key steps:
1. Configure S/MIME settings in Exchange Server for Outlook Web App
2. Set up a virtual certificate collection in Exchange Server to validate S/MIME

Related message encryption technologies

As message security becomes more important, admins need to understand the principles and concepts of secure
messaging. This understanding is especially important because of the growing variety of protection-related
technologies (including S/MIME ) that are available. To understand more about S/MIME and how it works in
context of email, see Understanding S/MIME. A variety of encryption technologies work together to provide
protection for messages at rest and in-transit. S/MIME can work simultaneously with the following technologies
but is not dependent on them:
Transport Layer Security (TLS ) encrypts the tunnel or the route between email servers in order to help
prevent snooping and eavesdropping.
Secure Sockets Layer (SSL ) encrypts the connection between email clients and Office 365 servers.
BitLocker encrypts the data on a hard drive in a datacenter so that if someone gets unauthorized access,
they can't read it.
S/MIME compared with Office 365 Message Encryption
S/MIME requires a certificate and publishing infrastructure that is often used in business-to-business and
business-to-consumer situations. The user controls the cryptographic keys in S/MIME and can choose whether to
use them for each message they send. Email programs such as Outlook search a trusted root certificate authority
location to perform digital signing and verification of the signature. Office 365 Message Encryption is a policy-
based encryption service that can be configured by an administrator, and not an individual user, to encrypt mail
sent to anyone inside or outside of the organization. It's an online service that's built on Azure Rights Management
(RMS ) and does not rely on a public key infrastructure. Office 365 Message Encryption also provides additional
capabilities, such as the capability to customize the mail with organization's brand. For more information about
Office 365 Message Encryption, see Encryption in Office 365.

More information
Outlook Web App
Secure Mail (2000)
 Configure S/MIME settings in Exchange Server for
Outlook on the web
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

As an administrator for Exchange Server, you can set up Outlook on the web (formerly known as Outlook Web
App) to allow sending and receiving S/MIME -protected messages. Use the Get-SmimeConfig and Set-
SmimeConfig cmdlets to view and manage this feature in the Exchange Management Shell. To open the
Exchange Management Shell, see Open the Exchange Management Shell.
For detailed syntax and parameter information, see Get-SmimeConfig and Set-SmimeConfig.

Considerations for Chrome

To use S/MIME in Outlook on the web in the Google Chrome web browser, you (or another administrator) must
set up and configure the Chromium policy named ExtensionInstallForcelist to install the Microsoft S/MIME
extension in Chrome. The policy value is: maafgiompdekodanheihhgilkjchcakm;https://<OWAUrl>/SmimeCrxUpdate.ashx
where <OWAUrl> is your URL value. For example:
maafgiompdekodanheihhgilkjchcakm;https://mail.contoso.com/owa/SmimeCrxUpdate.ashx . And note that applying this
policy requires domain-joined computers, so using S/MIME in Chrome effectively requires domain-joined
computers.
For details about the ExtensionInstallForcelist policy, see ExtensionInstallForcelist.
This step is a prerequisite for using Chrome; it does not replace the S/MIME control that's installed by users. Users
are prompted to download and install the S/MIME control in Outlook on the web during their first use of S/MIME.
Or, users can proactively go to S/MIME in their Outlook on the web settings to get the download link for the
control.

For more information

S/MIME for message signing and encryption
 Set up a virtual certificate collection in Exchange
Server to validate S/MIME
5/21/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

As an Exchange Server administrator, you need to configure a virtual certificate collection in Exchange that will be
used to validate S/MIME certificates. This virtual certificate collection is set up as a certificate store with an SST
filename extension. The SST file contains all the root and intermediate certificates that are used when validating an
S/MIME certificate.

Create and save an SST

You can create this SST certificate store file by exporting the certificates from a trusted machine using the Export-
Certificate cmdlet in Windows PowerShell and specifying the Type value as SST. For instructions, see Export-
Certificate.
Once you have the SST certificate store file, use the following syntax in the Exchange Management Shell to save
the SST file contents in the Exchange Online virtual certificate store. To open the Exchange Management Shell, see
Open the Exchange Management Shell.

Set-SmimeConfig -SMIMECertificateIssuingCA (Get-Content <FileNameAndPath>.sst -Encoding Byte)

This example imports the SST file C:\My Documents\Exported Certificate Store.sst.

Set-SmimeConfig -SMIMECertificateIssuingCA (Get-Content "C:\My Documents\Exported Certificate Store.sst" -

Encoding Byte)

For detailed syntax and parameter information, see Set-SmimeConfig.

Validating certificates
Exchange 2013 SP1 or later first checks for the SST file and validates the certificate. If the validation fails, it will
look at the local machine certificate store to validate the certificate. This behavior is different from previous
versions of Exchange.

More Information
S/MIME for message signing and encryption
Get-SmimeConfig
 Send and receive S/MIME signed and encrypted
email in Exchange Online
5/21/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sending or replying to an S/MIME -encrypted message in Microsoft Outlook is very similar to the experience with
a non-encrypted message. For more information about reading or sending S/MIME -encrypted messages from an
email program such as Outlook Web App, see Use Outlook to send and reply to S/MIME encrypted messages.

For more information

S/MIME for message signing and encryption
 Mailbox audit logging
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Because mailboxes can contain sensitive, high business impact (HBI) information and personally identifiable
information (PII), it's important that you track who logs on to the mailboxes in your organization and what actions
are taken. It's especially important to track access to mailboxes by users other than the mailbox owner. These users
are referred to as delegate users.
By using mailbox audit logging, you can log mailbox access by mailbox owners, delegates (including
administrators with full access permissions to mailboxes), and administrators.
When you enable audit logging for a mailbox, you can specify which user actions (for example, accessing, moving,
or deleting a message) will be logged for a logon type (administrator, delegate user, or owner). Audit log entries
also include important information such as the client IP address, host name, and process or client used to access
the mailbox. For items that are moved, the entry includes the name of the destination folder.

Mailbox audit logs

Mailbox audit logs are generated for each mailbox that has mailbox audit logging enabled. Log entries are stored
in the Recoverable Items folder in the audited mailbox, in the Audits subfolder. This ensures that all audit log
entries are available from a single location, regardless of which client access method was used to access the
mailbox or which server or workstation an administrator used to access the mailbox audit log. If you move a
mailbox to another Mailbox server, the mailbox audit logs for that mailbox are also moved because they're located
in the mailbox.
By default, mailbox audit log entries are retained in the mailbox for 90 days and then deleted. You can modify this
retention period by using the AuditLogAgeLimit parameter with the Set-Mailbox cmdlet. If a mailbox is on In-
Place Hold or Litigation Hold, audit log entries are only retained until the audit log retention period for the mailbox
is reached. To retain audit log entries longer, you have to increase the retention period by changing the value for
the AuditLogAgeLimit parameter. You can also export audit log entries before the retention period is reached. For
more information, see:
Export mailbox audit logs
Create a mailbox audit log search

Enabling mailbox audit logging

Mailbox audit logging is enabled per mailbox. Use the Set-Mailbox cmdlet to enable or disable mailbox audit
logging. For details, see Enable or disable mailbox audit logging for a mailbox.
When you enable mailbox audit logging for a mailbox, access to the mailbox and certain administrator and
delegate actions are logged by default. To log actions taken by the mailbox owner, you must specify which owner
actions should be audited.

Mailbox actions logged by mailbox audit logging

The following table lists the actions logged by mailbox audit logging, including the logon types for which the
action can be logged.
ACTION DESCRIPTION ADMINISTRATOR DELEGATE OWNER

Copy An item is copied Yes No No

to another folder.

Create An item is created Yes* Yes* Yes

in the Calendar,
Contacts, Notes,
or Tasks folder in
the mailbox; for
example, a new
meeting request
is created. Note
that message or
folder creation
isn't audited.

FolderBind A mailbox folder Yes* Yes** No

is accessed.

HardDelete An item is deleted Yes* Yes* Yes

permanently from
the Recoverable
Items folder.

MessageBind An item is Yes No No

accessed in the
reading pane or
opened.

Move An item is moved Yes* Yes Yes

to another folder.

MoveToDeletedIt An item is moved Yes* Yes Yes

ems to the Deleted
Items folder.

SendAs A message is sent Yes* Yes* Not applicable

using Send As
permissions.

SendOnBehalf A message is sent Yes* Yes Not applicable

using Send on
Behalf
permissions.

SoftDelete An item is deleted Yes* Yes* Yes

from the Deleted
Items folder.
 ACTION DESCRIPTION ADMINISTRATOR DELEGATE OWNER

Update An item's Yes* Yes* Yes

properties are
updated.

* Audited by default if auditing is enabled for a mailbox.

** Entries for folder bind actions performed by delegates are consolidated. One log entry is generated for
individual folder access within a time span of 24 hours.
If you no longer require certain types of mailbox actions to be audited, you should modify the mailbox's audit
logging configuration to disable those actions. Existing log entries aren't purged until the age limit for audit log
entries is reached.

Searching mailbox audit log entries

You can use the following methods to search mailbox audit log entries:
Synchronously search a single mailbox: You can use the Search-MailboxAuditLog cmdlet to
synchronously search mailbox audit log entries for a single mailbox. The cmdlet displays search results in
the Exchange Management Shell window. For details, see Search the mailbox audit log for a mailbox.
Asynchronously search one or more mailboxes: You can create a mailbox audit log search to
asynchronously search mailbox audit logs for one or more mailboxes, and then have the search results sent
to a specified email address. The search results are sent as an XML attachment. To create the search, use the
New -MailboxAuditLogSearch cmdlet. For details, see Create a mailbox audit log search.
Use auditing reports in the Exchange admin center (EAC ): You can use the Auditing tab in the EAC to
run a non-owner mailbox access report or export entries from the mailbox audit log. For details, see:
Run a non-owner mailbox access report
Export mailbox audit logs

Mailbox audit log entries

The following table describes the fields logged in a mailbox audit log entry.

FIELD POPULATED WITH

FIELD POPULATED WITH

Operation One of the following actions:

Copy
Create
FolderBind
HardDelete
MessageBind
Move
MoveToDeletedItems
SendAs
SendOnBehalf
SoftDelete
Update

OperationResult One of the following results:

Failed
PartiallySucceeded
Succeeded

LogonType Logon type of the user who performed the operation.

Logon types include:
Owner
Delegate
Admin

DestFolderId Destination folder GUID for move operations.

DestFolderPathName Destination folder path for move operations.

FolderId Folder GUID.

FolderPathName Folder path.

ClientInfoString Details that identify which client or Exchange component

performed the operation.

ClientIPAddress Client computer IP address.

ClientMachineName Client computer name.

FIELD POPULATED WITH

ClientProcessName Name of the client application process.

ClientVersion Client application version.

InternalLogonType Logon type of the user who performed the operation.

Logon types include:
Owner
Delegate
Admin

MailboxOwnerUPN Mailbox owner user principal name (UPN).

MailboxOwnerSid Mailbox owner security identifier (SID).

DestMailboxOwnerUPN Destination mailbox owner UPN, logged for cross-mailbox

operations.

DestMailboxOwnerSid Destination mailbox owner SID, logged for cross-mailbox

operations.

DestMailboxOwnerGuid Destination mailbox owner GUID.

CrossMailboxOperation Information about whether the operation logged is a

cross-mailbox operation (for example, copying or moving
messages between mailboxes).

LogonUserDisplayName Display name of user who is logged on.

DelegateUserDisplayName Delegate user display name.

LogonUserSid SID of user who is logged on.

SourceItems ItemID of mailbox items on which the logged action is

performed (for example, move or delete). For operations
performed on a number of items, this field is returned as a
collection of items.

SourceFolders Source folder GUID.

ItemId Item ID.

 FIELD POPULATED WITH

ItemSubject Item subject.

MailboxGuid Mailbox GUID.

MailboxResolvedOwnerName Mailbox user resolved name in the format

DOMAIN\SamAccountName.

LastAccessed Time when the operation was performed.

Identity Audit log entry ID.

More information
Administrator access to mailboxes: Mailboxes are considered to be accessed by an administrator only in
the following scenarios:
In-Place eDiscovery is used to search a mailbox.
The New -MailboxExportRequest cmdlet is used to export a mailbox.
Microsoft Exchange Server MAPI Editor is used to access the mailbox.
Bypassing mailbox auditing logging: Mailbox access by authorized automated processes such as
accounts used by third-party tools or accounts used for lawful monitoring can create a large number of
mailbox audit log entries and may not be of interest to your organization. You can configure such accounts
to bypass mailbox audit logging. For details, see Bypass a user account from mailbox audit logging.
Logging mailbox owner actions: For mailboxes such as the Discovery Search Mailbox, which may
contain more sensitive information, consider enabling mailbox audit logging for mailbox owner actions
such as message deletion.
 Mailbox audit logging procedures
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Enable or disable mailbox audit logging for a mailbox
Bypass a user account from mailbox audit logging
Search the mailbox audit log for a mailbox
Create a mailbox audit log search
 Enable or disable mailbox audit logging for a mailbox
6/10/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

With mailbox audit logging, you can track logons to a mailbox as well as what actions are taken while the user is
logged on. When you enable mailbox audit logging for a mailbox, some actions performed by administrators and
delegates are logged by default. None of the actions performed by the mailbox owner are logged. To learn more
about mailbox audit logging, see Mailbox audit logging.

WARNING
Auditing of mailbox owner actions can generate a large number of mailbox audit log entries and is therefore disabled by
default. We recommend that you only enable auditing of specific owner actions needed to meet business or security
requirements.

For additional tasks related to mailbox audit logging, see Mailbox audit logging procedures.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox audit logging" entry in the Messaging policy and compliance
permissions topic.
You can't use the Exchange admin center (EAC ) to enable or disable mailbox audit logging. You must use
the Shell.
An administrator who has been assigned the Full Access permission to a user's mailbox is considered a
delegate user.
Mailboxes are considered to be accessed by an administrator only in the following scenarios:
In-Place eDiscovery is used to search a mailbox.
The New-MailboxExportRequest cmdlet is used to export a mailbox.
Microsoft Exchange Server MAPI Editor is used to access the mailbox.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable mailbox audit logging

You can use the Shell to enable or disable mailbox audit logging for a mailbox. This enables or disables logging of
all operations specified for administrator, delegates, and the mailbox owner.
This example enables mailbox audit logging for Ben Smith's mailbox.
 Set-Mailbox -Identity "Ben Smith" -AuditEnabled $true

This example disables mailbox audit logging for Ben Smith's mailbox.

Set-Mailbox -Identity "Ben Smith" -AuditEnabled $false

For detailed syntax and parameter information, see Set-Mailbox.

Use the Shell to configure mailbox audit logging settings for

administrator, delegate, and owner access
When mailbox audit logging is enabled for a mailbox, only the administrator, delegate, and owner actions specified
in the audit logging configuration for the mailbox are logged.
This example specifies that the SendAs or SendOnBehalf actions performed by delegate users will be logged for
Ben Smith's mailbox.

Set-Mailbox -Identity "Ben Smith" -AuditDelegate SendAs,SendOnBehalf -AuditEnabled $true

This example specifies that the MessageBind and FolderBind actions performed by administrators will be logged
for Ben Smith's mailbox.

Set-Mailbox -Identity "Ben Smith" -AuditAdmin MessageBind,FolderBind -AuditEnabled $true

This example specifies that the HardDelete action performed by the mailbox owner will be logged for Ben Smith's
mailbox.

Set-Mailbox -Identity "Ben Smith" -AuditOwner HardDelete -AuditEnabled $true

For detailed syntax and parameter information, see Set-Mailbox.

How do you know this worked?

To verify that you have successfully enabled mailbox audit logging for a mailbox and specified the correct logging
settings for administrator, delegate, or owner access, use the Get-Mailbox cmdlet to retrieve the mailbox audit
logging settings for that mailbox.
This example retrieves Ben Smith's mailbox settings and pipes the specified audit settings, including the audit log
age limit, to the Format-List cmdlet.

Get-Mailbox "Ben Smith" | Format-List *audit*

 Bypass a user account from mailbox audit logging
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

When you enable mailbox audit logging for a mailbox, specified mailbox access events (for example, accessing a
folder or a message, or permanently deleting a message) are logged. However, access by some authorized
accounts, such as accounts used by third-party tools or accounts used for lawful monitoring, can create a large
number of mailbox audit log entries and may not be of interest to your organization.
You can configure a user or computer account to bypass mailbox audit logging, so actions taken by that user or
account for any mailbox aren't logged. By bypassing trusted user or computer accounts that need frequent access
to mailboxes, you can reduce the noise in mailbox audit logs.

WARNING
If you use mailbox audit logging to audit mailbox access and actions, you must monitor mailbox audit bypass associations at
regular intervals. If a mailbox audit bypass association is added for an account, the account can access any mailbox in the
organization to which it has been assigned permissions, without any mailbox audit logging entries being generated for such
access or any actions taken (such as message deletions).

For additional management tasks related to mailbox audit logging, see Mailbox audit logging procedures.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox audit logging" entry in the Messaging policy and compliance
permissions topic.
When an account is configured to bypass mailbox audit logging, access to any mailbox by that account
won't be logged. You can't configure an account to bypass the logging of access to a specific mailbox.
You can't use the Exchange admin center (EAC ) to enable or disable mailbox audit logging bypass for an
account. You must use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable mailbox audit logging bypass for an
account
For an example of how to enable mailbox audit logging bypass for an account, see Example 1 in Set-
MailboxAuditBypassAssociation.
For an example of how to disable mailbox audit logging bypass for an account, see Example 2 in Set-
MailboxAuditBypassAssociation.

How do you know this worked?

After you have bypassed a user account from mailbox audit logging, you can check the bypass settings by running
the Get-MailboxAuditBypassAssociation cmdlet.
For examples of how to check mailbox audit bypass associations, see Examples in Get-
MailboxAuditBypassAssociation.
 Search the mailbox audit log for a mailbox
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can synchronously search mailbox audit log entries for a mailbox and have the search results displayed in the
Shell.
If you want to search mailbox audit logs for multiple mailboxes and have the results emailed to a specified
address, you must create a mailbox audit log search instead. For details, see Create a mailbox audit log search.
For additional management tasks related to mailbox audit logging, see Mailbox audit logging procedures.

What do you need to know before you begin?

Estimated time to complete: 1 minute.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox audit logging" entry in the Messaging policy and compliance
permissions topic.
By default, mailbox audit logging is disabled for all mailboxes. For each mailbox you want to audit, you
must enable audit logging and specify the mailbox owner, delegate, or administrator actions you want to
audit. For details, see Enable or disable mailbox audit logging for a mailbox.
You can't use the EAC to search the mailbox audit log for a mailbox. However, you can use the EAC to run
or search for and export a non-owner mailbox access report.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to search the mailbox audit log for a mailbox
For examples of how to use the Shell to search the mailbox audit log for a mailbox, see Examples in Search-
MailboxAuditLog.
 Create a mailbox audit log search
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can create a mailbox audit log search to asynchronously search one or more mailboxes and have the search
results sent by email as an XML file to specified addresses.
To search mailbox audit logs for a single mailbox and have the results displayed in the Shell, see Search the
mailbox audit log for a mailbox.
For additional management tasks related to mailbox audit logging, see Mailbox audit logging procedures.

What do you need to know before you begin?

Estimated time to complete: 2 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox audit logging" entry in the Messaging policy and compliance
permissions topic.
By default, mailbox audit logging is disabled for all mailboxes. For each mailbox you want to audit, you
must enable audit logging and specify the mailbox owner, delegate, or administrator actions you want to
audit. For more details, see Enable or disable mailbox audit logging for a mailbox.
You can't use the EAC to search mailbox audit logs for owner access. The auditing section in EAC includes
reports for non-owner mailbox access and also allows you to search for and export non-owner access
events.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create a mailbox audit log search

1. Navigate to Compliance management > Auditing.
2. In the list view, select Export mailbox audit logs.
3. In Export Mailbox Audit Logs, complete the following fields, and then click Export:
Start date
End date
Search these mailboxes or leave blank to find all mailboxes accessed by non-owners
 WARNING
Depending on the number of mailboxes in your organization and the amount of mailbox audit log data in
each mailbox, searching all mailboxes may take a long time.

Search for access by

Select from the following types of access events you want to search:
All non-owners
External users
Administrators and delegated users
Administrators
Send the auditing report to

Use the Shell to create a mailbox audit log search

For an example of how to use the Shell to create a mailbox audit log search, see Example 1 in New-
MailboxAuditLogSearch.
 Administrator audit logging
6/11/2019 • 13 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use administrator audit logging in Microsoft Exchange Server 2013 to log when a user or administrator
makes a change in your organization. By keeping a log of the changes, you can trace changes to the person who
made the change, augment your change logs with detailed records of the change as it was implemented, comply
with regulatory requirements and requests for discovery, and more.
By default, audit logging is enabled in new installations of Exchange 2013.

What gets audited

Cmdlets that are run directly in the Exchange Management Shell are audited. In addition, operations performed
using the Exchange admin center (EAC ) are also logged because those operations run cmdlets in the background.
Cmdlets, regardless of where they're run, are audited if a cmdlet is on the cmdlet auditing list and one or more
parameters on that cmdlet are on the parameter auditing list. Audit logging is intended to show what actions have
been taken to modify objects in an Exchange organization rather than what objects have been viewed.

IMPORTANT
A cmdlet might not be logged if an error occurs before the cmdlet calls the Admin Audit Log cmdlet extension agent. If an
error occurs after the Admin Audit Log agent is called, the cmdlet is logged along with the associated error. For more
information, see the Admin Audit Log Agent section later in this topic.
Changes made using Microsoft Exchange Server 2010 management tools are logged; however, changes using Microsoft
Exchange Server 2007 management tools aren't logged.
Changes to the audit log configuration are refreshed every 60 minutes on computers that have the Shell open at the time a
configuration change is made. If you want to apply the changes immediately, close and then open the Shell again on each
computer.
A command may take up to 15 minutes after it's run to appear in audit log search results. This is because audit log entries
must be indexed before they can be searched. If a command doesn't appear in the administrator audit log, wait a few
minutes and run the search again.

Audit logging configuration

By default, if audit logging is enabled, a log entry is created every time any cmdlet is run. If you don't want to audit
every cmdlet that's run, you can configure audit logging to audit only the cmdlets and parameters you're interested
in. You configure audit logging with the Set-AdminAuditLogConfig cmdlet. The parameters referenced in the
following sections are used with this cmdlet.

IMPORTANT
Changes to the administrator audit log configuration are always logged, regardless of whether the Set-
AdministratorAuditLog cmdlet is included in the list of cmdlets being audited and whether audit logging is enabled or
disabled.

When a command is run, Exchange inspects the cmdlet that was used. If the cmdlet that was run matches any of
the cmdlets provided with the AdminAuditLogConfigCmdlets parameter, Exchange then checks the parameters
specified in the AdminAuditLogConfigParameters parameter. If at least one or more parameters from the
parameters list are matched, Exchange logs the cmdlet that was run in the mailbox specified using the
AdminAuditLogMailbox parameter. The following sections contain more information about each aspect of the
audit logging configuration.
For more information about managing audit logging configuration, see Manage administrator audit logging.

Cmdlets
You can control which cmdlets are audited by providing a list of cmdlets, and their parameters, that you want to
log. When you configure audit logging, you can specify to audit every cmdlet, or you can specify the cmdlets you
want to audit by using the AdminAuditLogConfigCmdlets parameter. You can specify full cmdlet names, such as
New-Mailbox, or you can specify partial cmdlet names and enclose those names in wildcard characters, such as
an asterisk ( * ). For example, if you want to log when any cmdlet that contains the string Transport runs, you can
specify a value of *Transport* . You can use a mix of full cmdlet names and partial cmdlet names at the same time
to tailor the audit logging configuration to your needs.

Parameters
In addition to specifying which cmdlets you want to log, you can also indicate that cmdlets should only be logged if
certain parameters on those cmdlets are used. Use the AdminAuditLogConfigParameters parameter to specify
which parameters should be logged. As with cmdlets, you can specify full parameter names, such as Database , or
partial parameter names enclosed in wildcard characters ( * ), such as *Address* , or a combination of both.

Audit log age limit

By default, audit logging is configured to store audit log entries for 90 days. After 90 days, the audit log entry is
deleted. You can change the audit log age limit using the AdminAuditLogAgeLimit parameter. You can specify the
number of days, hours, minutes, and seconds that audit log entries should be kept. To specify a value, use the
format dd.hh:mm:ss where the following applies:
dd: The number of days to keep the audit log entry.
hh: The number of hours to keep the audit log entry.
mm: The number of minutes to keep the audit log entry.
ss: The number of seconds to keep the audit log entry.
You must specify multiple years using the dd field. For example, 365 days equals one year; 730 days equals two
years; 913 days equals two years and six months. For example, to set the audit log age limit to two years and six
months, use the syntax 913.00:00:00 .

WARNING
You can set the audit log age limit to a value that's less than the current age limit. If you do this, any audit log entry whose
age exceeds the new age limit is deleted.
If you set the age limit to 0, Exchange deletes all the entries in the audit log.
We recommend that you grant permissions to configure the audit log age limit only to highly trusted users.

Verbose logging
By default, the administrator audit log records only the cmdlet name, cmdlet parameters (and values specified), the
object that was modified, who ran the cmdlet, when the cmdlet was run, and on what server the cmdlet was run.
The administrator audit log doesn't log what properties were modified on the object. If you want the audit log to
also include the properties of the object that were modified, you can enable verbose logging by setting the
LogLevel parameter to Verbose . When you enable verbose logging, in addition to the information logged by
default, the properties modified on an object, including their old and new values, are included in the audit log.

Test cmdlets
Cmdlets that begin with the verb Test aren't logged by default. You can indicate that Test cmdlets should be
logged by setting the TestCmdletLoggingEnabled parameter to $true . Although you can enable logging of test
cmdlets, we recommend that you do this only for short periods of time because test cmdlets can produce a large
amount of information.

Audit logs
Each time a cmdlet is logged, an audit log entry is created. Audit logs are stored in a hidden, dedicated arbitration
mailbox that can only be accessed using the EAC or the Search-AdminAuditLog or New-
AdminAuditLogSearch cmdlet. It can't be opened using Microsoft Outlook Web App or Microsoft Outlook. The
following sections provide information about the following:
What's included in the logs
Reports available on the EAC auditing page
Audit log search cmdlets

Audit log contents

Each audit log entry contains the information described in the following table. The audit log contains one or more
audit log entries. The number of audit log entries is controlled by the audit log age limit specified using the Set-
AdminAuditLogConfig cmdlet. Any audit log entry that exceeds the age limit is deleted.
Audit log entry fields
FIELD DESCRIPTION

RunspaceId This field is used internally by Exchange.

ObjectModified This field contains the object that was modified by the
cmdlet specified in the CmdletName field.

CmdletName This field contains the name of the cmdlet that was run by
the user in the Caller field.

CmdletParameters This field contains the parameters that were specified

when the cmdlet in the CmdletName field was run. Also
stored in this field, but not visible in the default output, is
the value specified with the parameter, if any. For more
information about how to access the additional
information in this field, see Search the role group
changes or administrator audit logs.
 FIELD DESCRIPTION

ModifiedProperties This field contains the properties that were modified on

the object in the ObjectModified field. Also stored in
this field, but not visible in the default output, are the old
value of the property and the new value that was stored.
For more information about how to access the additional
information in this field, see Search the role group
changes or administrator audit logs.

IMPORTANT
This field is only populated if the LogLevel parameter on
the Set-AdminAuditLogConfig cmdlet is set to Verbose .

Caller This field contains the user account of the user who ran
the cmdlet in the CmdletName field.

Succeeded This field specifies whether the cmdlet in the CmdletName

field ran successfully. The value is either True or False .

Error This field contains the error message generated if the

cmdlet in the CmdletName field failed to complete
successfully.

RunDate This field contains the date and time when the cmdlet in
the CmdletName field was run. The date and time are
stored in Coordinated Universal Time (UTC) format.

OriginatingServer This field indicates the server on which the cmdlet

specified in the CmdletName field was run.

Identity This field is used internally by Exchange.

IsValid This field is used internally by Exchange.

ObjectState This field is used internally by Exchange.

EAC auditing reports

The auditing page in the EAC has several reports that provide information about various types of compliance and
administrative configuration changes. The following reports provide information about configuration changes in
your organization:
Administrator role group report: This report enables you to search for changes to management role
groups that you specify within a specified timeframe. The results that are returned include the role groups
that have been changed, who changed them and when, and what changes were made. A maximum of 3,000
entries can be returned. If your search might return more than 3,000 entries, use the Administrator audit
 log report or the Search-AdminAuditLog cmdlet.
Administrator audit log: This report enables you to export the audit log entries recorded within a
specified timeframe to a XML file and then send the file via email to a recipient you specify. For more
information about the contents of the XML file, see Administrator audit log structure.
For information about how to use these reports, see Search the role group changes or administrator audit logs.
For information about the other reports included on the auditing page see Exchange auditing reports.

Search-AdminAuditLog cmdlet
When you run the Search-AdminAuditLog cmdlet, all the audit log entries that match the search criteria you
specify are returned. You can specify the following search criteria:
Cmdlets: Specifies the cmdlets you want to search for in the administrator audit log.
Parameters: Specifies the parameters, separated by commas, you want to search for in the administrator
audit log. You can only search for parameters if you specify a cmdlet to search for.
End date: Scopes the administrator audit log results to log entries that occurred on or before the specified
date.
Start date: Scopes the administrator audit log results to log entries that occurred on or after the specified
date.
Object IDs: Specifies that only administrator audit log entries that contain the specified changed objects
should be returned
User IDs: Specifies that only the administrator audit log entries that contain the specified IDs of the user
who ran the cmdlet should be returned.
Successful completion: Specifies whether only administrator audit log entries that indicated a success or
failure should be returned.
Each audit log entry returned contains the information described in the table in Audit Log Contents. By default,
only the first 1,000 log entries that match the criteria you specify are returned. However, you can override this
default and return more or fewer entries using the ResultSize parameter. You can specify a value of Unlimited with
the ResultSize parameter to return all log entries that match the specified criteria.
For information about how to use the Search-AdminAuditLog cmdlet, see Search the role group changes or
administrator audit logs.

New-AdminAuditLogSearch cmdlet
The New-AdminAuditLogSearch cmdlet searches the audit log just like the Search-AdminAuditLog cmdlet.
However, instead of displaying the results of the audit log search in the Shell, the New-AdminAuditLogSearch
cmdlet performs the search and then sends the results of the search to a recipient you specify via an email
message. The results are included as an XML attachment to the email message.
You can use the same search criteria with the New-AdminAuditLogSearch cmdlet that's used on the Search-
AdminAuditLog cmdlet. For a list of the search criteria, see Search-AdminAuditLog Cmdlet.
After you run the New-AdminAuditLogSearch cmdlet, Exchange may take up to 15 minutes to deliver the
report to the specified recipient. The XML file attached report can be a maximum of 10 megabytes (MB ). The XML
file contains the same information described in the table in Audit Log Contents. For more information about the
structure of the XML file, see Administrator audit log structure.
 NOTE
Outlook Web App doesn't allow you to open XML attachments by default. You can either configure Exchange to allow XML
attachments to be viewed using Outlook Web App, or you can use another email client, such as Microsoft Outlook, to view
the attachment. For information about how to configure Outlook Web App to allow you to view an XML attachment, see
View or configure Outlook Web App virtual directories.

For information about how to use the New-AdminAuditLogSearch cmdlet, see Search the role group changes
or administrator audit logs.

Manual audit log entries

In addition to logging Exchange cmdlets when they're run, Exchange 2013 enables you to manually write log
entries to the audit log. Exchange 2013 supports this using the Write-AdminAuditLog cmdlet. Situations where
you might want to add a manual log entry include the following:
Custom script entry and exit
Change control information
Maintenance start and end times
With the Write-AdminAuditLog cmdlet, you specify a string of text to include in the audit log using the
Comment parameter. The Comment parameter accepts an alphanumeric string up to 500 characters. Included in
the manual audit log entry along with the comment string is all of the same information captured when an
Exchange cmdlet is logged. For a description of each field included in the audit log, see the table in Audit Log
Contents.
You can retrieve manual audit log entries the same way as any other log entry, using the EAC auditing page or
using the Search-AdminAuditLog or New-AdminAuditLogSearch cmdlets.
To view the contents of the Comment parameter on the Write-AdminAuditLog cmdlet in a manual audit log
entry, see Search the role group changes or administrator audit logs.

Active Directory replication

Administrator audit logging relies on Active Directory replication to replicate the configuration settings you specify
to the domain controllers in your organization. Depending on your replication settings, the changes you make may
not be immediately applied to all servers running Exchange 2013 or Exchange 2010 in your organization.

Admin Audit Log agent

The Admin Audit Log built-in cmdlet extension agent performs administrator audit logging of cmdlet operations
in Exchange 2013. This agent reads the audit log configuration and then performs an evaluation of each cmdlet
run in your organization. If the criteria you've specified in the audit log configuration matches the cmdlet that's
being run, the agent generates an audit log.
The Admin Audit Log agent is enabled by default, which is required for audit logging to function. It can't be
disabled, and its priority can't be changed. For more information about cmdlet extension agents, see Cmdlet
extension agents.
 Administrator audit log structure
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Administrator audit logs contain a record of all the cmdlets and parameters that have been run in the Exchange
Management Shell and by the Exchange admin center (EAC ). They're created on-demand when you run the
Administrator audit log report in the EAC, or when you run the New-AdminAuditLogSearch cmdlet in the Shell.
For more information about audit logs, see Administrator audit logging.
The audit logs are XML files and can contain multiple audit log entries. The following table describes each XML tag
and its associated attributes.
Looking for management tasks related to Administrator audit logs? See Manage administrator audit logging.
Audit log XML tags and attributes
ELEMENT ATTRIBUTE DESCRIPTION

<?xml version="1.0" N/A This is the XML document

encoding="utf-8"?> declaration tag. It's included in
every audit log XML file and
contains the XML version number
and the character encoding value.

SearchResults N/A This tag contains all the audit log

entries in the XML file. The Event
tag is a child of this tag.
There is only one SearchResults
tag per XML file.

Event This tag contains the audit log

entry for an individual cmdlet. This
tag contains the Caller , Cmdlet
, ObjectModified , RunDate ,
Succeeded , Error , and
OriginatingServer attributes.
The CmdletParameters and
ModifiedProperties tags are
children of this tag.
There is one Event tag per audit
log entry.

Caller This attribute contains the user

account of the user who ran the
cmdlet in the Cmdlet attribute.

Cmdlet This attribute contains the name of

the cmdlet that was run by the user
in the Caller attribute.
ELEMENT ATTRIBUTE DESCRIPTION

ObjectModified This attribute contains the object

that was modified by the cmdlet
specified in the Cmdlet attribute.
The ModifiedProperties tag
shows which properties were
modified on this object.

RunDate This attribute contains the date and

time when the cmdlet in the
Cmdlet attribute was run.

Succeeded This attribute specifies whether the

cmdlet in the Cmdlet attribute ran
successfully. The value is either
True or False .

Error This attribute contains the error

message generated if the cmdlet in
the Cmdlet attribute failed to
complete successfully. If no error
was encountered, the value is set to
None .

OriginatingServer This attribute contains the server

on which the cmdlet specified in the
Cmdlet attribute was run.

CmdletParameters N/A This tag contains all of the

parameters specified when the
cmdlet was run. The Parameter
tag is a child of this tag.
There is one CmdletParameters
tag per Event tag.

Parameter This tag contains an individual

parameter that was specified when
the cmdlet was run. This tag
contains the Name and Value
attributes.
There can be multiple Parameter
tags per CmdletParameters tag.
 ELEMENT ATTRIBUTE DESCRIPTION

Name This attribute contains the name of

the parameter that was specified on
the cmdlet that was run.

Value This attribute contains the value

that was provided on the
parameter specified in the Name
attribute.

ModifiedProperties N/A This tag contains all of the

properties that were modified by
the cmdlet that was run. The
Property tag is a child of this tag.

There is one ModifiedProperties

tag per Event tag.

IMPORTANT
This tag is only populated if the
LogLevel parameter on the Set-
AdminAuditLogConfig cmdlet
is set to Verbose .

Property This tag contains an individual

property that was specified when
the cmdlet was run. This tag
contains the Name , OldValue ,
and NewValue attributes.
There can be multiple Property
tags per ModifiedProperties tag.

Name This attribute contains the name of

the property that was modified
when the cmdlet was run.

OldValue This attribute contains the value

that was contained in the property
specified in the Name attribute
before it was changed.

NewValue This attribute contains the value

that the property in the Name
attribute was changed to.

Example audit log entry

The following is an example of a typical audit log entry. Based on the information in log entry, we know the
following occurred:
On 10/18/2012 at 3:48 P.M. Pacific Daylight Time (UTC -7), the user Administrator ran the cmdlet Set-
Mailbox.
The two following parameters were provided when the Set-Mailbox cmdlet was run:
Identity with a value of david

ProhibitSendReceiveQuota with a value of 10GB

The two following properties on the object david were modified:

NOTE
The modified properties are saved to the audit log because the LogLevel parameter on the
Set-AdminAuditLogConfig cmdlet was set to Verbose in this example.

ProhibitSendReceiveQuota with a new value of 10GB , which replaced the old value of 35GB
The operation completed successfully without any errors.

<?xml version="1.0" encoding="utf-8"?>

<SearchResults>

<Event Caller="corp.e15a.contoso.com/Users/Administrator" Cmdlet="Set-Mailbox"

ObjectModified="corp.e15a.contoso.com/Users/david" RunDate="2012-10-18T15:48:15-07:00" Succeeded="true"
Error="None" OriginatingServer="WIN8MBX (15.00.0516.032)">
<CmdletParameters>
<Parameter Name="Identity" Value="david" />
<Parameter Name="ProhibitSendReceiveQuota" Value="10 GB (10,737,418,240 bytes)" />
</CmdletParameters>
<ModifiedProperties>
<Property Name="ProhibitSendReceiveQuota" OldValue="35 GB (37,580,963,840 bytes)" NewValue="10 GB
(10,737,418,240 bytes)" />
</ModifiedProperties>
</Event>
</SearchResults>
 Manage administrator audit logging
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Administrator audit logging in Microsoft Exchange Server 2013 enables you to create a log entry each time a
specified cmdlet is run. Log entries provide you with information about what cmdlet was run, which parameters
were used, who ran the cmdlet, and what objects were affected. For more information about administrator audit
logging, see Administrator audit logging.

What do you need to know before you begin?

Estimated time to complete each procedure: less than 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Administrator audit logging" entry in the Exchange and Shell infrastructure
permissions topic.
Administrator audit logging relies on Active Directory replication to replicate the configuration settings you
specify to the domain controllers in your organization. Depending on your replication settings, the changes
you make may not be immediately applied to all Exchange 2013 servers in your organization.
Changes to the audit log configuration are refreshed every 60 minutes on computers that have the Shell
open at the time a configuration change is made. If you want to apply the changes immediately, close and
then open the Shell again on each computer.
A command may take up to 15 minutes after it's run to appear in audit log search results. This is because
audit log entries must be indexed before they can be searched. If a command doesn't appear in the
administrator audit log, wait a few minutes and run the search again.
You must use the Shell to perform these procedures.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Specify the cmdlets to be audited

By default, audit logging creates a log entry for every cmdlet that's run. If you're enabling audit logging for the first
time and want this behavior, you don't have to change the cmdlet audit list. If you've previously specified cmdlets
to audit and now want to audit all cmdlets, you can audit all cmdlets by specifying the asterisk (*) wildcard
character with the AdminAuditLogCmdlets parameter on the Set-AdminAuditLogConfig cmdlet, as shown in
the following command.

Set-AdminAuditLogConfig -AdminAuditLogCmdlets *

You can specify which cmdlets to audit by providing a list of cmdlets using the AdminAuditLogCmdlets parameter.
When you provide the list of cmdlets to audit, you can provide single cmdlets, cmdlets with the asterisk (*)
wildcard characters, or a mix of both. Each entry in the list is separated by commas. The following values are all
valid:
New-Mailbox

*TransportRule

*Management*

Set-Transport*

This example audits the cmdlets specified in the preceding list.

Set-AdminAuditLogConfig -AdminAuditLogCmdlets New-Mailbox, *TransportRule, *Management*, Set-Transport*

For detailed syntax and parameter information, see Set-AdminAuditLogConfig.

Specify the parameters to be audited

By default, audit logging creates a log entry for every cmdlet that's run, regardless of the parameters specified. If
you're enabling audit logging for the first time and want this behavior, you don't have to change the parameter
audit list. If you've previously specified parameters to audit and now want to audit all parameters, you can do so by
specifying the asterisk (*) wildcard character with the AdminAuditLogParameters parameter on the Set-
AdminAuditLogConfig cmdlet, as shown in the following command.

Set-AdminAuditLogConfig -AdminAuditLogParameters *

You can specify which parameters you want to audit by using the AdminAuditLogParameters parameter. When
you provide the list of parameters to audit, you can provide single parameters, parameters with the asterisk (*)
wildcard characters, or a mix of both. Each entry in the list is separated by commas. The following values are all
valid:
Database

*Address*

Custom*

*Region

NOTE
For an audit log entry to be created when a command is run, the command must include at least one or more parameters
that exist on at least one or more cmdlets specified with the AdminAuditLogCmdlets parameter.

This example audits the parameters specified in the preceding list.

Set-AdminAuditLogConfig -AdminAuditLogParameters Database, *Address*, Custom*, *Region

For detailed syntax and parameter information, see Set-AdminAuditLogConfig.

Specify the audit log age limit

The audit log age limit determines how long audit log entries will be retained. When a log entry exceeds the age
limit, it's deleted. The default is 90 days.
You can specify the number of days, hours, minutes, and seconds that audit log entries should be kept. To specify a
value, use the format dd.hh.mm:ss where the following applies:
dd: Number of days to keep the audit log entry
hh: Number of hours to keep the audit log entry
mm: Number of minutes to keep the audit log entry
ss: Number of seconds to keep the audit log entry

WARNING
You can set the audit log age limit to a value that's less than the current age limit. If you do this, any audit log entry whose
age exceeds the new age limit will be deleted.
If you set the age limit to 0, Exchange deletes all the entries in the audit log.
We recommend that you grant permissions to configure the audit log age limit only to highly trusted users.

This example specifies an age limit of two years and six months.

Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 913.00:00:00

For detailed syntax and parameter information, see Set-AdminAuditLogConfig.

Enable or disable logging of Test cmdlets

Cmdlets that start with the verb Test aren't logged by default. This is because Test cmdlets can generate a
significant amount of data in a short time. Only enable the logging of Test cmdlets for short periods of time.
This command enables the logging of Test cmdlets.

Set-AdminAuditLogConfig -TestCmdletLoggingEnabled $True

This command disables the logging of Test cmdlets.

Set-AdminAuditLogConfig -TestCmdletLoggingEnabled $False

For detailed syntax and parameter information, see Set-AdminAuditLogConfig.

Disable administrator audit logging

To disable administrator audit logging, use the following command.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $False

Enable administrator audit logging

To enable administrator audit logging, use the following command.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

View administrator audit logging settings
To view the administrator audit logging settings that you've configured for your organization, use the following
command.

Get-AdminAuditLogConfig
 Exchange auditing reports in Exchange 2013
5/30/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Use audit logging to troubleshoot configuration issues by tracking specific changes made by administrators and to
help you meet regulatory, compliance, and litigation requirements. Microsoft Exchange provides two types of audit
logging:
Administrator audit logging records any action, based on an Exchange Management Shell cmdlet,
performed by an administrator. This can help you troubleshoot configuration issues or identify the cause of
security-related or compliance-related problems.
Mailbox audit logging records when a mailbox is accessed by an administrator, a delegated user, or the
person who owns the mailbox. This can help you determine who has accessed a mailbox and what they've
done.

Export audit logs

On the Compliance Management > Auditing page in the Exchange admin center (EAC ), you can search for and
export entries from the administrator audit log and the mailbox audit log.
Export the administrator audit log: Any action performed by an administrator that's based on a Shell
cmdlet and doesn't begin with the verbs Get, Search, or Test is logged in the administrator audit log. Audit
log entries include the cmdlet that was run, the parameter and values used with the cmdlet, and when the
operation was successful. You can search for and export entries from the administrator audit log. When you
export your search results, Microsoft Exchange saves them in an XML file and attaches it to an email
message. For more information, see:
Search the role group changes or administrator audit logs
View and Export the Datacenter Admin Audit Log

NOTE
By default, admin audit log entries are kept for 90 days. When an entry is older than 90 days, it's deleted. This
setting can't be changed in a cloud-based organization. However, it can be changed in an on-premises
Exchange organization by using the Set-AdminAuditLog cmdlet.

Export mailbox audit logs: When mailbox audit logging is enabled for a mailbox, Microsoft Exchange
stores a record of actions performed on mailbox data by non-owners in the mailbox audit log, which is
stored in a hidden folder in the mailbox being audited. Mailbox audit logging can also be configure to log
owner actions. Entries in this log indicate who accessed the mailbox and when, the actions performed, and
whether the action was successful. When you search for entries in the mailbox audit log and export them,
Microsoft Exchange saves the search results in an XML file and attaches it to an email message. For more
information, see Export mailbox audit logs.

Run auditing reports

When you run any of the following reports on the Auditing page in the EAC, the results are displayed in the
details pane of the report.
 Run a non-owner mailbox access report: Use this report to find mailboxes that have been accessed by
someone other than the person who owns the mailbox. For more information, see Run a non-owner
mailbox access report.
Run an administrator role group report: Use this report to search for changes made to administrator role
groups. For more information, see Search the role group changes or administrator audit logs.
Run an in-place discovery and hold report: Use this report to find mailboxes that have been put on, or
removed from, In-Place Hold. For more information, see:
In-Place Hold and Litigation Hold
In-Place eDiscovery
Run a per-mailbox litigation hold report: Use this report to find mailboxes that were put on, or removed
from, litigation hold. For more information, see.
Run a per-mailbox litigation hold report
Place a mailbox on Litigation Hold
Run the admin audit log report: Use this report to view entries from the administrator audit log. Instead
of exporting the administrator audit log, which can take up to 24 hours to receive in an email message, you
can run this report in the EAC. This report records configuration changes made by administrators in your
organization. Up to 5000 entries will be displayed on multiple pages. To narrow the search, you can specify a
date range. For more information, see:
View the administrator audit log
Administrator audit logging

Configure audit logging

Before you can run auditing reports and export audit logs, you have to configure audit logging for your
organization.
Enable mailbox audit logging
You have to enable mailbox audit logging for each mailbox that you want to run a non-owner mailbox access
report for. If mailbox audit logging isn't enabled for a mailbox, you won't get any results when you run a report for
it or export the mailbox audit log.
To enable mailbox audit logging for a single mailbox, run the following command in the Shell.

Set-Mailbox <Identity> -AuditEnabled $true

To enable mailbox auditing for all user mailboxes in your organization, run the following commands.

$UserMailboxes = Get-mailbox -Filter {(RecipientTypeDetails -eq 'UserMailbox')}

$UserMailboxes | ForEach {Set-Mailbox $_.Identity -AuditEnabled $true}

For more information about configuring which actions are logged, see Enable or disable mailbox audit logging for
a mailbox.
Give users access to Auditing reports
By default, administrators can access and run any of the reports on the Auditing page in the EAC. However, other
users, such as a records manager or legal staff, have to be assigned the necessary permissions.
The easiest way to give users access is to add them to the Records Management role group. You can also use the
Shell to give a user access to the Auditing page in the EAC by assigning the Audit Logs role to the user.
Add a user to the Records Management role group
1. Go to Permissions > Admin Roles.
2. In the list of role groups, click Records Management, and then click Edit .
3. Under Members, click Add .
4. In the Select Members dialog box, select the user. You can search for a user by typing all or part of a
display name, and then clicking Search . You can also sort the list by clicking the Name or Display
Name column headings.
5. Click Add and then click OK to return to the role group page.
6. Click Save to save the change to the role group.
In the details pane, the user is listed under Members and can access the Auditing page in the EAC, run auditing
reports, and export audit logs.
Assign the Audit Logs role to a user
Run the following command to assign the Audit Logs role to a user.

New-ManagementRoleAssignment -Role "Audit Logs" -User <Identity>

This enables the user to select Compliance Management > Auditing in the EAC to run any of the reports. The
user can also export the mailbox audit log, and export and view the administrator audit log.

NOTE
To allow a user to run auditing reports but not to export audit logs, use the preceding command to assign the View-Only
Audit Logs role.

Configure Outlook Web App to allow XML attachments

When you export the mailbox audit log or administrator audit log, Microsoft Exchange attaches the audit log, which
is an XML file, to an email message. However, Outlook Web App blocks XML attachments by default. If you want
to use Outlook Web App to access these audit logs, you have to configure Outlook Web App to allow XML
attachments.
Run the following command to allow XML attachments in Outlook Web App.

Set-OwaMailboxPolicy -Identity Default -AllowedFileTypes

'.rpmsg','.xlsx','.xlsm','.xlsb','.tiff','.pptx','.pptm','.ppsx','.ppsm','.docx','.docm','.zip','.xls','.wmv','
.wma','.wav','.vsd','.txt','.tif','.rtf','.pub','.ppt','.png','.pdf','.one','.mp3','.jpg','.gif','.doc','.bmp',
'.avi','.xml'
 Export mailbox audit logs in Exchange 2013
5/30/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

When mailbox auditing is enabled for a mailbox, Microsoft Exchange logs information in the mailbox audit log
whenever a user other than the owner accesses the mailbox. Each log entry includes information about who
accessed the mailbox and when, the actions performed by the non-owner, and whether the action was successful.
Entries in the mailbox audit log are retained for 90 days by default. You can use the mailbox audit log to determine
if a user other than the owner has accessed a mailbox.
When you export entries from mailbox audit logs, Microsoft Exchange saves the entries in an XML file and
attaches it to an email message sent to the specified recipients.

Before you begin

Estimated time to complete each procedure: Times are variable.
Procedures in this topic require specific permissions. See each procedure for its permissions information.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Configure mailbox audit logging

You have to enable mailbox audit logging on each mailbox that you want to audit before you can export and view
mailbox audit logs. You also have to configure Microsoft Outlook Web App to allow XML attachments to use
Outlook Web App to access the audit log.
Step 1: Enable mailbox audit logging
You have to enable mailbox audit logging for each mailbox that you want to run a non-owner mailbox access
report for. If mailbox audit logging isn't enabled for a mailbox, you won't get any results for that mailbox when you
export the mailbox audit log.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox audit logging" entry in the Messaging policy and compliance permissions
topic.
To enable mailbox audit logging for a single mailbox, run the command in the Shell.

Set-Mailbox <Identity> -AuditEnabled $true

To enable mailbox audit logging for all user mailboxes in your organization, run the following commands.

$UserMailboxes = Get-mailbox -Filter {(RecipientTypeDetails -eq 'UserMailbox')}

 $UserMailboxes | ForEach {Set-Mailbox $_.Identity -AuditEnabled $true}

Step 2: Configure Outlook Web App to allow XML attachments

When you export the mailbox audit log, Microsoft Exchange attaches the audit log, which is an XML file, to an
email message. However, Outlook Web App blocks XML attachments by default. To access the exported audit log,
you have to use Microsoft Outlook or configure Outlook Web App to allow XML attachments.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Outlook Web App mailbox policies" entry in the Client Access Permissions topic.
Perform the following procedures to allow XML attachments in Outlook Web App. In Exchange Server 2013, use
the value Default for the Identity parameter.
1. Run the following command to add XML to the list of allowed file types in Outlook Web App.

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -AllowedFileTypes @{add='.xml'}

2. Run the following command to remove XML from the list of blocked file types in Outlook Web App.

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -BlockedFileTypes @{remove='.xml'}

How do you know this worked?

To verify that you've successfully configured mailbox audit logging, do the following:
1. Run the following command to verify that audit logging is configured for mailboxes.

Get-Mailbox | Format-List Name,AuditEnabled

A value of True for the AuditEnabled property verifies that audit logging is enabled.
2. Run the following command to verify that XML attachments are allowed in Outlook Web App.

Get-OwaMailboxPolicy | Select-Object -ExpandProperty AllowedFileTypes

Verify that .xml is included in the list of allowed file types.

3. Run the following command to verify that XML attachments are removed from the blocked file list in
Outlook Web App.

Get-OwaMailboxPolicy | Select-Object -ExpandProperty BlockedFileTypes

Verify that .xml isn't included in the list of blocked file types.

Export the mailbox audit log

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "View -only administrator audit logging" entry in the Shell Infrastructure
Permissions topic.
1. In the Exchange admin center (EAC ), go to Compliance Management > Auditing.
2. Click Export mailbox audit logs.
3. Configure the following search criteria for exporting the entries from the mailbox audit log:
Start and end dates: Select the date range for the entries to include in the exported file.
Mailboxes to search audit log for: Select the mailboxes to retrieve audit log entries for.
Type of non-owner access: Select one of the following options to define the type of non-owner
access to retrieve entries for:
All non-owners: Search for access by administrators and delegated users inside your organization.
External users: Search for access by Microsoft datacenter administrators.
Administrators and delegated users: Search for access by administrators and delegated users
inside your organization.
Administrators: Search for access by administrators in your organization.
Recipients: Select the users to send the mailbox audit log to.
4. Click Export.
Exchange retrieves entries in the mailbox audit log that meet your search criteria, saves them to a file named
SearchResult.xml, and then attaches the XML file to an email message sent to the recipients that you
specified.
How do you know this worked?
Sign in to the mailbox where the mailbox audit log was sent. If you've successfully exported the audit log, you'll
receive a message sent from Exchange. The mailbox audit log (named SearchResult.xml) will be attached to this
message. If you've correctly configured Outlook Web App to allow XML attachments, you can download the
attached XML file.

View the mailbox audit log

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "View -only administrator audit logging" entry in the Shell Infrastructure
Permissions topic.
To save and view the SearchResult.xml file:
1. Sign in to the mailbox where the mailbox audit log was sent.
2. In the Inbox, open the message with the XML file attachment sent by Microsoft Exchange. Notice that the
body of the email message contains the search criteria.
3. Click the attachment and select to download the XML file.
4. Open the SearchResult.xml in Microsoft Excel.

More information
Entries in the mailbox audit log: The following example shows an entry from the mailbox audit log
contained in the SearchResult.xml file. Each entry is preceded by the <Event> XML tag and ends with the
</Event> XML tag. This entry shows that the administrator purged the message with the subject, "
Notification of litigation hold" from the Recoverable Items folder in David's mailbox on April 30, 2010.
 <Event MailboxGuid="6d4fbdae-e3ae-4530-8d0b-f62a14687939"
Owner="PPLNSL-dom\david50001-1363917750"
LastAccessed="2010-04-30T11:01:55.140625-07:00"
Operation="HardDelete"
OperationResult="Succeeded"
LogonType="Admin"
FolderId="0000000073098C3277988F4CB882F5B82EBF64610100A7C317F68C24304BBD18ABE1F185E79B00000026BD4F0000"
FolderPathName="\Recoverable Items\Deletions"
ClientInfoString="Client=OWA;Action=ViaProxy"
ClientIPAddress="10.196.241.168"
InternalLogonType="Owner"
MailboxOwnerUPN="[email protected]"
MailboxOwnerSid="S-1-5-21-290112810-296651436-1966561949-1151"
CrossMailboxOperation="false"
LogonUserDN="Administrator"
LogonUserSid="S-1-5-21-290112810-296651436-1966561949-1149">
<SourceItems>

<ItemId="0000000073098C3277988F4CB882F5B82EBF64610700A7C317F68C24304BBD18ABE1F185E79B00000026BD4F0000A7C
317F68C24304BBD18ABE1F185E79B00000026BD540"
Subject="Notification of litigation hold"
FolderPathName="\Recoverable Items\Deletions" />
</SourceItems>
</Event>

Useful fields in the mailbox audit log: Here's a description of useful fields in the mailbox audit log. They
can help you identify specific information about each instance of non-owner access of a mailbox.

FIELD DESCRIPTION

Owner The owner of the mailbox that was accessed by a non-

owner.

LastAccessed The date and time when the mailbox was accessed.

Operation The action that was performed by the non-owner. For

more information, see the "What gets logged in the
mailbox audit log?" section in Run a Non-Owner Mailbox
Access Report.

OperationResult Whether the action performed by the non-owner

succeeded or failed.

LogonType The type of non-owner access. These include

administrator, delegate, and external.

FolderPathName The name of the folder that contained the message that
was affected by the non-owner.

ClientInfoString Information about the mail client used by the non-owner

to access the mailbox.

ClientIPAddress The IP address of the computer used by the non-owner to

access the mailbox.

InternalLogonType The logon type of the account used by the non-owner to

access this mailbox.

MailboxOwnerUPN The email address of the mailbox owner.

FIELD DESCRIPTION

LogonUserDN The display name of the non-owner.

Subject The subject line of the email message that was affected by
the non-owner.
 Run a non-owner mailbox access report in Exchange
2013
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Non-Owner Mailbox Access Report in the Exchange admin center (EAC ) lists the mailboxes that have been
accessed by someone other than the person who owns the mailbox. When a mailbox is accessed by a non-owner,
Microsoft Exchange logs information about this action in a mailbox audit log that's stored as an email message in a
hidden folder in the mailbox being audited. Entries from this log are displayed as search results and include a list of
mailboxes accessed by a non-owner, who accessed the mailbox and when, the actions performed by the non-owner,
and whether the action was successful. By default, entries in the mailbox audit log are retained for 90 days.
When you enable mailbox audit logging for a mailbox, Microsoft Exchange logs specific actions by non-owners,
including both administrators and users, called delegated users, who have been assigned permissions to a mailbox.
You can also narrow the search to users inside or outside your organization.

What do you need to know before you begin?

Estimated time to complete: 5 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox audit logging" entry in the Messaging policy and compliance
permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Enable mailbox audit logging

You have to enable mailbox audit logging for each mailbox that you want to run a non-owner mailbox access
report for. If mailbox audit logging isn't enabled, you won't get any results when you run a report.
To enable mailbox audit logging for a single mailbox, run the following Shell command.

Set-Mailbox <Identity> -AuditEnabled $true

For example, to enable mailbox auditing for a user named Florence Flipo, run the following command.

Set-Mailbox "Florence Flipo" -AuditEnabled $true

To enable mailbox auditing for all user mailboxes in your organization, run the following commands.

$UserMailboxes = Get-mailbox -Filter {(RecipientTypeDetails -eq 'UserMailbox')}

 $UserMailboxes | ForEach {Set-Mailbox $_.Identity -AuditEnabled $true}

How do you know this worked?

Run the following command to verify that you've successfully configured mailbox audit logging.

Get-Mailbox | Format-List Name,AuditEnabled

A value of True for the AuditEnabled property verifies that audit logging is enabled.

Run a non-owner mailbox access report

1. In the EAC, navigate to Compliance Management > Auditing.
2. Click Run a non-owner mailbox access report.
By default, Microsoft Exchange runs the report for non-owner access to any mailboxes in the organization
over the past two weeks. The mailboxes listed in the search results have been enabled for mailbox audit
logging.
3. To view non-owner access for a specific mailbox, select the mailbox from the list of mailboxes. View the
search results in the details pane.

TIP
Want to narrow the search results? Select the start date, end date, or both, and select specific mailboxes to search. Click
Search to re-run the report.

Search for specific types of non-owner access

You can also specify the type of non-owner access, also called the logon type, to search for. Here are your options:
All non-owners Search for access by administrators and delegated users inside your organization. Also
includes access user outside of your organization.
External users Search for access by users outside of your organization.
Administrators and delegated users Search for access by administrators and delegated users inside your
organization.
Administrators Search for access by administrators in your organization.
How do you know this worked?
To verify that you've successfully run a non-owner mailbox access report, check the search results pane. Mailboxes
that you ran the report for are displayed in this pane. If there are no results for a specific mailbox, it's possible there
hasn't been access by a non-owner or that non-owner access hasn't taken place within the specified date range. As
previously described, be sure to verify that audit logging has been enabled for the mailboxes you want to search
for access by non-owners.

What gets logged in the mailbox audit log?

When you run a non-owner mailbox access report, entries from the mailbox audit log are displayed in the search
results in the EAC. Each report entry contains this information:
Who accessed the mailbox and when
The actions performed by the non-owner
 The affected message and its folder location
Whether the action was successful
The following table lists the actions performed by non-owners that can be logged by mailbox audit logging. In the
table, a Yes indicates that the action can be logged for that logon type, and a No indicates that an action can't be
logged. An asterisk ( * ) indicates that the action is logged by default when mailbox audit logging is enabled for the
mailbox. If you want to track actions that aren't logged by default, you have to use PowerShell to enable logging of
those actions.

NOTE
An administrator who has been assigned the Full Access permission to a user's mailbox is considered a delegated user.

ACTION DESCRIPTION ADMINISTRATOR DELEGATED USER

Copy A message was copied to Yes No

another folder.

Create An item is created in the Yes* Yes*

Calendar, Contacts, Notes,
or Tasks folder in the
mailbox; for example, a new
meeting request is created.
Note that message or folder
creation isn't audited.

FolderBind A mailbox folder was Yes* Yes

accessed.

Hard-delete A message was purged from Yes* Yes*

the Recoverable Items folder.

MessageBind A message was viewed in Yes No

the preview pane or opened.

Move A message was moved to Yes* Yes

another folder.

Move To Deleted Items A message was moved to Yes* Yes

the Deleted Items folder.

Send as A message was sent using Yes* Yes*

SendAs permission. This
means another user sent the
message as though it came
from the mailbox owner.
ACTION DESCRIPTION ADMINISTRATOR DELEGATED USER

Send on behalf of A message was sent using Yes* Yes

SendOnBehalf permission.
This means another user
sent the message on behalf
of the mailbox owner. The
message will indicate to the
recipient who the message
was sent on behalf of and
who actually sent the
message.

Soft-delete A message was deleted from Yes* Yes*

the Deleted Items folder.

Update A message was changed. Yes* Yes*

NOTE
*Audited by default if auditing is enabled for a mailbox.
 Run a per-mailbox litigation hold report in Exchange
2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

If your organization is involved in a legal action, you may have to take steps to preserve relevant data, such as
email messages, that may be used as evidence. In situations like this, you can use litigation hold to retain all email
sent and received by specific people or retain all email sent and received in your organization for a specific time
period. For more information about what happens when a mailbox is on litigation hold and how to enable and
disable it, see the "Mailbox Features" section in Manage user mailboxes.
Use the litigation hold report to keep track of the following types of changes made to a mailbox in a given time
period:
Litigation hold was enabled.
Litigation hold was disabled.
For each of these change types, the report includes the user who made the change and the time and date the
change was made.

What do you need to know before you begin?

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "View -only administrator audit logging" entry in the Shell Infrastructure
Permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to run a litigation hold report

1. In the EAC, navigate to Compliance Management > Auditing.
2. Click Run a per-mailbox litigation hold report.
Microsoft Exchange runs the report for litigation hold changes made to any mailbox in the past two weeks.
3. To view the changes for a specific mailbox, in the search results pane, select the mailbox. View the search
results in the details pane.

TIP
Want to narrow the search results? Select the start date, end date, or both, and select specific mailboxes to search. Click
Search to re-run the report.
How do you know this worked?
To verify that you've successfully run a litigation hold report, mailboxes that had litigation hold changes within the
date range are displayed in the search results pane. If there are no results, then no changes to litigation hold have
taken place within the date range or recent changes haven't taken effect yet.

NOTE
When a mailbox is put on litigation hold, it can take up to 60 minutes for the hold to take effect.
 Search the role group changes or administrator audit
logs in Exchange 2013
6/14/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can search the administrator audit logs to discover who made changes to organization, server, and recipient
configuration. This can be helpful when you're trying to track the cause of unexpected behavior, to identify a
malicious administrator, or to verify that compliance requirements are being met. For more information about
administrator audit logging, see Administrator audit logging.
If you want to search the mailbox audit log, see Mailbox Audit Logging.

What do you need to know before you begin?

Estimated time to complete each procedure: less than 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "View -only administrator audit logging" entry in the Exchange and Shell
Infrastructure Permissions topic.
Administrator audit logging is enabled by default. To verify that it's enabled, run the following command:

Get-AdminAuditLogConfig | Format-List AdminAuditLogEnabled

A value of True indicates that administrator audit logging is enabled. A value of False indicates that it's
disabled. If you need to enable administrator audit logging for an on-premises Exchange organization, run
the following command:

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true

For more information, see Configure Administrator Audit Logging.

For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to run the management role group changes report
If you want to know what changes to management role group membership have been made to role groups in
your organization, you can use the Administrator Role Group report in the Exchange admin center (EAC ). Using
the Administrator Role Group report, you can view a list of role groups that have changed during a specified date
range. You can also select the specific role groups you want to view changes for.
1. In the EAC, select Compliance management > Auditing, and then click Run an administrator role
group report.
2. Select a date range using the Start date and End date fields.
3. Click Select role groups, and then select the role groups you want to show changes for or leave this field
blank to search for changes in all role groups.
4. Click Search.
If any changes are found using the criteria you specified, a list of changes will be displayed in the results pane.
Clicking a role group displays the changes to the role group in the details pane.

Use the EAC to export the administrator audit log

If you want to create an XML file that contains changes made to your organization, you can use the Export
Administrator Audit Log report in the EAC. Using the Export Administrator Audit Log report, you can specify a
date range to search for audit log entries that contain changes made by users you specify. The XML file is then
sent to a recipient as an email attachment. The maximum size of the XML file is 10 megabytes (MB ).

NOTE
Outlook Web App doesn't allow you to open XML attachments by default. You can either configure Exchange to allow XML
attachments to be viewed using Outlook Web App, or you can use another email client, such as Microsoft Outlook, to view
the attachment. For information about how to configure Outlook Web App to allow you to view an XML attachment, see
View or configure Outlook Web App virtual directories.

1. In the EAC, select Compliance management > Auditing, and then click Export the administrator
audit log.
2. Select a date range using the Start date and End date fields.
3. In the Send the auditing report to field, click Select users and then select the recipient you want to send
the report to.
4. Click Export.
If any log entries are found using the criteria you specified, an XML file will be created and sent as an email
attachment to the recipient you specified.

Use the Shell to search for audit log entries

You can use the Shell to search for audit log entries that meet the criteria you specify. For a list of search criteria,
see Administrator audit logging. This procedure uses the Search-AdminAuditLog cmdlet and displays search
results in the Shell. You can use this cmdlet when you need to return a set of results that exceeds the limits defined
on the New-AdminAuditLogSearch cmdlet or in the EAC Audit Reporting reports.
If you want to send audit log search results in an email attachment to a recipient, see the Use the Shell to search
for audit log entries and send results to a recipient section later in this topic.
To search the audit log for criteria you specify, use the following syntax.

Search-AdminAuditLog - Cmdlets <cmdlet 1, cmdlet 2, ...> -Parameters <parameter 1, parameter 2, ...> -

StartDate <start date> -EndDate <end date> -UserIds <user IDs> -ObjectIds <object IDs> -IsSuccess <$True |
$False >
 NOTE
The Search-AdminAuditLog cmdlet returns a maximum of 1,000 log entries by default. Use the ResultSize parameter to
specify up to 250,000 log entries. Or, use the value Unlimited to return all entries.

This example performs a search for all audit log entries with the following criteria:
Start date: 08/04/2012
End date: 10/03/2012
User IDs: davids, chrisd, kima
Cmdlets: Set-Mailbox
Parameters: ProhibitSendQuota, ProhibitSendReceiveQuota, IssueWarningQuota, MaxSendSize, and
MaxReceiveSize

Search-AdminAuditLog -Cmdlets Set-Mailbox -Parameters ProhibitSendQuota, ProhibitSendReceiveQuota,

IssueWarningQuota, MaxSendSize, MaxReceiveSize -StartDate 08/04/2012 -EndDate 10/03/2012 -UserIds davids,
chrisd, kima

This example searches for changes made to a specific mailbox. This is useful if you're troubleshooting or you need
to provide information for an investigation. The following criteria are used:
Start date: 05/01/2012
End date: 10/03/2012
Object ID: contoso.com/Users/DavidS

Search-AdminAuditLog -StartDate 05/01/2012 -EndDate 10/03/2012 -ObjectID contoso.com/Users/DavidS

If your searches return many log entries, we recommend that you use the procedure provided in Use the Shell to
search for audit log entries and send results to a recipient later in this topic. The procedure in that section
sends an XML file as an email attachment to the recipients you specify, enabling you to more easily extract the
data you're interested in.
For detailed syntax and parameter information, see Search-AdminAuditLog.
View details of audit log entries
The Search-AdminAuditLog cmdlet returns the fields described in the "Audit log contents section of
Administrator audit logging. Of the fields returned by the cmdlet, two fields, CmdletParameters and
ModifiedProperties, contain additional information that isn't viewable by default.
To view the contents of the CmdletParameters and ModifiedProperties fields, use the following steps. Or, you
can use the procedure in Use the Shell to search for audit log entries and send results to a recipient later in
this topic to create an XML file.
This procedure uses the following concepts:
Arrays
User-Defined Variables
1. Decide the criteria you want to search for, run the Search-AdminAuditLog cmdlet, and store the results in
a variable using the following command.
 $Results = Search-AdminAuditLog <search criteria>

2. Each audit log entry is stored as an array element in the variable $Results . You can select an array element
by specifying its array element index. Array element indexes start at zero (0) for the first array element. For
example, to retrieve the 5th array element, which has an index of 4, use the following command.

$Results[4]

3. The previous command returns the log entry stored in array element 4. To see the contents of the
CmdletParameters and ModifiedProperties fields for this log entry, use the following commands.

$Results[4].CmdletParameters
$Results[4].ModifiedProperties

4. To view the contents of the CmdletParameters or ModifiedParameters fields in another log entry,
change the array element index.

Use the Shell to search for audit log entries and send results to a
recipient
You can use the Shell to search for audit log entries that meet the criteria you specify, and then send those results
to a recipient you specify as an XML file attachment. The results are sent to the recipient within 15 minutes. For a
list of search criteria, see Administrator audit logging.

NOTE
Outlook Web App doesn't allow you to open XML attachments by default. You can either configure Exchange to allow XML
attachments to be viewed using Outlook Web App, or you can use another email client, such as Microsoft Outlook, to view
the attachment. For information about how to configure Outlook Web App to allow you to view an XML attachment, see
View or configure Outlook Web App virtual directories.

To search the audit log for criteria you specify, use the following syntax.

New-AdminAuditLogSearch -Cmdlets <cmdlet 1, cmdlet 2, ...> -Parameters <parameter 1, parameter 2, ...> -

StartDate <start date> -EndDate <end date> -UserIds <user IDs> -ObjectIds <object IDs> -IsSuccess <$True |
$False > -StatusMailRecipients <recipient 1, recipient 2, ...> -Name <string to include in subject>

This example performs a search for all audit log entries with the following criteria:
Start date: 08/04/2012
End date: 10/03/2012
User IDs: davids, chrisd, kima
Cmdlets: Set-Mailbox
Parameters: ProhibitSendQuota, ProhibitSendReceiveQuota, IssueWarningQuota, MaxSendSize,
MaxReceiveSize
The command sends the results to the [email protected] SMTP address with "Mailbox limit changes" included
in the subject line of the message.
 New-AdminAuditLogSearch -Cmdlets Set-Mailbox -Parameters ProhibitSendQuota, ProhibitSendReceiveQuota,
IssueWarningQuota, MaxSendSize, MaxReceiveSize -StartDate 08/04/2012 -EndDate 10/03/2012 -UserIds davids,
chrisd, kima -StatusMailRecipients [email protected] -Name "Mailbox limit changes"

NOTE
The report that the New-AdminAuditLogSearch cmdlet generates can be a maximum of 10 MB in size. If the search you
perform returns a report larger than 10 MB, change the search criteria you specified. For example, reduce the size of the
date range and run multiple reports, each with a portion of the original date range.

For more information about the format of the XML file, see Administrator Audit Log Structure.
For detailed syntax and parameter information, see New -AdminAuditLogSearch.
 View the administrator audit log in Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange 2013, you can use the Exchange admin center (EAC ) to search for and view entries in the
administrator audit log. The administrator audit log records specific actions, based on Exchange Management Shell
cmdlet, performed by administrators and users who have been assigned administrative privileges. Entries in the
administrator audit log provide you with information about what cmdlet was run, which parameters were used,
who ran the cmdlet, and what objects were affected.

NOTE
Administrator auditing logging is enabled by default.
The administrator audit log doesn't record any action that is based on an Exchange Management Shell cmdlet that begins
with the verbs Get, Search, or Test.
Audit log entries are kept for 90 days. When an entry is older than 90 days, it's deleted.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "View reports" entry in the Feature Permissions in EOP topic.
As previously stated, administrator audit logging is enabled by default. To verify that it's enabled, you can
run the following command.

Get-AdminAuditLogConfig | Format-List AdminAuditLogEnabled

You can enable administrator audit logging if it's disabled by running the following command.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts for the Exchange admin center in Exchange 2013.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to view the administrator audit log

1. In the EAC, go to Compliance management > Auditing, and choose Run the admin audit log report.
2. Choose a Start date and End date, and then choose Search. All configuration changes made during the
specified time period are displayed, and can be sorted, using the following information:
Date: The date and time that the configuration change was made. The date and time are stored in
 Coordinated Universal Time (UTC ) format.
Cmdlet: The name of the cmdlet that was used to make the configuration change.
User: The name of the user account of the user who made the configuration change.
Up to 5000 entries will be displayed on multiple pages. Specify a smaller date range if you need to narrow
your results. If you select an individual search result, the following additional information is displayed in the
details pane:
Object modified: The object that was modified by the cmdlet.
Parameters (Parameter:Value): The cmdlet parameters that were used, and any value specified
with the parameter.
3. If you want to print a specific audit log entry, choose the Print button in the details pane.

How do you know this worked?

If you've successfully run an administrator audit log report, configuration changes made within the date range you
specify are displayed in the search results pane. If there are no results, change the date range and then run the
report again.

NOTE
When a change is made in your organization, it may take up to 15 minutes to appear in audit log search results. If a change
doesn't appear in the administrator audit log, wait a few minutes and run the search again.
 Anti-spam and anti-malware protection
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 customers are automatically provided with anti-spam and anti-malware
protection. The following topics (and their associated subtopics) provide overview information and configuration
steps for customizing the built-in spam filtering and malware filtering settings so that they best meet the needs of
your organization:
Anti-spam protection Describes the basic built-in anti-spam protection features as well as other anti-spam
protection options such as using a cloud-hosted anti-spam solution and managing quarantined messages.
Anti-malware protection Describes the basic built-in anti-malware protection features as well as other anti-
malware protection options. Among the information included are an Anti-Malware FAQ and details about how to
configure anti-malware settings using the Exchange admin center or the Exchange Management Shell.
If you're looking for information about anti-spam features of Office 365, see Office 365 Email Anti-Spam
Protection.
You can also use anti-malware programs in the Windows operating system on Exchange servers to help further
enhance the security and health of your Exchange organization. However, there are important considerations for
how to best implement file-level scanning with Exchange 2013. For more information, see Anti-Virus Software in
the Operating System on Exchange Servers.

TIP
You can also create transport rules to enforce company specific regulations and policies; for more information see Mail flow
or transport rules. Exchange 2013 customers who have purchased the data loss prevention (DLP) feature can also create DLP
policies to help protect sensitive data; for more information, see Data loss prevention.
 Anti-spam protection
6/11/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Spammers, or malicious senders, use a variety of techniques to send unwanted email into your organization. No
single tool or process can eliminate all spam. However, Microsoft Exchange Server 2013 provides a layered,
multipronged, and multifaceted approach to reducing these unwanted messages. Exchange uses transport agents
to provide anti-spam protection, and the built-in agents that are available in Exchange 2013 are relatively
unchanged from Microsoft Exchange Server 2010.
For more anti-spam features and easier management, you can elect to purchase Microsoft Exchange Online
Protection (EOP ). For a comparison of EOP and Exchange 2013 features, see Benefits of anti-spam features in
Exchange Online Protection over Exchange Server 2013. To learn more about Office 365 anti-spam protection, see
Office 365 Email Anti-Spam Protection.
For information about the built-in anti-malware capabilities in Exchange 2013, see Anti-malware protection.

Anti-spam agents on Mailbox servers

Typically, you would enable the anti-spam agents on a mailbox server if your organization doesn't have an Edge
Transport server, or doesn't do any prior anti-spam filtering before accepting incoming messages. For more
information, see Enable anti-spam functionality on Mailbox servers.
Like all transport agents, each anti-spam agent is assigned a priority value. A lower value indicates a higher
priority, so typically, an anti-spam agent with priority 1 will act on a message before an anti-spam agent with
priority 9. However, the SMTP event where the anti-spam agent is registered is also very important in
determining the order that anti-spam agents act on messages. A low priority anti-spam agent that's registered on
an SMTP event early in the transport pipeline will act on a message before a high priority anti-spam agent that's
registered on an SMTP event later in the transport pipeline.
Based on the default priority value of the anti-spam agent, and the SMTP event in the transport pipeline where the
anti-spam agent is registered, the following list describes the agents and the default order in which they are
applied to messages on a Mailbox server:
1. Sender Filter agent: Sender filtering compares the sender on the MAIL FROM: SMTP command to an
administrator-defined list of senders or sender domains who are prohibited from sending messages to the
organization to determine what action, if any, to take on an inbound message. For more information, see
Sender filtering.
2. Sender ID agent: Sender ID relies on the IP address of the sending server and the Purported Responsible
Address (PRA) of the sender to determine whether the sender is spoofed or not. For more information, see
Sender ID.
3. Content Filter agent: Content filtering assesses the contents of a message. For more information, see
Content filtering.
Spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages
that are incorrectly classified as spam. Spam quarantine provides a temporary storage location for
messages that are identified as spam and that shouldn't be delivered to a user mailbox inside the
organization. For more information, see Spam quarantine.
Content filtering also acts on the safelist aggregation feature. Safelist aggregation collects data from the
 anti-spam safe lists that Microsoft Outlook and Outlook Web App users configure and makes this data
available to the Content Filter agent. For more information, see Safelist Aggregation.
4. Protocol Analysis agent: The Protocol Analysis agent is the underlying agent that implements the sender
reputation functionality. Sender reputation relies on persisted data about the IP address of the sending
server to determine what action, if any, to take on an inbound message. A sender reputation level (SRL ) is
calculated from several sender characteristics that are derived from message analysis and external tests. For
more information, see Sender reputation and the Protocol Analysis agent.

Anti-spam agents on Edge Transport servers

If your organization has an Edge Transport server installed in the perimeter network, all of the anti-spam agents
that are available on a Mailbox server are installed and enabled by default on the Edge Transport server. However,
the following anti-spam agents are only available on an Edge Transport server:
Connection Filtering agent: Connection filtering inspects the IP address of the remote server that's
trying to send messages to determine what action, if any, to take on an inbound message. Connection
filtering uses an IP Block list, IP Allow list, IP Block List provider services and IP Allow List provider
services to determine whether the connection IP should be blocked or allowed. For more information, see
Connection Filtering on Edge Transport Servers.
Recipient Filter agent: Recipient filtering compares the message recipients on the RCPT TO: SMTP
command to an administrator-defined Recipient Block list. If a match is found, the message isn't permitted
to enter the organization. The recipient filter also compares recipients on inbound messages to the local
recipient directory to determine whether the message is addressed to valid recipients. When a message
isn't addressed to valid recipients, the message is rejected. For more information, see Recipient filtering on
Edge Transport servers.

NOTE
Although the Recipient Filter agent is available on Mailbox servers, you shouldn't configure it. When recipient filtering
on a Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the
message is rejected. If you install the anti-spam agents on a Mailbox server, the Recipient Filter agent is enabled by
default. However, it isn't configured to block any recipients.

Attachment Filtering agent: Attachment filtering blocks messages based on attachment file name, file
name extension, or file MIME content type. You can configure attachment filtering to block a message and
its attachment, to strip the attachment and allow the message to pass through, or to silently delete the
message and its attachment. For more information, see Attachment filtering on Edge Transport servers.
Based on the default priority value of the anti-spam agent, and the SMTP event in the transport pipeline where the
anti-spam agent is registered, this is the default order in which the anti-spam agents are applied on an Edge
Transport server:
1. Connection Filtering agent
2. Sender Filter agent
3. Recipient Filter agent
4. Sender ID agent
5. Content Filter agent
6. Protocol Analysis agent for sender reputation
7. Attachment Filtering agent
Anti-spam stamps
Anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or stamps, such as
sender-specific information, puzzle validation results, and content filtering results, to messages as they pass
through the anti-spam features that filter inbound messages from the Internet. For more information, see Anti-
spam stamps.

Strategy for anti-spam approach

Your strategy for how to configure the anti-spam features and establish the aggressiveness of your anti-spam
agent settings requires that you plan and calculate carefully. If you set all anti-spam filters to their most aggressive
levels and configure all anti-spam features to reject all suspicious messages, you're more likely to reject messages
that aren't spam. On the other hand, if you don't set the anti-spam filters at a sufficiently aggressive level and don't
set the spam confidence level (SCL ) threshold low enough, you probably won't see a reduction in the spam that
enters your organization.
It's a best practice to reject a message when Exchange detects a bad message through the Connection Filtering
agent, Recipient Filter agent, or Sender Filter agent. This approach is better than quarantining such messages or
assigning metadata, such as anti-spam stamps, to such messages. The Connection Filtering agent and Recipient
Filter agent automatically block messages that are identified by the respective filters. The Sender Filter agent is
configurable.
This best practice is recommended because the SCL that underlies connection filtering, recipient filtering, or
sender filtering is relatively high. For example, with sender filtering, where the administrator has configured
specific senders to block, there's no reason to assign the sender filtering data to such messages and to continue to
process them. In most organizations, blocked messages should be rejected. (If you didn't want the messages
rejected, you wouldn't have put them on the Blocked Senders List.)
The same logic applies to real-time block list services and recipient filtering, although the underlying confidence
isn't as high as the IP Block list. You should be aware that the further along the mail flow path a message travels,
the greater the probability of false positives, because the anti-spam features are evaluating more variables.
Therefore, you may find that if you configure the first several anti-spam features in the anti-spam chain more
aggressively, you can reduce the bulk of your spam. As a result, you'll save processing, bandwidth, and disk
resources so that you can process more ambiguous messages.
Ultimately, you must plan to monitor the overall effectiveness of the anti-spam features. If you monitor carefully,
you can continue to adjust the anti-spam features to work well together for your environment. With this approach,
you should plan on a fairly non-aggressive configuration of the anti-spam features when you start. This approach
lets you minimize the number of false positives. As you monitor and adjust the anti-spam features, you can
become more aggressive about the type of spam and spam attacks that your organization experiences.

See Also
Office 365 Email Anti-Spam Protection
 Benefits of anti-spam features in Exchange Online
Protection over Exchange Server 2013
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following are benefits of using Exchange anti-spam protection in the cloud (Microsoft Exchange Online or
Microsoft Exchange Online Protection) as opposed to Microsoft Exchange Server 2013, which has most of the
same built-in anti-spam capabilities as Microsoft Exchange Server 2010:
More control and easier configuration: Administrators can use the Exchange admin center (EAC ) web-
based management console in order to customize spam filtering settings so that they best meet the needs
of your organization. There is no anti-spam user interface in Exchange Server 2013. EOP anti-spam
protection features are included in Exchange Online
Stronger connection filtering: In Exchange 2013, connection filtering IP Allow lists and IP Block lists are
available only if you install an Edge Transport server in your perimeter network. For more information, see
Edge Transport servers. In the cloud, you can choose to skip spam filtering on email messages sent from
trusted senders (gathered from various third-party sources), ensuring that these messages are not
mistakenly marked as spam. Also, the hosted filtering service uses Microsoft's own block lists and lists
aggregated from vendors to provide greater IP -level filtering.
Stronger content filtering: You can easily configure your content filter policy to:
Filter messages written in specific languages.
Filter messages sent from specific countries or regions.
Mark bulk email messages (such as advertisements and marketing emails) as spam.
Search for attributes in a message and act upon the message if it matches a specific advanced spam
option attribute. If you are concerned about phishing, some of these options offer a combination of
Sender ID and SPF technologies to authenticate and verify that messages are not spoofed.
In addition to the above content filter options that you can configure in the EAC, the hosted filtering service
uses additional URL lists to block suspicious messages that contain specific URLs within their message
body.
Quicker updates: Spam updates are propagated more quickly across the network. In Exchange Server
2013 updates occur two times per month, whereas the service is updated multiple times per hour.
Outbound filtering: Outbound spam filtering is always enabled if you use the hosted service for sending
outbound email, thereby protecting organizations using the service and their intended recipients.
 Enable anti-spam functionality on Mailbox servers
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, the following anti-spam agents are available in the Transport service on
Mailbox servers, but they are not installed by default:
Content Filter agent
Sender ID agent
Sender Filter agent
Protocol Analysis agent for sender reputation
However, you can install these anti-spam agents on a Mailbox server using a script in the Exchange
Management Shell. Typically, you would install the anti-spam agents on a Mailbox server only when your
organization accepts all incoming mail without any prior anti-spam filtering.

NOTE
Although the Recipient Filter agent is available on Mailbox servers, you shouldn't configure it. When recipient filtering on a
Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the message is
rejected. Although the Recipient Filter agent is enabled by default, it isn't configured to block any recipients. For more
information, see Manage recipient filtering on Edge Transport servers.

What happens if you install the available anti-spam agents in the Transport service on a Mailbox server, but you
also have other Exchange anti-spam agents operating on the messages before they reach the Mailbox server?
For example, what if you have an Edge Transport server in the perimeter network? The anti-spam agents on the
Mailbox server recognize the anti-spam X-header values that are added to messages by other Exchange anti-
spam agents, and messages that contain these X-headers pass through without being scanned again. However,
recipient look-ups performed by the Recipient Filter agent will occur again on the Mailbox server.

What do you need to know before you begin?

Estimated time to complete this task: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport configuration" entry in the Mail flow permissions topic.
The Connection Filter agent and the Attachment Filter agent aren't available on Mailbox servers. They're
only available on an Edge Transport server. However, the Malware agent is installed and enabled by
default on a Mailbox server. For more information, see Anti-malware protection.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Step 1: Use the Shell to run the Install-AntispamAgents.ps1 script
Run the following command:

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1

How do you know this step worked?

You know this step worked if the script runs without errors, and asks you to restart the Microsoft Exchange
Transport service.

Step 2: Use the Shell to restart the Microsoft Exchange Transport

service
Run the following command:

Restart-Service MSExchangeTransport

How do you know this step worked?

You know this step worked if the Microsoft Exchange Transport service restarts without errors.

Step 3: Use the Shell to specify the internal SMTP servers in your
organization
You need to specify the IP addresses of any internal SMTP servers that should be ignored by the Sender ID
agent. In fact, you need to specify the IP address of at least one internal SMTP server. If the Mailbox server
where you're running the anti-spam agents is the only SMTP server in your organization, specify the IP address
of that computer.
To add the IP addresses of internal SMTP servers without affecting any existing values, run the following
command:

Set-TransportConfig -InternalSMTPServers @{Add="<ip address1>","<ip address2>"...}

This example adds the internal SMTP server addresses 10.0.1.10 and 10.0.1.11 to the transport configuration of
your organization.

Set-TransportConfig -InternalSMTPServers @{Add="10.0.1.10","10.0.1.11"}

How do you know this step worked?

To verify that you have successfully specified the IP address of at least one internal SMTP server, do the
following:
1. Run the following command:

Get-TransportConfig | Format-List InternalSMTPServers

2. Verify the IP address of at least one valid internal SMTP server is displayed.
 Sender filtering
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sender filtering relies on the MAIL FROM: SMTP header to determine what action, if any, to take on an inbound
email message. Sender filtering is provided by the Sender Filter agent.
The Sender Filter agent acts on messages from specific senders outside the organization. Administrators maintain
a list of senders who are blocked from sending messages to the organization. As an administrator, you can block
single senders (such as [email protected]), whole domains (contoso.com), or domains and all subdomains
(*.contoso.com). You can also configure what action the Sender Filter agent should take when a message that has a
blocked sender is found. You can configure the following actions:
The Sender Filter agent rejects the SMTP request with a 554 5.1.0 Sender Denied SMTP session error and
closes the connection.
The Sender Filter agent accepts the message and updates the message to indicate that the message came
from a blocked sender. Because the message came from a blocked sender and it's marked as such, the
Content Filter agent will use this information when it calculates the spam confidence level (SCL ).
You can designate blocked senders and define how the Sender Filter agent should act on messages from blocked
senders. For more information about how to configure the Sender Filter agent, see Manage sender filtering.

IMPORTANT
The MAIL FROM: SMTP headers can be spoofed. Therefore, you shouldn't rely on the Sender Filter agent only. Use the
Sender Filter agent and the Sender ID agent together. The Sender ID agent uses the originating IP address of the sending
server to verify that the domain in the MAIL FROM: SMTP header matches the domain that's registered. For more
information about the Sender ID agent, see Sender ID.

Using the Sender Filter agent to block messages

When the Sender Filter agent is enabled on an Exchange server, sender filtering blocks inbound messages that
come from the Internet, but aren't authenticated. These messages are handled as external messages. You can
disable the Sender Filter agent in individual computer configurations. For more information, see Manage sender
filtering.
When you enable the Sender Filter agent on an Exchange server, the Sender Filter agent filters all messages that
come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come
from external sources are filtered. External sources are defined as non-authenticated sources. These are considered
anonymous Internet sources.
As a best practice, you shouldn't filter email messages from trusted partners or from inside your organization.
When you run anti-spam filters, there's always a chance that the filters will detect false positives. You should
configure anti-spam agents to run only on messages from potentially untrusted and unknown sources. This will
reduce the chance that anti-spam filters will mishandle legitimate messages. You can enable and disable the
Sender Filter agent to run on messages from any source. For more information, see Manage sender filtering.
You can configure the Sender Filter agent to block inbound messages that don't specify a sender and domain in the
MAIL FROM: SMTP header. You can use this feature to prevent non-delivery report (NDR ) attacks on the
Exchange server. Most legitimate SMTP messages come from SMTP servers that provide a sender and domain in
the MAIL FROM: SMTP command.

Specifying the block action

After you've specified blocked senders and domains, you must specify how you want the Sender Filter agent to act
on messages from blocked senders and domains. We recommend that you reject the messages. When you use the
Sender Filter agent to block email addresses and domains that are specified by an Exchange administrator, the
chance of false positives is relatively less than when you use other anti-spam agents. For example, the Content
Filter agent is an anti-spam agent that relies on many different variables to determine whether a message is spam.
There are only two scenarios in which legitimate messages may be rejected by the Sender Filter agent:
If you mistype an email address or domain name, the wrong sender may be blocked.
If a domain name is reregistered to a legitimate company after you add the domain to your Blocked
Senders list, you will unintentionally block legitimate messages.
In either of these cases, it may still make sense to reject the messages.
 Manage sender filtering
6/11/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sender filtering is provided by the Sender Filter agent. The Sender Filter agent relies on the MAIL FROM: SMTP
header to determine what action, if any, to take on an inbound email message.
When sender filtering functionality is enabled on an Exchange server, sender filtering functionality filters all
messages that come through all Receive connectors on that computer.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
topic.
You can only use the Shell to perform this procedure.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable sender filtering

To disable sender filtering, run the following command:

Set-SenderFilterConfig -Enabled $false

To enable sender filtering, run the following command:

Set-SenderFilterConfig -Enabled $true

NOTE
When you disable sender filtering, the underlying Sender Filter agent is still enabled. To disable the Sender Filter agent, run
the command: Disable-TransportAgent "Sender Filter Agent" .

How do you know this worked?

To verify that you have successfully enabled or disabled sender filtering, do the following:
1. Run the following command:

Get-SenderFilterConfig | Format-List Enabled

2. Verify the value displayed is the value you configured.

Use the Shell to configure blocked senders and domains

To replace the existing values, run the following command:

Set-SenderFilterConfig -BlockedSenders <sender1,sender2...> -BlockedDomains <domain1,domain2...> -

BlockedDomainsAndSubdomains <domain1,domain2...>

This example configures the Sender Filter agent to block messages from [email protected] and
[email protected], messages from the fabrikam.com domain, and messages from northwindtraders.com and all
its subdomains.

Set-SenderFilterConfig -BlockedSenders [email protected],[email protected] -BlockedDomains fabrikam.com -

BlockedDomainsAndSubdomains northwindtraders.com

To add or remove entries without modifying any existing values, run the following command:

Set-SenderFilterConfig -BlockedSenders @{Add="<sender1>","<sender2>"...; Remove="<sender1>","<sender2>"...} -

BlockedDomains @{Add="<domain1>","<domain2>"...; Remove="<domain1>","<domain2>"...} -
BlockedDomainsAndSubdomains @{Add="<domain1>","<domain2>"...; Remove="<domain1>","<domain2>"...}

This example configures the Sender Filter agent with the following information:
Add [email protected] and [email protected] to the list of existing senders who are blocked.
Remove tailspintoys.com from the list of existing sender domains that are blocked.
Add blueyonderairlines.com to the list of existing sender domains and subdomains that are blocked.

Set-SenderFilterConfig -BlockedSenders @{Add="[email protected]","[email protected]"} -BlockedDomains

@{Remove="tailspintoys.com"} -BlockedDomainsAndSubdomains @{Add="blueyonderairlines.com"}

How do you know this worked?

To verify that you have successfully configured blocked senders, do the following:
1. Run the following command:

Get-SenderFilterConfig | Format-List BlockedSenders,BlockedDomains,BlockedDomainsAndSubdomains

2. Verify the values displayed are the values you configured.

Use the Shell to enable or disable blocking messages with blank

senders
To enable or disable blocking message with blank senders, run the following command:
 Set-SenderFilterConfig -BlankSenderBlockingenabled <$true | $false>

This example configures the Sender Filter agent to block messages that don't specify a sender in the MAIL FROM:
SMTP command:

Set-SenderFilterConfig -BlankSenderBlockingEnabled $true

How do you know this worked?

To verify that you have successfully enabled or disabled blocking messages with blank senders, do the following:
1. Run the following command:

Get-SenderFilterConfig | Format-List BlankSenderBlockingEnabled

2. Verify the value displayed is the value you configured.

 Sender ID
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Sender ID agent is an anti-spam agent that's available in Microsoft Exchange Server 2013. The Sender ID
agent relies on the RECEIVED SMTP header and a query to the sending system's DNS service to determine what
action, if any, to take on an inbound message.
Sender ID is intended to combat the impersonation of a sender and a domain, a practice that's frequently called
spoofing. A spoofed mail is an email message that has a sending address that was modified to appear as if it
originates from a sender other than the actual sender of the message.
Spoofed mails typically contain a From: address that purports to be from a certain organization. In the past, it was
relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL FROM: header, and in the
RFC 2822 message data, such as From: "Masato Kawai" [email protected], because the headers weren't
validated.

Using Sender ID to combat spoofing

Sender ID makes spoofing more difficult. When you enable Sender ID, each message contains a Sender ID status
in the metadata of the message. When an email message is received, the Exchange server queries the sender's
DNS server to verify that the IP address from which the message was received is authorized to send messages for
the domain that's specified in the message headers. The IP address of the authorized sending server is referred to
as the purported responsible address (PRA).
Domain administrators publish sender policy framework (SPF ) records on their DNS servers. SPF records
identify authorized outbound email servers. If an SPF record is configured on the sender's DNS server, the
Exchange server parses the SPF record and determines whether the IP address from which the message was
received is authorized to send email on behalf of the domain that's specified in the message. For more information
about what an SPF record contains and how to create an SPF record, see Sender ID.
The Exchange server updates the message metadata with the Sender ID status based on the SPF record. After the
Exchange server updates the message metadata, message delivery proceeds as it ordinarily would.

Sender ID status values

The Sender ID evaluation process generates a Sender ID status for the message. The Sender ID status is used to
evaluate the spam confidence level (SCL ) rating for the message. This status can be set to one of the following
values:
Pass: Both the IP address and Purported Responsible Address (PRA) passed the Sender ID verification
check.
Neutral: Published Sender ID data is explicitly inconclusive.
Soft fail: The IP address for the PRA may be in the not permitted set.
Fail: The IP Address is not permitted; no PRA is found in the incoming mail or the sending domain does
not exist.
None: No published SPF data exists in the sender's DNS.
TempError: A temporary DNS failure occurred, such as an unavailable DNS server.
 PermError: The DNS record is invalid, such as an error in the record format.
The Sender ID status is added to the message metadata and is later converted to a MAPI property. The junk email
filter in Microsoft Outlook uses the MAPI property during the generation of the SCL value.
Outlook neither displays the Sender ID status nor necessarily flags a message as junk at certain Sender ID values.
Outlook uses the Sender ID status value only during the calculation of the SCL value.
Besides the seven scenarios that generate the Sender ID statuses, the Sender ID evaluation process may reveal
instances where the From: IP address is missing. If the From: IP address is missing, the Sender ID status can't be
set. If the Sender ID status can't be set, Exchange continues to process the message without including a Sender ID
status on the message. The message isn't discarded or rejected. In this scenario, Sender ID status isn't set, and an
application event is logged.
For more information about how the Sender ID status is displayed in messages, see Anti-spam stamps.

Sender ID options for handling spoofed mail and unreachable DNS

servers
You can also define how the Exchange server handles messages that are identified as spoofed mail and how the
Exchange server handles messages when a DNS server can't be reached. The options for how the Exchange
server handles spoofed mail and unreachable DNS servers include the following actions:
Stamp the status: This option is the default action. All inbound messages to your organization have the
Sender ID status included in the metadata of the message.
Reject: This option rejects the message and sends an SMTP error response to the sending server. The
SMTP error response is a 5xx level protocol response with text that corresponds to the Sender ID status.
Delete: This option deletes the message without informing the sending system of the deletion. In fact, the
Exchange server sends a fake OK SMTP command to the sending server and then deletes the message.
Because the sending server assumes the message was sent, it doesn't retry sending the message in the
same session.
For more information about how to configure the Sender ID agent, see Manage Sender ID.

Updating your organization's Internet-facing DNS to support Sender

ID
The effectiveness of Sender ID depends on specific DNS data. The more organizations that update their Internet-
facing DNS servers by using an SPF record, the more effectively Sender ID identifies spoofed email messages.
To support the Sender ID infrastructure, you must update your Internet-facing DNS data by creating an SPF
record and hosting the SPF record on your public DNS servers. For more information about how to create and
deploy SPF records, see Sender ID.

Specifying recipients and sender domains to exclude from Sender ID

filtering
You may want to exclude specific recipients and sender domains from Sender ID filtering. To do this, you specify
the recipients and sender domains using the Set-SenderIdConfig cmdlet in the Exchange Management Shell.
For more information, see Set-SenderIdConfig.
 Manage Sender ID
6/11/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sender ID functionality is provided by the Sender ID agent. Sender ID validates the origin of email messages by
verifying the IP address of the sender against the purported owner of the sender domain. Sender ID filtering is
performed on inbound messages that come from the Internet but aren't authenticated. These messages are
handled as external messages.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
topic.
You can only use the Shell to perform this procedure.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable Sender ID

To disable Sender ID, run the following command:

Set-SenderIDConfig -Enabled $false

To enable Sender ID, run the following command:

Set-SenderIDConfig -Enabled $true

NOTE
When you disable Sender ID, the underlying Sender ID agent is still enabled. To disable the Sender ID agent, run the
command: Disable-TransportAgent "Sender ID Agent" .

How do you know this worked?

To verify that you have successfully enabled or disabled Sender ID, do the following:
1. Run the following command:

Get-SenderIDConfig | Format-List Enabled

2. Verify the value displayed is the value you configured.

Use the Shell to configure the Sender ID action for spoofed messages
To configure the Sender ID action for spoofed messages, run the following command:

Set-SenderIDConfig -SpoofedDomainAction <StampStatus | Reject | Delete>

This example configures the Sender ID agent to reject any messages where the IP address of the sending server
isn't listed as an authoritative SMTP sending server in the DNS Sender Policy Framework (SPF ) record for the
sending domain.

Set-SenderIDConfig -SpoofedDomainAction Reject

How do you know this worked?

To verify that you have successfully configured the Sender ID action for spoofed messages, do the following:
1. Run the following command:

Get-SenderIDConfig | Format-List SpoofedDomainAction

2. Verify the value displayed is the value you configured.

Use the Shell to configure the Sender ID action for transient errors
To configure the Sender ID action for transient errors, run the following command:

Set-SenderIDConfig -TempErrorAction <StampStatus | Reject | Delete>

This example configures the Sender ID agent to stamp the messages when the Sender ID status can't be
determined due to a temporary DNS server error. The message will be processed by other anti-spam agents and
the Content Filter agent will use the mark when determining the SCL value for the message.

Set-SenderIDConfig -TempErrorAction StampStatus

Note that StampStatus is the default value for the TempErrorAction parameter.

How do you know this worked?

To verify that you have successfully configured the Sender ID action for transient errors, do the following:
1. Run the following command:
 Get-SenderIDConfig | Format-List TempErrorAction

2. Verify the value displayed is the value you configured.

Use the Shell to configure recipient and sender domain exceptions

To replace the existing values, run the following command:

Set-SenderIDConfig -BypassedRecipients <recipient1,recipient2...> -BypassedSenderDomains <domain1,domain2...>

This example configures the Sender ID agent to bypass the Sender ID check for messages sent to
[email protected] and [email protected], and to bypass the Sender ID check for messages sent from the
fabrikam.com domain.

Set-SenderIDConfig -BypassedRecipients [email protected],[email protected] -BypassedSenderDomains fabrikam.com

To add or remove entries without modifying any existing values, run the following command:

Set-SenderIDConfig -BypassedRecipients @{Add="<recipient1>","<recipient2>"...; Remove="<recipient1>","

<recipient2>"...} -BypassedSenderDomains @{Add="<domain1>","<domain2>"...; Remove="<domain1>","<domain2>"...}

This example configures the Sender ID agent with the following information:
Add [email protected] and [email protected] to the list of existing recipients who bypass the Sender
ID check.
Remove tailspintoys.com from the list of existing domains that bypass the Sender ID check.

Set-SenderIDConfig -BypassedRecipients @{Add="[email protected]","[email protected]"} -

BypassedSenderDomains @{Remove="tailspintoys.com"}

How do you know this worked?

To verify that you have successfully configured recipient and sender domain exceptions, do the following:
1. Run the following command:

Get-SenderIDConfig | Format-List BypassedRecipients,BypassedSenderDomains

2. Verify the values displayed are the values you configured.

 Content filtering
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

NOTE
On November 1, 2016, Microsoft stopped producing spam definition updates for the SmartScreen filters in Exchange and
Outlook. The existing SmartScreen spam definitions will be left in place, but their effectiveness will likely degrade over time.
For more information, see Deprecating support for SmartScreen in Outlook and Exchange.

The Content Filter agent evaluates inbound email messages and assesses the probability that an inbound message
is legitimate or spam. Unlike many other filtering technologies, the Content Filter agent uses characteristics from a
statistically significant sample of email messages. The inclusion of legitimate messages in this sample reduces the
chance of mistakes. Because the Content Filter agent recognizes characteristics of legitimate messages and spam,
its accuracy is increased. Updates to the Content Filter agent are available periodically through Microsoft Update.

Using the Content Filter agent

The Content Filter agent is one of several anti-spam agents in Exchange. When you configure anti-spam agents on
an Exchange server, the agents act on messages cumulatively to reduce the amount of spam that enters the
organization. For more information about how to plan and deploy anti-spam agents, see Anti-spam protection.
The Content Filter agent assigns a spam confidence level (SCL ) rating to each message. The SCL rating is a
number between 0 and 9. A higher SCL rating indicates that a message is more likely to be spam.
You can configure the Content Filter agent to take the following actions on messages according to their SCL
rating:
Delete message
Reject message
Quarantine message
For example, you may determine that messages that have an SCL rating of 7 or higher must be deleted, messages
that have an SCL rating of 6 must be rejected, and messages that have an SCL rating of 5 must be quarantined.
You can adjust the SCL threshold behavior by assigning different SCL ratings to each of these actions. For more
information about how to adjust the SCL threshold to suit your organization's requirements and about per-
recipient SCL thresholds, see Spam Confidence Level Threshold.

NOTE
Messages that are over 11 MB aren't scanned by the Intelligent Message Filter. Instead, they pass through the Content Filter
without being scanned.

Allow phrases and Block phrases

You can customize how the Content Filter agent assigns SCL values by configuring custom words. Custom words
are individual words or phrases that the Content Filter agent uses to apply appropriate filter processing. You
configure approved words or phrases with Allow phrases and unapproved words or phrases with Block phrases.
When the Content Filter agent detects a preconfigured Allow phrase in an inbound message, the Content Filter
agent automatically assigns an SCL value of 0 to the message. Alternatively, when the Content Filter agent detects
a configured Block phrase in an inbound message, the Content Filter agent assigns an SCL rating of 9.
You can enter custom words or phrases in any combination of uppercase and lowercase letters. However, when
the Content Filter agent evaluates message content, it ignores case. The maximum number of custom words or
phrases that can be created is 800.

Outlook Email Postmark validation

The Content Filter agent also includes Microsoft Outlook Email Postmark validation, a computational proof that
Outlook applies to outgoing messages to help recipient messaging systems distinguish legitimate email from junk
email. This feature helps reduce the chance of false positives. In the context of spam filtering, a false positive exists
when a spam filter incorrectly identifies a message from a legitimate sender as spam. When Outlook Email
Postmark validation is enabled, the Content Filter agent parses the inbound message for a computational
postmark header. The presence of a valid, solved computational postmark header in the message indicates that the
client computer that generated the message solved the computational postmark.
Computers don't require significant processing time to solve individual computational postmarks. However,
processing postmarks for many messages may be prohibitive to a malicious sender. Anyone who sends millions of
spam messages is unlikely to invest the processing power that is required to solve computational postmarks for all
outbound spam. If a sender's email contains a valid, solved computational postmark, it's unlikely that the sender is
a malicious sender. In this case, the Content Filter agent would lower the SCL rating. If the postmark validation
feature is enabled and an inbound message either doesn't contain a computational postmark header or the
computational postmark header isn't valid, the Content Filter agent would not change the SCL rating.

Bypassing the recipient, sender, and sender domain

In some organizations, all email to certain aliases must be accepted. This scenario can introduce problems if your
organization is in an industry that manages significant volumes of spam.
For example, a company named Woodgrove Bank has an alias named [email protected] that
provides email-based support to external loan customers. The Exchange administrators configure the Content
Filter agent to set Block phrases that filter out words or phrases that are typically used in spam that is sent by
unscrupulous loan agencies. To prevent potentially legitimate messages from being rejected, the administrators set
exceptions to content filtering by entering a list of SMTP email recipient addresses in the Content Filter agent
configuration.
You can also specify senders and sender domains that you do not want the Content Filter agent to block.

Safelist aggregation
In Exchange 2013, the Content Filter agent uses the Outlook Safe Senders Lists, Blocked Sender List, Safe
Recipients Lists, and trusted contacts from Outlook to optimize spam filtering. Safelist aggregation is a set of anti-
spam functionality that is shared across Outlook and Exchange. As its name suggests, this functionality collects
data from the anti-spam safe lists that Outlook users configure and makes this data available to the anti-spam
agents on the Exchange server. Email messages that Outlook users receive from contacts that those users have
added to their Outlook Safe Recipients List, Safe Senders List, or trusted contacts list are identified by the Content
Filter agent as safe. The Sender Filter agent also performs per-recipient sender filtering using the Blocked Senders
list that users configure. For more information, see Safelist Aggregation.

Configuring the Content Filter agent

You configure the Content Filter agent by using the Exchange Management Shell.
 IMPORTANT
Configuration changes that you make to the Content Filter agent in the Exchange Management Shell are only made on the
local computer. If you have the Content Filter agent running on multiple Exchange servers in your organization, you must
make Content Filter configuration changes to each computer.

The Content Filter agent depends on updates to determine whether a message can be delivered with confidence
that it isn't spam. These updates contain data about phishing Web sites, Microsoft SmartScreen spam heuristics,
and other Intelligent Message Filter updates. Content filter updates generally contain about 6 MB of data that's
useful for longer periods of time than other anti-spam update data.
Content filter updates are available from Microsoft Update. The content filter update data is updated and available
for download every two weeks.
For more information about how to configure content filtering, see Manage content filtering.
 Manage content filtering
6/6/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Content filtering is provided by the Content Filter agent. The Content Filter agent filters all messages that come
through all Receive connectors on the Exchange server. Only messages that come from non-authenticated sources
are filtered.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam feature" entry in the Anti-spam and anti-malware permissions
topic.
You can only use the Shell to perform this procedure.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable content filtering

To disable content filtering, run the following command:

Set-ContentFilterConfig -Enabled $false

To enable content filtering, run the following command:

Set-ContentFilterConfig -Enabled $true

NOTE
When you disable content filtering, the underlying Content Filter agent is still enabled. To disable the Content Filter agent,
run the command: Disable-TransportAgent "Content Filter Agent" .

How do you know this worked?

To verify that you have successfully enabled or disabled content filtering, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List Enabled

2. Verify the value of the Enabled property that's displayed.

Use the Shell to enable or disable content filtering for external

messages
By default, content filtering functionality is enabled for external messages.
To disable content filtering for external messages, run the following command:

Set-ContentFilterConfig -ExternalMailEnabled $false

To enable content filtering for external messages, run the following command:

Set-ContentFilterConfig -ExternalMailEnabled $true

How do you know this worked?

To verify that you have successfully enabled or disabled content filtering for external messages, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List ExternalMailEnabled

2. Verify the value of the ExternalMailEnabled property that's displayed.

Use the Shell to enable or disable content filtering for internal

messages
As a best practice, you should not filter messages from trusted partners or from inside your organization. When
you run anti-spam filters, there's always a chance that the filters will detect false positives. To reduce the chance
that filters will mishandle legitimate email messages, you should enable anti-spam agents to run only on
messages from potentially untrusted and unknown sources.
To enable content filtering for internal messages, run the following command:

Set-ContentFilterConfig -InternalMailEnabled $true

To disable content filtering for internal messages, run the following command:

Set-ContentFilterConfig -InternalMailEnabled $false

How do you know this worked?

To verify that you have successfully enabled or disabled content filtering for internal messages, do the following:
1. Run the following command:
 Get-ContentFilterConfig | Format-List InternalMailEnabled

2. Verify the value of the InternalMailEnabled property that's displayed.

Use the Shell to configure recipient and sender exceptions

To replace the existing values, run the following command:

Set-ContentFilterConfig -BypassedRecipients <recipient1,recipient2...> -BypassedSenders <sender1,sender2...> -

BypassedSenderDomains <domain1,domain2...>

This example configures the following exceptions in content filtering:

The recipients [email protected] and [email protected] aren't checked by content filtering.
The senders [email protected] and [email protected] aren't checked by content filtering.
All senders in the domain nwtraders.com and all subdomains aren't checked by content filtering.

Set-ContentFilterConfig -BypassedRecipients [email protected],[email protected] -BypassedSenders

[email protected],[email protected] -BypassedSenderDomains *.nwtraders.com

To add or remove entries without modifying any existing values, run the following command:

Set-ContentFilterConfig -BypassedRecipients @{Add="<recipient1>","<recipient2>"...; Remove="<recipient1>","

<recipient2>"...} -BypassedSenders @{Add="<sender1>","<sender2>"...; Remove="<sender1>","<sender2>"...} -
BypassedSenderDomains @{Add="<domain1>","<domain2>"...; Remove="<domain1>","<domain2>"...}

This example configures the following exceptions in content filtering:

Add [email protected] and [email protected] to the list of existing recipients who aren't checked by
content filtering.
Add [email protected] and [email protected] to the list of existing senders who aren't checked by
content filtering.
Add blueyonderairlines.com to the list of existing domains whose senders aren't checked by content
filtering.
Remove the domain woodgrovebank.com and all subdomains from the list of existing domains whose
senders aren't checked by content filtering.

Set-ContentFilterConfig -BypassedRecipients @{Add="[email protected]","[email protected]"} -BypassedSenders

@{Add="[email protected]","[email protected]"} -BypassedSenderDomains @{Add="blueyonderairlines.com";
Remove="*.woodgrovebank.com"}

How do you know this worked?

To verify that you have successfully configured the recipient and sender exceptions, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List Bypassed*

2. Verify the values displayed match the settings you specified.

Use the Shell to configure allowed and blocked phrases

To add allowed and blocked words and phrases, run the following command:

Add-ContentFilterPhrase -Influence GoodWord -Phrase <Phrase> -Influence BadWord -Phrase <Phrase>

This example allows all messages that contain the phrase "customer feedback".

Add-ContentFilterPhrase -Influence GoodWord -Phrase "customer feedback"

This example blocks all messages that contain the phrase "stock tip".

Add-ContentFilterPhrase -Influence BadWord -Phrase "stock tip"

To remove allowed or blocked phrases, run the following command:

Remove-ContentFilterPhrase -Phrase <Phrase>

This example removes the phrase "stock tip":

Remove-ContentFilterPhrase -Phrase "stock tip"

How do you know this worked?

To verify that you have successfully configured the allowed and block phrases, do the following:
1. Run the following command:

Get-ContentFilterPhrase | Format-List Influence,Phrase

2. Verify the values displayed match the settings you specified.

Use the Shell to configure SCL thresholds

To configure the spam confidence level (SCL ) thresholds and actions, run the following command:

Set-ContentFilterConfig -SCLDeleteEnabled <$true | $false> -SCLDeleteThreshold <Value> -SCLRejectEnabled

<$true | $false> -SCLRejectThreshold <Value> -SCLQuarantineEnabled <$true | $false> -SCLQuarantineThreshold
<Value>

NOTE
The Delete action takes precedence over the Reject action, and the Reject action takes precedence over the Quarantine
action. Therefore, the SCL threshold for the Delete action should be greater than the SCL threshold for the Reject action,
which in turn should be greater than the SCL threshold for the Quarantine action. Only the Reject action is enabled by
default, and it has the SCL threshold value 7.

This example configures the following values for the SCL thresholds:
 The Delete action is enabled and the corresponding SCL threshold is set to 9.
The Reject action is enabled and the corresponding SCL threshold is set to 8.
The Quarantine action is enabled and the corresponding SCL threshold is set to 7.

Set-ContentFilterConfig -SCLDeleteEnabled $true -SCLDeleteThreshold 9 -SCLRejectEnabled $true -

SCLRejectThreshold 8 -SCLQuarantineEnabled $true -SCLQuarantineThreshold 7

How do you know this worked?

To verify that you have successfully configured the SCL thresholds, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List SCL*

2. Verify the values displayed match the settings you specified.

Use the Shell to configure the rejection response

When the Reject action is enabled, you can customize the rejection response that's sent to the message sender.
The rejection response can't exceed 240 characters.
To configure a custom rejection response, run the following command:

Set-ContentFilterConfig -RejectionResponse "<Custom Text>"

This example configures the Content Filter agent to send a customized rejection response.

Set-ContentFilterConfig -RejectionResponse "Your message was rejected because it appears to be SPAM."

How do you know this worked?

To verify that you have successfully configured the rejection response, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List *Reject*

2. Verify the values displayed match the settings you specified.

Use the Shell to enable or disable Outlook Email Postmarking

Outlook Email Postmarking validation is a computational proof that Microsoft Outlook applies to outgoing
messages to help recipient messaging systems distinguish legitimate email from junk email. Postmarking is
available in Outlook 2007 or newer. Postmarking helps reduce false positives. Outlook Email Postmarking is
enabled by default.
To disable Outlook Email Postmarking, run the following command:
 Set-ContentFilterConfig -OutlookEmailPostmarkValidationEnabled $false

To enable Outlook Email Postmarking, run the following command:

Set-ContentFilterConfig -OutlookEmailPostmarkValidationEnabled $true

How do you know this worked?

To verify that you have successfully configured Outlook Email Postmarking, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List OutlookEmailPostmarkValidationEnabled

2. Verify the value displayed matches the setting you specified.

 Safelist Aggregation
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, safelist aggregation refers to anti-spam functionality shared across Microsoft
Outlook and Exchange. This functionality collects data from the anti-spam Safe Recipients Lists, Safe Senders
Lists, Blocked Senders Lists, and contact data that Outlook users configure, and makes this data available to the
Exchange anti-spam agents.
When you enable and correctly configure safelist aggregation, the Content Filter agent passes safe email
messages to the enterprise mailbox without additional processing. Email messages that Outlook users receive
from contacts that those users have added to their Outlook Safe Recipients List or Safe Senders List or have
trusted are identified by the Content Filter agent as safe. An Outlook contact is a person, inside or outside the
user's organization, about whom the user can save several types of information, such as email and street
addresses, telephone and fax numbers, and Web page URLs.
In Exchange 2013, the safelist aggregation process also allows the Sender Filtering agent to block incoming
messages from the per-recipient Block Senders List.
Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by Exchange.
In the context of spam filtering, a false-positive occurs when a spam filter incorrectly identifies a legitimate
message as spam.
For organizations that filter hundreds of thousands of messages from the Internet every day, even a small
percentage of false-positives means that users might not receive many messages that were incorrectly identified
as spam if those messages were quarantined or deleted.
Safelist aggregation is likely the most effective way to reduce false-positives. In Outlook 2010 or newer versions,
users can create Safe Senders Lists. Safe Senders Lists specify a list of domain names and email addresses from
which the Outlook user wants to receive messages. By default, email addresses in Outlook Contacts and in the
Exchange global address list are included in this list. By default, Outlook adds all external contacts to which the
user sends mail to the Safe Senders List.

Information stored in the Outlook user's safelist collection

A safelist collection is the combined data from the user's Safe Senders List, Safe Recipients List, Blocked Senders
List, and external contacts. This data is stored in Outlook and in the Exchange mailbox.
The following types of information are stored in an Outlook user's safelist collection:
Safe senders and safe recipients: The From message header indicates a sender. The To field of the email
message indicates a recipient. Safe senders and safe recipients are represented by full SMTP addresses,
such as [email protected]. Outlook users can add senders and recipients to their safe lists.
Blocked senders: Just like safe senders, users can block unwanted senders by adding them to their
Blocked Senders Lists.
Safe domain: The domain is the part of an SMTP address that follows the @ symbol. For example,
contoso.com is the domain in the [email protected] address. Outlook users can add sending domains
to their safe lists.
 IMPORTANT
By default, Exchange doesn't include the domains during safelist aggregation. However, you can configure safelist
aggregation to include the safe domain data for the anti-spam agents. For more information, see Configure Content
Filtering to Use Safe Domain Data.

External contacts: Two types of external contacts can be included in the safelist aggregation. The first type
of external contact includes contacts to whom Outlook users have sent mail. This class of contact is added
to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk Email settings
in Outlook 2007.
The second type of external contact includes the users' Outlook contacts. Users can add or import these
contacts into Outlook. This class of contact is added to the Safe Senders List only if an Outlook user selects
the corresponding option in the Junk Email Filter settings in Outlook 2010 or Outlook 2007.

How Exchange uses the safelist collection

The safelist collection is stored on the user's Mailbox server. A user can have up to 1,024 unique entries in a
safelist collection. Exchange 2013 has a mailbox assistant, called the Junk Email Options mailbox assistant, which
monitors changes to the safelist collection for your mailboxes. It then replicates these changes to Active Directory,
where the safelist collection is stored on each user object. When the safelist collection is stored on the user object
in Active Directory, the safelist collection is aggregated with the anti-spam functionality of Exchange 2013 and is
optimized for minimized storage and replication. Exchange uses the safelist collection data during content filtering.
If you have a subscribed Edge Transport server in your perimeter network, the Microsoft Exchange EdgeSync
service replicates the safelist collection to the Active Directory Lightweight Directory Services (AD LDS ) instance
on the Edge Transport server.

IMPORTANT
Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection, the content filtering
functionality doesn't act on safe recipient data.

Hashing of safelist collection entries

Safelist collection entries are hashed (SHA-256) one way before they are stored as array sets across three user
object attributes, msExchSafeSenderHash, msExchSafeRecipientHash, and msExchBlockedSendersHash,
as a binary large object. When data is hashed, an output of fixed length is produced, and the output is likely to be
unique. For hashing of safelist collection entries, a 4-byte hash is produced. When a message is received from the
Internet, Exchange hashes the sender address and compares it to the hashes stored on behalf of the Outlook user
to whom the message was sent. If the sender matches the safe senders hash, the message bypasses content
filtering. If the sender matches the blocked senders hash, the message is blocked.
One-way hashing of safelist collection entries performs the following important functions:
Minimizes storage and replication space: Most of the time, hashing reduces the size of the data hashed.
Therefore, saving and transmitting a hashed version of a safelist collection entry conserves storage space
and replication time. For example, a user who has 200 entries in his or her safelist collection would create
about 800 bytes of hashed data stored and replicated in Active Directory.
Renders user safelist collections unusable by malicious users: Because one-way hash values are
impossible to reverse-engineer into the original SMTP address or domain, the safelist collections don't yield
usable email addresses for malicious users who might compromise an Exchange server.
Enabling safelist aggregation
Safelist aggregation is enabled by default in Exchange 2013. Unlike in Exchange Server 2007, you don't need to
manually run the Update-SafeList cmdlet to hash and write the safelist collection data to Active Directory. In
Exchange 2013, the safelist collection data is written to Active Directory by the Junk Email Options mailbox
assistant.
To make the safelist aggregation data in Active Directory available to Edge Transport servers in the perimeter
network, you need to install and configure the Microsoft Exchange EdgeSync service so that the safelist
aggregation data is replicated to AD LDS.
You can still manually run safelist aggregation by using the UpdateSafelist cmdlet. However, you need to be
mindful of the network and replication traffic that may be generated when you run this command. Running
Update-Safelist on multiple mailboxes where safelists are heavily used may generate a significant amount of
traffic. We recommend that if you run the command on multiple mailboxes, you should run the command during
off-peak, non-business hours.
The Update-SafeList cmdlet reads the safelist collection from the user's mailbox, hashes each entry, sorts the
entries for easy search, and then converts the hash to a binary attribute. Finally, the Update-SafeList cmdlet
compares the binary attribute that was created to any value stored on the attribute. If the two values are identical,
the Update-SafeList cmdlet doesn't update the user attribute value with the safelist aggregation data. If the two
attribute values are different, the Update-SafeList cmdlet updates the safelist aggregation value.
 Manage safelist aggregation
6/6/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Safelist aggregation refers to anti-spam functionality that's shared from Microsoft Outlook to Microsoft Exchange
Server 2013. This functionality collects data from the Safe Recipients Lists, Safe Senders Lists, Blocked Senders
Lists, and contact data that Outlook users configure, and makes this data available to the Exchange anti-spam
agents. Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by the
Exchange servers where the anti-spam agents are running.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Recipient Provisioning Permissions" section in the Recipients Permissions
topic, and the "Anti-spam features" section in the Anti-spam and anti-malware permissions topic.
You can only use the Shell to perform this procedure.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you only
enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior anti-
spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
Be mindful of the network and replication traffic that may be generated when you run the Update-SafeList
cmdlet. Running the command on multiple mailboxes where safelists are heavily used may generate a
significant amount of traffic. We recommend that if you run the command on multiple mailboxes, you
should run the command during off-peak, non-business hours.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure the mailbox safelist collection limits

You can configure the maximum number of safe senders and blocked senders a user can configure. By default,
users can configure up to 5,000 safe senders and 500 blocked senders.
To configure the maximum number of safe senders and blocked senders, run the following command:

Set-Mailbox <MailboxIdentity> -MaxSafeSenders <Integer> -MaxBlockedSenders <Integer>

This example configures the mailbox [email protected] to have a maximum of 2,000 safe senders and 200
blocked senders.
 Set-Mailbox [email protected] -MaxSafeSenders 2000 -MaxBlockedSenders 200

How do you know this worked?

To verify that you have successfully configured the mailbox safelist collection limits, do the following:
1. Run the following command:

Get-Mailbox <Identity> | Format-List Name,Max*Senders

2. Verify the values displayed match the values you configured.

Use the Shell to run the Update-Safelist command

In Exchange 2013, safelist aggregation is done automatically, so you don't need to schedule or manually run the
Update-Safelist cmdlet. However, you may want to occasionally run this cmdlet to test safelist aggregation.
This example writes the safe senders list for the mailbox [email protected] to Active Directory.

Update-Safelist [email protected] -Type SafeSenders

For detailed syntax and parameter information, see Update-SafeList.

How do you know this worked?

To verify that you have successfully configured safelist aggregation, perform the following steps:

Step 1: Use the Shell to verify the Content Filter agent is enabled on
the Exchange server
1. Run the following command:

Get-ContentFilterConfig | Format-List Enabled

2. If the output shows the Enabled parameter to be True , content filtering is enabled. If it isn't, run the
following command to enable content filtering and the Content Filter agent on the Exchange server:

Set-ContentFilterConfig -Enabled $true

Step 2: (Optional) Use ADSI Edit to verify replication of the safelist

aggregation data to Edge Transport servers
This step is only required if you run the Content Filter agent on an Edge Transport server in your perimeter
network.
You can view the user objects in the Active Lightweight Directory Services (AD LDS ) instance on the Edge
Transport server to verify that the safelist collection data is updated for the user objects and that the Microsoft
Exchange EdgeSync service has replicated the data to the AD LDS instance.
There are three safelist collection attributes for each user object:
 msExchSafeRecipientsHash: This attribute stores the hash of the Safe Recipients List collection for the
user.
msExchSafeSendersHash: This attribute stores the hash of the Safe Senders List collection for the user.
msExchBlockedSendersHash: This attribute stores the hash of the Blocked Senders List collection for the
user.
If a hexadecimal string, such as 0xac 0xbd 0x03 0xca , is present on the attribute, the user object was updated. If the
attribute has a value of <Not Set> , the attribute wasn't updated.
You can search for and view the attributes by using the AD LDS Active Directory Service Interfaces (ADSI) Edit
snap-in.

Step 3: Send a test message to verify safelist aggregation is working

To test whether safelist aggregation is functioning, you need to send yourself a message from a safe sender that
would otherwise be blocked by content filtering. If safelist aggregation is functioning, the message should arrive in
your Inbox.
1. Find an existing external email account to use, or create an email account at a free web-based email provider
like Microsoft Hotmail.
2. Add that account to your Safe Senders List in Microsoft Outlook.
3. Use the Update-SafeList cmdlet to have the safelist collection from that mailbox copied to Active
Directory.
4. Optional: if you are running the Content Filter agent on an Edge Transport server in the perimeter network,
run the Start-EdgeSynchronization cmdlet to force EdgeSync replication.
5. Add a specific word as a blocked phrase to your content filtering configuration. For detailed steps, see
Manage content filtering.
6. From the external email account in step 1, send a message to your Exchange mailbox that includes the
blocked phrase you configured in step 5.
If the message is successfully delivered to your Inbox, safelist aggregation is working correctly.
 Configure Content Filtering to Use Safe Domain Data
6/4/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Safe domain data is an entire domain (for example, @contoso.com) that's stored in a user's Safe Senders List. By
default, the Content Filter agent doesn't use safe domain data to identify senders that are allowed to bypass
content filtering.
This default setting helps reduce the amount of spam that's delivered into your organization. For example, a user
might add the domain of a large email provider to their Safe Senders List. If this domain is frequently used or
spoofed by spammers, and if content filtering is configured to use safe domain data to mark the messages as safe,
messages from any sender in that domain would be delivered to recipients in your organization.
We recommend that you don't modify the default setting in most cases. However, you can configure users' safe
domain data to be stored in Active Directory and used by content filtering to mark messages as safe. To do this,
you need to modify the MSExchangeMailboxAssistants.exe.config XML application configuration file that's
associated with the Microsoft Exchange Mailbox Assistants service, as detailed later in this topic. When you make
this configuration change, the safe domain data is hashed and stored in each user's msExchSafeSenderHash
user object attribute in Active Directory as part of safelist aggregation. The Content Filter agent can then use the
safe domain data to mark messages from senders in those domains as safe. For more information about safelist
aggregation, see Safelist Aggregation.

What do you need to know before you begin?

Estimated time to complete: 10 minutes
Exchange permissions don't apply to the procedures in this topic. These procedures are performed in the
operating system of the Exchange Server.
Changes you save to the MSExchangeMailboxAssistants.exe.config file are applied after you restart the
Microsoft Exchange Mailbox Assistants service.
Any customized per-server settings you make in Exchange XML application configuration files, for example,
web.config files on Client Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be
overwritten when you install an Exchange Cumulative Update (CU ). Make sure that you save this
information so you can easily re-configure your server after the install. You must re-configure these settings
after you install an Exchange CU.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use a command prompt to configure content filtering to use safe

domain data
1. In the Command Prompt window, open the MSExchangeMailboxAssistants.exe.config file in Notepad by
running the following command:
 Notepad %ExchangeInstallPath%Bin\MSExchangeMailboxAssistants.exe.config

2. Locate the </appsettings> key at the end of the file, and paste the following key before the </appsettings>
key:

<add key="IncludeSafeDomains" value="true" />

3. When you are finished, save and close the MSExchangeMailboxAssistants.exe.config file.
4. Restart the Microsoft Exchange Mailbox Assistants service by running the following command:

net stop MSExchangeMailboxAssistants && net start MSExchangeMailboxAssistants

How do you know this worked?

To verify that you have successfully configured content filtering to use safe domain data, do the following:
1. Verify that adding a domain to a user's Safe Senders List in Outlook updates the user's
msExchSafeSenderHash attribute in Active Directory. To do this, view the attribute in ADSIEdit.exe or
LDP.exe, open the user's mailbox in Outlook, add a domain to the Safe Senders List, run the command
Update-Safelist <username> , and verify that the original and current values of msExchSafeSenderHash
are different.
2. After you've verified the safe domain data is stored in Active Directory, send a test message from an
external sender in that domain to a user in your organization. Verify the message is marked as safe by
examining the anti-spam header fields in the message header.
 Spam Confidence Level Threshold
5/28/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

NOTE
On November 1, 2016, Microsoft stopped producing spam definition updates for the SmartScreen filters in Exchange and
Outlook. The existing SmartScreen spam definitions will be left in place, but their effectiveness will likely degrade over time.
For more information, see Deprecating support for SmartScreen in Outlook and Exchange.

In Microsoft Exchange Server 2013, you can define specific actions according to spam confidence level (SCL )
thresholds. For example, you can define different thresholds for rejecting, deleting, or quarantining messages on
an Exchange server that's running the Content Filter agent.
The combination of this SCL threshold configuration in the Content Filter agent and the SCL Junk Email folder
configuration on the user's mailbox helps you implement a more comprehensive and precise anti-spam strategy.
This more precise and detailed SCL threshold adjustment functionality in Exchange 2013 can help you reduce the
overall cost of deploying and maintaining an anti-spam solution across your Exchange organization.
The Content Filter agent assigns an SCL rating to messages late in the anti-spam cycle, after other anti-spam
agents have processed any inbound messages. Many of the other anti-spam agents that process inbound
messages before they're processed by the Content Filter agent are deterministic in how they act on a message. For
example, on an Edge Transport server the Connection Filter agent rejects any message sent from an IP address on
a real-time block list. The Sender Filter agent and Recipient Filter agent process messages in a similarly
deterministic manner.
In Exchange 2013, these deterministic anti-spam agents process messages first and therefore greatly reduce the
number of messages that must be processed by the Content Filter agent. For more information about the order in
which anti-spam agents process messages, see Anti-spam protection.
Because content filtering isn't an exact, deterministic process, the ability to adjust the action that the Content Filter
agent performs on different SCL values is important. By carefully adjusting the SCL threshold configuration, you
can minimize the following:
Size of the spam quarantine storage
Number of legitimate email messages mistakenly quarantined
Number of legitimate email messages that reach the Microsoft Outlook user's Junk Email folder
Number of offensive spam email messages that reach the Outlook user's Inbox or Junk Email folder
Number of spam email messages that reach the Outlook user's Inbox

SCL threshold actions

By adjusting SCL threshold actions, you can escalate the content filtering action taken on messages that have a
greater risk of being spam. To understand this functionality, it's helpful to understand the different SCL threshold
actions and how they're implemented:
SCL delete threshold: When the SCL value for a specific message is equal to or higher than the SCL
delete threshold, the Content Filter agent deletes the message. There's no protocol-level communication
 that tells the sending system or sender that the message was deleted. If the SCL value for a message is
lower than the SCL delete threshold value, the Content Filter agent doesn't delete the message. Instead, the
Content Filter agent compares the SCL value to the SCL reject threshold.
SCL reject threshold: When the SCL value for a specific message is equal to or higher than the SCL reject
threshold, the Content Filter agent deletes the message and sends a rejection response to the sending
system. You can customize the rejection response. In some cases, a non-delivery report (NDR ) is sent to the
original sender of the message. If the SCL value for a message is lower than the SCL delete and SCL reject
threshold values, the Content Filter agent doesn't delete or reject the message. Instead, the Content Filter
agent compares the SCL value to the SCL quarantine threshold.
SCL quarantine threshold: When the SCL value for a specific message is equal to or higher than the SCL
quarantine threshold, the Content Filter agent sends the message to a quarantine mailbox. Email
administrators must periodically review the quarantine mailbox. If the SCL value for a message is lower
than the SCL delete, reject, and quarantine threshold values, the Content Filter agent doesn't delete, reject,
or quarantine the message. Instead, the Content Filter agent sends the message to the appropriate Mailbox
server, where the per-recipient SCL Junk Email folder threshold value of the message is evaluated.
SCL Junk Email folder threshold: If the SCL value for a specific message exceeds the SCL Junk Email
folder threshold, the message is delivered to the user's Junk Email folder. If the SCL value for a message is
lower than the SCL delete, reject, quarantine, and Junk Email folder threshold values, the message is
delivered to the user's Inbox.
The Content Filter agent and the Junk Email folder process the SCL threshold value differently. The Content Filter
agent takes action on the SCL threshold value that you configure. The Junk Email folder takes action on the SCL
threshold value that you configure plus 1. For example, if you configure the Delete action to an SCL of 8 on the
Content Filter agent, all messages with an SCL of 8 or greater are deleted. However, if you configure the Junk
Email folder with an SCL threshold of 4, all messages with an SCL of 5 or greater are moved to the Junk Email
folder.
For example, if you set the SCL delete threshold to 8, the SCL reject threshold to 7, the SCL quarantine threshold
to 6, and the SCL Junk Email folder threshold to 4, all messages with an SCL of 5 or lower are delivered to the
user's mailbox. Messages with an SCL value of 5 are put in the user's Junk Email folder. Messages with an SCL
value of 4 or lower are put in the user's Inbox.
You can configure the SCL delete, reject, quarantine, and Junk Email folder settings in the following locations:
On the Content Filter agent configuration (per-transport server SCL configuration): You use the
Set-ContentFilterConfig cmdlet to enable or disable and set the SCL delete, reject, and quarantine
thresholds on the Exchange server where you're running the Content Filter agent. Over time, as you
analyze the spam functionality and metrics provided by the anti-spam logging and reporting features, you
can make additional adjustments to these SCL threshold configurations as needed.
The SCL parameters that are available on the Set-ContentFilterConfig cmdlet are described in the
following table.

PARAMETER DESCRIPTION

SCLDeleteEnabled This parameter enables or disables deleting a message

without a non-delivery report (NDR) when the SCL
value of the message is greater than or equal to the
value specified by the SCLDeleteThreshold parameter.
Valid input for this parameter is $true or $false .
 PARAMETER DESCRIPTION

SCLDeleteThreshold Valid input for this parameter is an integer from 0

through 9 inclusive. The value of this parameter
should be greater than the other SCL threshold
parameters. This parameter is only meaningful if the
value of the SCLDeleteEnabled parameter is $true .

SCLRejectEnabled This parameter enables or disables rejecting a

message with an NDR when the SCL value of the
message is greater than or equal to the value
specified by the SCLRejectThreshold parameter. Valid
input for this parameter is $true or $false .

SCLRejectThreshold Valid input for this parameter is an integer from 0

through 9 inclusive. The value of this parameter
should be less than the SCLDeleteThreshold
parameter, but greater than the other SCL threshold
parameters This parameter is only meaningful if the
value of the SCLRejectEnabled parameter is $true .

SCLQuarantineEnabled This parameter enables or disables sending a message

to the spam quarantine mailbox when the SCL value
of the message is greater than or equal to the value
specified by the SCLQuarantineThreshold parameter.
Valid input for this parameter is $true or $false .
For more information about the spam quarantine
mailbox, see Spam quarantine.

SCLQuarantineThreshold Valid input for this parameter is an integer from 0

through 9 inclusive. The value of this parameter
should be less than the SCLRejectThreshold
parameter, but greater than the SCLJunkThreshold
parameter on the Set-OrganizationConfig or Set-
Mailbox cmdlets. This parameter is only meaningful if
the value of the SCLQuarantineThreshold parameter
is $true .

On the organization configuration settings (organization-wide SCL configuration): You use the
Set-OrganizationConfig cmdlet to set the SCL Junk Email folder threshold for all mailboxes in the
organization.
The SCL parameter that's available on the Set-OrganizationConfig cmdlet is described in the following
table. For an example of using SCLJunkThreshold, see Configure Anti-Spam Settings on Mailboxes.

PARAMETER DESCRIPTION
 PARAMETER DESCRIPTION

SCLJunkThreshold This parameter specifies the SCL value that a message

must exceed for the message to be moved into the
Junk Email folder of the recipient's mailbox. Valid input
for this parameter is an integer from 0 through 9
inclusive. The value of this parameter should be less
than the other SCL threshold parameters. For
example, if you specify the value 4, then messages
with an SCL value of 5 or higher are moved into the
user's Junk Email folder.

On user mailboxes (per-recipient SCL configuration): You use the Set-Mailbox cmdlet to enable or
disable and set per-recipient SCL delete, reject, quarantine, and Junk Email folder thresholds on individual
mailboxes. You can only use the Set-Mailbox cmdlet to enable or disable the SCL Junk Email folder
threshold on individual mailboxes. The per-recipient SCL delete, reject, and quarantine thresholds are
stored in Active Directory and are replicated to subscribed Edge Transport servers by the Microsoft
Exchange EdgeSync service. The per-recipient SCL threshold configurations are used by the Content Filter
agent even if you've set per-transport server SCL configurations. Therefore, if you've set per-recipient SCL
thresholds, the Content Filter agent uses the per-recipient SCL thresholds for specific users instead of the
SCL configuration on the Content Filter agent. For examples, see Configure Anti-Spam Settings on
Mailboxes.

NOTE
Per-recipient SCL thresholds are not enforced on mail received through distribution groups.

The same SCL parameters are available on the Set-Mailbox cmdlet that are available on the Set-
ContentFilterConfig and Set-OrganizationConfig cmdlets:
SCLDeleteEnabled
SCLDeleteThreshold
SCLRejectEnabled
SCLRejectThreshold
SCLQuarantineEnabled
SCLQuarantineThreshold
SCLJunkThreshold
However, all the SCL parameters on the Set-Mailbox cmdlet also accept the value $null . If an SCL
setting on a mailbox is blank ( $null ), the corresponding Content Filter agent setting or organization
configuration setting is applied to the mailbox. If an SCL setting on a mailbox has the value of $true or
$false , the setting on the mailbox overrides the corresponding organization-wide setting on the Content
Filter agent or the organization configuration.
The SCL parameter that's only available on the Set-Mailbox cmdlet is described in the following table.

PARAMETER DESCRIPTION
 PARAMETER DESCRIPTION

SCLJunkEnabled This parameter enables or disables delivering a

message to the user's Junk Email folder when the SCL
value of the message is greater than the value
specified by the SCLQuarantineThreshold parameter.
Valid input for this parameter is $true , $false , or
$null .

Note that junk email filtering is enabled by default for

all user mailboxes in the organization. By default, the
Enabled parameter is set to the value $true on the
Set-MailboxJunkEmailConfiguration cmdlet for all
user mailboxes.

For more information about configuring the SCL thresholds on a mailbox, see Configure Anti-Spam
Settings on Mailboxes.

Monitoring the SCL thresholds

You can use several built-in scripts located in the %ExchangeInstallPath%Scripts folder, such as get-
AntispamSCLHistogram.ps1, for gathering filtering result data. If the data indicates that you need to make
immediate adjustments, reconfigure the SCL thresholds. Otherwise, collect data and analyze the spam reporting
to determine whether adjustments are required.
 Configure Anti-Spam Settings on Mailboxes
6/7/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can configure specific anti-spam settings on individual mailboxes that are different than the anti-spam
settings that are applied to the rest of the mailboxes in your Exchange organization. When you configure an anti-
spam setting on a mailbox, that setting overrides the corresponding organization-wide content filtering or
organization configuration anti-spam setting.

NOTE
On November 1, 2016, Microsoft stopped producing spam definition updates for the SmartScreen filters in Exchange and
Outlook. The existing SmartScreen spam definitions will be left in place, but their effectiveness will likely degrade over time.
For more information, see Deprecating support for SmartScreen in Outlook and Exchange.

What do you need to know before you begin?

Estimated time to complete each procedure: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
topic, and the "Anti-spam" entry in the Recipients Permissions topic.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
You can only use the Shell to perform this procedure.
The Junk Email Folder SCL threshold value behaves differently than the SCL delete, reject, and quarantine
values. For more information, see Spam Confidence Level Threshold.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure anti-spam features on a single mailbox

To configure the anti-spam settings on a single mailbox, use the following syntax.

Set-Mailbox <MailboxIdentity> -AntispamBypassEnabled <$true | $false> -RequireSenderAuthenticationEnabled

<$true | $false> -SCLDeleteEnabled <$true | $false | $null> -SCLDeleteThreshold <0-9 | $null> -SCLJunkEnabled
<$true | $false | $null > -SCLJunkThreshold <0-9 | $null> -SCLQuarantineEnabled <$true | $false | $null > -
SCLQuarantineThreshold <0-9 | $null> -SCLRejectEnabled <$true | $false | $null > -SCLRejectThreshold <0-9 |
$null>
This example configures the mailbox of a user named Jeff Phillips to bypass all the anti-spam filters and to have
messages that meet or exceed a Junk Email folder SCL threshold of 5 delivered to his Junk Email folder in
Microsoft Outlook.

Set-Mailbox "Jeff Phillips" -AntispamBypassEnabled $true -SCLJunkEnabled $true -SCLJunkThreshold 4

How do you know this worked?

To verify that you have successfully configured the anti-spam features on a single mailbox, do the following:
1. Run the following command:

Get-Mailbox <MailboxIdentity> | Format-List SCL*,Bypass*,*SenderAuth*

2. Verify the value displayed is the value you configured.

Use the Shell to configure anti-spam features on multiple mailboxes

To configure all the anti-spam settings on multiple mailboxes, use the following syntax.

Get-Mailbox [<Filter>]| Set-Mailbox <Anti-Spam Settings>

This example enables the SCL quarantine threshold with a value of 7 on all mailboxes in the Users container in the
Contoso.com domain.

Get-Mailbox -OrganizationalUnit Contoso.com/Users | Set-Mailbox -SCLQuarantineEnabled $true -

SCLQuarantineThreshold 7

How do you know this worked?

To verify that you have successfully configured the anti-spam features on multiple mailboxes, do the following:
1. Run the following command:

Get-Mailbox [<Filter>] | Format-List Name,SCL*,*SenderAuth*

2. Verify the values displayed are the values you configured.

Use the Shell to configure the junk email threshold for all mailboxes in
your organization
Run the following command:

Set-OrganizationConfig -SCLJunkThreshold <Integer>

This example sets the organization's junk email threshold to 5.

Set-OrganizationConfig -SCLJunkThreshold 5
How do you know this worked?
To verify that you have successfully configured the junk email threshold for all mailboxes in your organization, do
the following:
1. Run the following command:

Get-OrganizationConfig | Format-List SCLJunkThreshold

2. Verify the value displayed is the value you configured.

 Sender reputation and the Protocol Analysis agent
6/14/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sender reputation is part of the Exchange anti-spam functionality that blocks messages according to many
characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action,
if any, to take on an inbound message. The Protocol Analysis agent is the underlying agent for sender reputation
functionality.
When you configure anti-spam agents on an Exchange server, the agents act on messages cumulatively to reduce
the number of unsolicited messages that enter the organization.

Calculation of the sender reputation level

A sender reputation level (SRL ) is calculated from the following statistics:
HELO/EHLO analysis: The HELO and EHLO SMTP commands are intended to provide the domain name,
such as Contoso.com, or IP address of the sending SMTP server to the receiving SMTP server. Malicious
users, or spammers, frequently forge the HELO/EHLO statement in various ways. For example, they type an
IP address that doesn't match the IP address from which the connection originated. Spammers also put
domains that are known to be locally supported at the receiving server in the HELO statement in an
attempt to appear as if the domains are in the organization. In other cases, spammers change the domain
that's passed in the HELO statement. The typical behavior of a legitimate user may be to use a different, but
relatively constant, set of domains in their HELO statements.
Therefore, analysis of the HELO/EHLO statement on a per-sender basis may indicate that the sender is
likely to be a spammer. For example, a sender that provides many different unique HELO/EHLO statements
in a specific time period is more likely to be a spammer. Senders who consistently provide an IP address in
the HELO statement that doesn't match the originating IP address as determined by the Connection Filter
agent are also more likely to be spammers. Remote senders who consistently provide a local domain name
in the HELO statement that's in the same organization as the Exchange server are also more likely to be
spammers.
Reverse DNS lookup: Sender reputation also verifies that the originating IP address from which the
sender transmitted the message matches the registered domain name that the sender submits in the HELO
or EHLO SMTP command.
Sender reputation performs a reverse DNS query by submitting the originating IP address to DNS. The
result that's returned by DNS is the domain name that's registered by using the domain naming authority
for that IP address. Sender reputation compares the domain name that's returned by DNS to the domain
name that the sender submitted in the HELO/EHLO SMTP command. If the domain names don't match, the
sender is likely to be a spammer, and the overall SRL rating for the sender is increased.
The Sender ID agent performs a similar task, but the success of the Sender ID agent relies on legitimate
senders to update their DNS infrastructure to identify all the email-sending SMTP servers in their
organization. By performing a reverse DNS lookup, you can help identify potential spammers.
Analysis of SCL ratings on messages from a particular sender: When the Content Filter agent
processes a message, it assigns a spam confidence level (SCL ) rating to the message. The SCL rating is a
number from 0 through 9. A higher SCL rating indicates that a message is more likely to be spam. Data
about each sender and the SCL ratings that their messages yield is persisted for analysis by sender
 reputation. Sender reputation calculates statistics about a sender according to the ratio between all
messages from that sender that had a low SCL rating in the past and all messages from that sender that
had a high SCL rating in the past. Additionally, the number of messages that have a high SCL rating that
the sender has sent in the last day is applied to the overall SRL.
Sender open proxy test: An open proxy is a proxy server that accepts connection requests from anyone
anywhere and forwards the traffic as if it originated from the local hosts. Proxy servers relay TCP traffic
through firewall hosts to provide user applications transparent access across the firewall. Because proxy
protocols are lightweight and independent of user application protocols, proxies can be used by many
different services. Proxies can also be used to share a single Internet connection by multiple hosts. Proxies
are usually set up so that only trusted hosts inside the firewall can cross through the proxies. A legitimate
sender may be an open proxy because of an unintentional misconfiguration or malware.
Open proxies provide an ideal way for malicious users to hide their true identities and launch denial of
service attacks (DoS ) or send spam. As more proxy servers are configured to be open by default, open
proxies have become more common. Additionally, malicious users can use multiple open proxies together
to hide the sender's originating IP address.
When sender reputation performs an open proxy test, it does so by formatting an SMTP request in an
attempt to connect back to the Exchange server from the open proxy. If an SMTP request is received from
the proxy, sender reputation verifies that the proxy is an open proxy and updates the open proxy test
statistic for that sender.
Sender reputation weighs each of these statistics and calculates an SRL for each sender. The SRL is a number
from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. A
value of 0 indicates that the sender isn't likely to be a spammer; a value of 9 indicates that the sender is likely to be
a spammer.
You can configure a block threshold from 0 through 9 at which sender reputation issues a request to the Sender
Filter agent, and, therefore, blocks the sender from sending a message into the organization. When a sender is
blocked, the sender is added to the Blocked Senders list for a configurable period. How blocked messages are
handled depends on the configuration of the Sender Filter agent. The following actions are the options for
handling blocked messages:
Reject
Delete and archive
Accept and mark as a blocked sender
If a sender is included in the IP Block list or Microsoft IP Reputation Service, sender reputation issues an
immediate request to the Sender Filter agent to block the sender. To take advantage of this functionality, you must
enable and configure the Microsoft Exchange Anti-spam Update Service.
By default, sender reputation sets a rating of 0 for senders that haven't been analyzed. After a sender has sent 20
or more messages, sender reputation calculates an SRL that's based on the statistics listed earlier in this topic.

Use of the SRL

Sender reputation acts on messages during two phases of the SMTP session:
At the MAIL FROM: SMTP command: Sender reputation acts on a message only if the message was
blocked or otherwise acted on by the Connection Filter agent, Sender Filter agent, Recipient Filter agent, or
Sender ID agent. In this case, sender reputation retrieves the sender's current SRL rating from the sender
profile that's persisted about that sender on the Exchange server. After this rating is retrieved and evaluated,
the Exchange server configuration dictates the behavior that occurs at a particular connection according to
the block threshold.
 After the "end of data" SMTP command: The end of data transfer (EOD ) SMTP command is given
when all the actual message data is sent. At this point in the SMTP session, many of the anti-spam agents
have processed the message. As a by-product of anti-spam processing, the statistics that sender reputation
relies on are updated. Therefore, sender reputation has the data to calculate or recalculate an SRL rating for
the sender.
For more information, see Manage sender reputation.

Enabling and configuring the detection of open proxy servers

Sender reputation evaluates several sender characteristics to calculate an SRL. Among the characteristics that
sender reputation evaluates are the results of a test for open proxy servers. Frequently, spammers route messages
through open proxy servers on the Internet. By routing spam through open proxy servers, spammers can send
messages that appear to originate from a different server than their own.
When sender reputation calculates an SRL, sender reputation tries to connect to the sender's originating IP
address by using a variety of common proxy protocols, such as SOCKS4, SOCKS5, HTTP, Telnet, Cisco, and
Wingate. Sender reputation formats a protocol-specific request in an attempt to connect back to the Edge
Transport server from the open proxy server by using an SMTP request. If an SMTP request is received from the
proxy server, sender reputation verifies that the proxy server is an open proxy server and adjusts the SRL rating
according to this result. By default, detection of open proxy servers is enabled on sender reputation.
For more information about how to enable and configure detection of open proxy servers, see Manage sender
reputation.

Setting the SRL block threshold

The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or
otherwise malicious user. You must set a threshold for sender blocking by SRL. This SRL block threshold defines
the SRL value that must be exceeded for sender reputation to block a sender. By default, the SRL is set at 7. You
should monitor the effectiveness of the agent at the default level. You may find that you can adjust the value to
meet the needs of your organization. If you set other anti-spam agents aggressively, you may be able to set a
higher SRL threshold for sender reputation than you would if the other anti-spam agents weren't set aggressively.
For more information about how to adjust anti-spam configurations so that they work together to reduce spam,
see Anti-spam protection.
On an Edge Transport server, if the SRL block threshold is exceeded for a particular sender, sender reputation adds
the sender to the IP Block list on the Connection Filter agent. Sometimes, spammers send batches of spam from a
single sender. In this scenario, if sender reputation calculates an SRL that exceeds the SRL block threshold, the
sender is added to the Sender Block List for a configurable duration of time. The default duration is 24 hours. After
24 hours, the sender is removed from the Sender Block List and can send messages again.
When a sender is added to the IP Block list, sender reputation deletes the profile for the sender. Sender reputation
deletes the profile because the blocked sender's existing profile indicates that the sender's SRL exceeds the SRL
block threshold. This would cause the blocked sender to be added to the IP Block list again as soon as the duration
for sender blocking ends.
For more information, see Manage sender reputation.
 Manage sender reputation
6/6/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Sender reputation is provided by the Protocol Analysis agent. Sender reputation blocks messages according to
various characteristics of the sender. Sender reputation relies on persisted data about the sender to determine
what action, if any, to take on an inbound message.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
topic.
You can only use the Shell to perform this procedure.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
The Protocol Analysis agent is the underlying agent for sender reputation functionality. When you disable
sender reputation, the Protocol Analysis agent is still enabled.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable sender reputation

This example disables sender reputation.

Set-SenderReputationConfig -Enabled $false

This example enables sender reputation.

Set-SenderReputationConfig -Enabled $true

How do you know this worked?

To verify that you have successfully enabled or disabled sender reputation, do the following:
1. Verify the Protocol Analysis agent is installed and enabled by running the following command:
 Get-TransportAgent

2. Verify the sender reputation values you configured by running the following command:

Get-SenderReputationConfig | Format-List Enabled,*MailEnabled

Use the Shell to enable or disable sender reputation for internal or

external messages
By default, sender reputation is enabled for external messages, and disabled for internal messages. A message is
considered external if it comes from an unauthenticated connection that's external to your Exchange organization.
A message is considered internal if it comes from authenticated connection, and the sender's domain is configured
as an authoritative domain in your Exchange organization.
To disable sender reputation for external messages, run the following command:

Set-SenderReputationConfig -ExternalMailEnabled $false

To enable sender reputation for external messages, run the following command:

Set-SenderReputationConfig -ExternalMailEnabled $true

To disable sender reputation for internal messages, run the following command:

Set-SenderReputationConfig -InternalMailEnabled $false

To enable sender reputation for internal messages, run the following command:

Set-SenderReputationConfig -InternalMailEnabled $true

How do you know this worked?

To verify that you have successfully enabled or disabled sender reputation for internal and external messages, do
the following:
1. Run the following command:

Get-SenderReputationConfig | Format-List Enabled,*MailEnabled

2. Verify the values displayed match the values you configured.

Use the Shell to configure sender reputation properties

To configure the sender reputation properties, run the following command:

Set-SenderReputationConfig -SrlBlockThreshold <Value> -SenderBlockingPeriod <Hours>

This example sets the sender reputation level (SRL ) block threshold to 6 and configures sender reputation to add
offending senders to the IP Block List for 36 hours:

Set-SenderReputationConfig -SrlBlockThreshold 6 -SenderBlockingPeriod 36

How do you know this worked?

To verify that you have successfully configured the sender reputation properties, do the following:
1. Run the following command:

Get-SenderReputationConfig

2. Verify the values displayed match the values you configured.

Use the Shell to configure outbound access for the detection of open
proxy servers
You may need to perform additional steps to allow sender reputation to traverse any firewalls that are between
the Internet and the Exchange server that's running the Protocol Analysis agent. The following table lists the
outbound ports that are required for sender reputation.

PROTOCOLS PORTS

SOCKS4, SOCKS5 1081, 1080

Wingate, Telnet, Cisco 23

HTTP CONNECT, HTTP POST 6588, 3128, 80

To configure outbound access for the detection of open proxy servers, run the following command:

Set-SenderReputationConfig -ProxyServerName <String> -ProxyServerPort <Port> -ProxyServerType <String>

This example configures sender reputation to use the open proxy server named SERVER01 that uses the HTTP
CONNECT protocol on port 80.

Set-SenderReputationConfig - ProxyServerName SERVER01 -ProxyServerPort 80 -ProxyServerType HttpConnect

How do you know this worked?

To verify that you have successfully configured outbound access for detection of open proxy servers, do the
following:
1. Run the following command:

Get-SenderReputationConfig | Format-List ProxyServer*

2. Verify the values displayed are the values you configured.

 Connection Filtering on Edge Transport Servers
6/11/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

Connection filtering is an anti-spam feature in Microsoft Exchange Server 2013 that allows or blocks email based
on the message source. Connection filtering is performed by the Connection Filtering agent that's available only on
Edge Transport servers. The Connection Filtering agent relies on the IP address of the connecting mail server to
determine what action, if any, to take on an inbound message.
By default, the Connection Filtering agent is the first anti-spam agent to evaluate an inbound message on an Edge
Transport server. The source IP address of the SMTP connection is checked against the allowed and blocked IP
addresses. If the source IP address is specifically allowed, the message is sent to the recipients in your organization
without additional processing by other anti-spam agents. If the source IP address is specifically blocked, the SMTP
connection is dropped. If the source IP address isn't specifically allowed or blocked, the message flows through the
other anti-spam agents on the Edge Transport server.
Connection filtering compares the IP address of the source mail server to the values in the IP Allow list, the IP
Block list, IP Allow list providers, and IP Block list providers. You need to configure at least one of these four IP
address data stores for connection filtering to function. If you don't specify any IP address data, you should disable
the Connection Filtering agent. For more information, see Manage Connection Filtering on Edge Transport
Servers.

IP Block list
The IP Block list contains the IP addresses of email servers that you want to block. You manually maintain the IP
addresses in the IP Block list. You can add individual IP addresses or IP address ranges. You can specify an
expiration time that specifies how long the IP address entry will be blocked. When the expiration time is reached,
the IP address entry in the IP Block list is disabled.
If the Connection Filtering agent finds the source IP address on the IP Block list, the SMTP connection will be
dropped after all the RCPT TO headers (envelope recipients) in the message are processed.
IP addresses can also be automatically added to the IP Block list by the Sender Reputation feature of the Protocol
Analysis agent. For more information, see Sender reputation and the Protocol Analysis agent.

IP Allow list
The IP Allow list contains the IP addresses of email servers that you want to designate as trustworthy sources of
email. Email from mail servers that you specify in the IP Allow list is exempt from processing by other Exchange
anti-spam agents.
You manually maintain the IP addresses in the IP Allow list. You can add individual IP addresses or IP address
ranges. You can specify an expiration time that specifies how long the IP address entry will be allowed. When the
expiration time is reached, the entry in the IP Allow list is disabled.

IP Block List providers

IP Block List providers are frequently referred to as real-time block lists, or RBLs. IP Block List providers compile
lists of mail server IP addresses that send spam. Many IP Block List providers also compile lists of mail server IP
addresses that could be used for spam. Examples include mail servers that are configured for open relay, Internet
service providers (ISPs) that assign dynamic IP addresses, and ISPs that allow SMTP mail server traffic from dial-
up accounts.
When you configure connection filtering to use an IP Block List provider, the Connection Filtering agent compares
the IP address of the connecting mail server to the list of IP addresses at the IP Block List provider. If there's a
match, the message isn't allowed in your organization. You can configure connection filtering to use multiple IP
Block List providers, and you assign different priority values to each provider.
The Connection Filtering agent checks the source IP address at the IP Allow list and the IP Block list. If the IP
address doesn't exist on either list, the Connection Filtering agent queries the IP Block List provider according to
the priority value that you assigned. If the IP address is defined at an IP Block List provider, the Edge Transport
server waits for and processes the RCPT TO header, responds to the sending mail server with an SMTP 550 error,
and closes the connection. The connection isn't immediately dropped so that the connection attempt can be logged,
and because you can specify recipients that are exempt from having messages blocked by any IP Block list
providers.
If the IP address isn't defined at any of the IP Block List providers, the Content Filtering agent hands the message
off to the next transport agent on the Edge Transport server.
For each IP Block List provider, you can customize the SMTP 550 error that's returned to the sender when a
message is blocked. You should identify the IP Block List provider that identified the message source as spam. If a
legitimate source mail server is erroneously identified as a spam source, the administrator can then contact the IP
Block List provider and take the steps necessary to remove the mail server from the IP Block List provider.
IP Block List providers can return different codes to identify why an IP address is defined in their lists. Most IP
Block List providers return bitmask or absolute value data types. Within these data types, the IP Block List provider
can use multiple values to classify the IP address by threat type.
There are issues to consider when using IP Block list providers:
Outages or delays at the IP Block list provider service can cause delays in the processing of messages on
the Edge Transport server. You should always select reliable IP Block list providers.
Source servers that you know to be legitimate can be erroneously identified as spam sources. For example,
the mail server can be unintentionally configured to act as an open relay. You should always select IP Block
list providers that provide clear procedures for evaluation and removal from their services.

Bitmask and absolute value examples

This section shows an example of the status codes returned by most Block List providers. For details about the
status codes that the provider returns, see the documentation from the specific provider.
For bitmask data types, the IP Block List provider service returns a status code of 127.0.0.x, where the integer x is
any one of the values listed in the following table.
Values and status codes for bitmask data types
VALUE STATUS CODE

1 The IP address is on an IP Block list.

2 The SMTP server is configured to act as an open relay.

4 The IP address supports a dial-up IP address.

For absolute value types, the IP Block List provider returns explicit responses that define why the IP address is
defined in their block lists. The following table shows examples of absolute values and the explicit responses.
Values and status codes for absolute value data types
VALUE EXPLICIT RESPONSE

127.0.0.2 The IP address is a direct spam source.

127.0.0.4 The IP address is a bulk mailer.

127.0.0.5 The remote server sending the message is known to

support multistage open relays.

IP Allow List providers

IP Allow List providers are also known as safe lists or white lists. IP Allow List providers are configured just like IP
Block List providers, but the results are the opposite: they define mail server IP addresses that are definitely not
associated with spam activity. If the IP address of the connecting mail server is defined at an IP Allow List provider,
the message is exempt from processing by other Exchange anti-spam agents. For this reason, IP Block List
providers are used much more frequently than IP Allow List providers. Choose your IP Allow List providers
carefully.

Test IP Block List providers and IP Allow List providers

After you configure connection filtering to use an IP Block List provider or an IP Allow List provider, you can run
tests to verify that the providers are working correctly. Most providers provide test IP addresses that you can use
to test their services. When you test a provider, the Connection Filtering agent issues a DNS query that should
result in a specific response from the provider. For more information about how to test IP addresses against an IP
Block List provider service or an IP Allow List provider service, see Manage Connection Filtering on Edge
Transport Servers.

Configure connection filtering on Edge Transport servers that aren't

directly connected to the Internet
You can use connection filtering on Edge Transport servers that don't directly receive email from the Internet. In
this scenario, the Edge Transport server is behind another mail server that receives and processes messages
directly from the Internet. For example, your organization might send email traffic through an anti-spam server,
service, or appliance before the messages reach the Edge Transport server. In this scenario, the Connection
Filtering agent needs to extract the correct source IP address from the message. To do this, the Connection
Filtering agent needs to parse the Received header field values in the message header and compare those values
to the known IP addresses of the mail server that sits between the Edge Transport server and the Internet.
Every mail server that accepts and relays an SMTP message along the delivery path adds its own Received
header field in the message header. The Received header typically contains the domain name and IP address of
the mail server that processed the message.
If the Edge Transport server doesn't accept messages directly from the Internet, you need to use the
InternalSMTPServers parameter on the Set-TransportConfig cmdlet on an Exchange 2013 Mailbox server to
identify the IP address of the mail server that sit between the Edge Transport server and the Internet. The IP
address data is replicated to Edge Transport servers by EdgeSync. When messages are received by the Edge
Transport server, the Connection Filtering agent assumes an IP address in a Received header field that doesn't
match a value specified by the InternalSMTPServers parameter is the source IP address that needs to be checked.
Therefore, you need specify all internal SMTP servers in order for connection filtering to function correctly.
 Manage Connection Filtering on Edge Transport
Servers
6/11/2019 • 17 minutes to read • Edit Online

Applies to: Exchange Server 2013

Connection filtering is an anti-spam feature that's provided by the Connection Filtering agent, which is available
only on Edge Transport servers in Microsoft Exchange 2013. Connection filtering enables the following features:
IP Block list
IP Block List providers
IP Allow list
IP Allow List providers
Each of these features can be enabled or disabled separately.

What do you need to know before you begin?

Estimated time to complete: 15 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
topic.
You can only use the Shell to perform this procedure.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable connection filtering

To completely enable or disable connection filtering, you enable or disable the Connection Filtering agent. The
change takes effect after you restart the Microsoft Exchange Transport service. When you restart the Microsoft
Exchange Transport service on an Edge Transport server, mail flow on the server is temporarily interrupted.
To disable connection filtering, run the following command:

Disable-TransportAgent "Connection Filtering Agent"

To enable connection filtering, run the following command:

Enable-TransportAgent "Connection Filtering Agent"

To make the change take effect, restart the Microsoft Exchange Transport service by running the following
command:

Restart-Service MSExchangeTransport

How do you know this worked?

To verify that you successfully enabled or disabled connection filtering, run the following command and verify that
the value displayed is the value you configured.

Get-TransportAgent "Connection Filtering Agent" | Format-List Enabled

IP Block list procedures

These procedures apply to the IP Block list that you manually configure. They don't apply to IP Block List
providers.
Use the IPBlockListConfig cmdlets to view and configure how connection filtering uses the IP Block list. Use the
IPBlockListEntry cmdlets to view and configure the IP addresses in the IP Block list.

Use the Shell to view the configuration of the IP Block list

To view the configuration of the IP Block list, run the following command:

Get-IPBlockListConfig | Format-List *Enabled,*Response

Use the Shell to enable or disable the IP Block list

To disable the IP Block list, run the following command:

Set-IPBlockListConfig -Enabled $false

To enable the IP Block list, run the following command:

Set-IPBlockListConfig -Enabled $true

How do you know this worked?

To verify that you successfully enabled or disabled the IP Block list, run the following command and verify that the
value displayed is the value you configured.

Get-IPBlockListConfig | Format-List Enabled

Use the Shell to configure the IP Block list

To configure the IP Block list, use the following syntax:
 Set-IPBlockListConfig [-ExternalMailEnabled <$true | $false>] [-InternalMailEnabled <$true | $false> -
MachineEntryRejectionResponse "<Custom response text>"] [-StaticEntryRejectionResponse "<Custom response
text>"]

This example configures the IP Block list with the settings as follows:
The IP Block list filters incoming connections from internal and external mail servers. By default,
connections are filtered from external mail servers only (ExternalMailEnabled is set to $true , and
InternalMailEnabled is set to $false ). Non-authenticated connections and authenticated connections from
external partners are considered external.
The custom response text for connections that were filtered by IP addresses that were automatically added
to the IP Block list by the sender reputation feature of the Protocol Analysis agent is set to the value
"Connection from IP address {0} was rejected by sender reputation."
The custom response text for connections that were filtered by IP addresses that were manually added to
the IP Block list is set to the value "Connection from IP address {0} was rejected by connection filtering."

Set-IPBlockListConfig -InternalMailEnabled $true -MachineEntryRejectionResponse "Connection from IP address

{0} was rejected by sender reputation." -StaticEntryRejectionResponse "Connection from IP address {0} was
rejected by connection filtering."

How do you know this worked?

To verify that you successfully configured the IP Block list, run the following command and verify that the values
displayed are the values you configured.

Get-IPBlockListConfig | Format-List *MailEnabled,*Response

Use the Shell to view IP Block list entries

To view all IP Block list entries, run the following command:

Get-IPBlockListEntry

Note that each IP Block list entry is identified by an integer value. The identity integer is assigned in ascending
order when you add entries to the IP Block list and the IP Allow list.
To view a specific IP Block list entry, use the following syntax:

Get-IPBlockListEntry <-Identity IdentityInteger | -IPAddress IPAddress>

For example, to view the IP Block list entry that contains the IP address 192.168.1.13, run the following command:

Get-IPBlockListEntry -IPAddress 192.168.1.13

 NOTE
When you use the IPAddress parameter, the resulting IP Block list entry can be an individual IP address, an IP address range,
or a Classless InterDomain Routing (CIDR) IP. To use the Identity parameter, you specify the integer value that's assigned to
the IP Block list entry.

Use the Shell to add IP Block list entries

To add IP Block list entries, use the following syntax:

Add-IPBlockListEntry <-IPAddress IPAddress | -IPRange IP range or CIDR IP> [-ExpirationTime <DateTime>] [-

comment "<Descriptive Comment>"]

The following example adds the IP Block list entry for the IP address range 192.168.1.10 through 192.168.1.15
and configures the IP Block list entry to expire on July 4, 2014 at 15:00.

Add-IPBlockListEntry -IPRange 192.168.1.10-192.168.1.15 -ExpirationTime "7/4/2014 15:00"

How do you know this worked?

To verify that you successfully added an IP Block list entry, run the following command and verify that the new IP
Block list entry is displayed.

Get-IPBlockListEntry

Use the Shell to remove IP Block list entries

To remove IP Block list entries, use the following syntax:

Remove-IPBlockListEntry <IdentityInteger>

The following example removes the IP Block list entry that has the Identity value 3.

Remove-IPBlockListEntry 3

The following example removes the IP Block list entry that contains the IP address 192.168.1.12 without using the
Identity integer value. Note that the IP Block list entry can be an individual IP address or an IP address range.

Get-IPBlockListEntry -IPAddress 192.168.1.12 | Remove-IPBlockListEntry

How do you know this worked?

To verify that you successfully removed an IP Block list entry, run the following command and verify that the IP
Block list entry you removed is gone.

Get-IPBlockListEntry
IP Block List provider procedures
These procedures apply to IP Block List providers. They don't apply to the IP Block list.
Use the IPBlockListProvidersConfig cmdlets to view and configure how connection filtering uses all IP Block
List providers. Use the IPBlockListProvider cmdlets to view, configure, and test IP Block List providers.

Use the Shell to view the configuration of all IP Block List providers
To view how connection filtering uses all IP Block List providers, run the following command:

Get-IPBlockListProvidersConfig | Format-List *Enabled,Bypassed*

Use the Shell to enable or disable all IP Block List providers

To disable all IP Block List providers, run the following command:

Set-IPBlockListProvidersConfig -Enabled $false

To enable all IP Block List providers, run the following command:

Set-IPBlockListProvidersConfig -Enabled $true

How do you know this worked?

To verify that you enabled or disabled all IP Block List providers, run the following command an verify that the
value displayed is the value you configured.

Get-IPBlockListProvidersConfig | Format-List Enabled

Use the Shell to configure all IP Block List providers

To configure how connection filtering uses all IP Block List providers, use the following syntax:

Set-IPBlockListProvidersConfig [-BypassedRecipients <recipient1,recipient2...>] [-ExternalMailEnabled <$true |

$false>] [-InternalMailEnabled <$true | $false>]

The following example configures all IP Block List providers with the following settings:
IP Block List providers filter incoming connections from internal and external mail servers. By default,
connections are filtered from external mail servers only (ExternalMailEnabled is set to $true , and
InternalMailEnabled is set to $false ). Non-authenticated connections and authenticated connections from
external partners are considered external.
Messages sent to the internal recipients [email protected] and [email protected] are excluded
from filtering by IP Block List providers. Note that if you want to add recipients to the list without affecting
existing recipients, use the syntax, @{Add="<recipient1>","<recipient2>"...} .

Set-IPBlockListProvidersConfig -BypassedRecipients [email protected],[email protected] -

InternalMailEnabled $true
For more information, see Set-IPBlockListProvidersConfig.

How do you know this worked?

To verify that you successfully configured all IP Block List providers, run the following command and verify that
the values displayed are the values you configured.

Get-IPBlockListProvidersConfig | Format-List *MailEnabled,Bypassed*

Use the Shell to view IP Block List providers

To view the summary list of all the IP Block List providers, run the following command:

Get-IPBlockListProvider

To view the details of a specific provider, use the following syntax:

Get-IPBlockListProvider <IPBlockListProviderIdentity>

The following example show the details of the provider named Contoso IP Block List Provider.

Get-IPBlockListProvider "Contoso IP Block List Provider" | Format-List

Name,Enabled,Priority,LookupDomain,*Match,*Response

Use the Shell to add an IP Block List provider

To add an IP Block List provider, use the following syntax:

Add-IPBlockListProvider -Name "<Descriptive Name>" -LookupDomain <FQDN> [-Priority <Integer>] [-Enabled <$true
| $false>] [-AnyMatch <$true | $false>] [-BitmaskMatch <IPAddress>] [-IPAddressesMatch
<IPAddressStatusCode1,IPAddressStatusCode2...>] [-RejectionResponse "<Custom Text>"]

This example creates an IP Block List provider named "Contoso IP Block List Provider" with the following options:
FQDN to use the provider: rbl.contoso.com
Bitmask code to use from the provider: 127.0.0.1

Add-IPBlockListProvider -Name "Contoso IP Block List Provider" -LookupDomain rbl.contoso.com -BitmaskMatch

127.0.0.1

NOTE
When you add a new IP Block List provider, it's enabled by default (the value of Enabled is $true ), and the priority value is
incremented (the first entry has the Priority value 1).

For more information, see Add-IPBlockListProvider.

How do you know this worked?

To verify that you successfully added an IP Block List provider, run the following command and verify that the new
IP Block List provider is displayed.

Get-IPBlockListProvider

Use the Shell to enable or disable an IP Block List provider

To enable or disable a specific IP Block List provider, use the following syntax:

Set-IPBlockListProvider <IPBlockListProviderIdentity> -Enabled <$true | $false>

The following example disables the provider named Contoso IP Block List Provider.

Set-IPBlockListProvider "Contoso IP Block List Provider" -Enabled $false

The following example enables the provider named Contoso IP Block List Provider.

Set-IPBlockListProvider "Contoso IP Block List Provider" -Enabled $true

How do you know this worked?

To verify that you successfully enabled or disabled an IP Block List provider, run the following command and verify
that the value displayed is the value you configured.

Get-IPBlockListProvider <IPBlockListProviderIdentity> | Format-List Enabled

Use the Shell to configure an IP Block List provider

The configuration options that are available on the Set-IPBlockListProvider cmdlet are identical to those on the
New-IPBlockListProvider cmdlet.
To configure an existing IP Block List provider, use the following syntax:

Set-IPBlockListProvider <IPBlockListProviderIdentity> -Name "<Descriptive Name>" -LookupDomain <FQDN> [-

Priority <Integer>] [-AnyMatch <$true | $false>] [-BitmaskMatch <IPAddress>] [-IPAddressesMatch
<IPAddressStatusCode1,IPAddressStatusCode2...>] [-RejectionResponse "<Custom Text>"]

For example, to add the IP address status code 127.0.0.1 to the list of existing status codes for the provider named
Contoso IP Block List Provider, run the following command:

Set-IPBlockListProvider "Contoso IP Block List Provider" -IPAddressesMatch @{Add="127.0.0.1"}

For more information, see Set-IPBlockListProvider.

How do you know this worked?

To verify that you successfully configured an IP Block List provider, run the following command and verify that the
values displayed are the values you configured.
 Get-IPBlockListProvider <IPBlockListProviderIdentity> | Format-List

Use the Shell to test an IP Block List provider

To test an IP Block List provider, use the following syntax.

Test-IPBlockListProvider <IPBlockListProviderIdentity> -IPAddress <IPAddressToTest>

The following example tests the provider named Contoso IP Block List Provider by looking up the IP address
192.168.1.1.

Test-IPBlockListProvider "Contoso IP Block List Provider" -IPAddress 192.168.1.1

Use the Shell to remove an IP Block List provider

To remove an IP Block List provider, use the following syntax:

Remove-IPBlockListProvider <IPBlockListProviderIdentity>

The following example removes the IP Block List provider named Contoso IP Block List Provider.

Remove-IPBlockListProvider "Contoso IP Block list Provider"

How do you know this worked?

To verify that you successfully removed an IP Block List provider, run the following command and verify that the IP
Block List provider you removed is gone.

Get-IPBlockListProvider

IP Allow list procedures

These procedures apply to the IP Allow list that you manually configure. They don't apply to IP Allow List
providers.
Use the IPAllowListConfig cmdlets to view and configure how connection filtering uses the IP Allow list. Use the
IPAllowListEntry cmdlets to view and configure the IP addresses in the IP Allow list.

Use the Shell to view the configuration of the IP Allow list

To view the configuration of the IP Allow list, run the following command.

Get-IPAllowListConfig | Format-List *Enabled

Use the Shell to enable or disable the IP Allow list

To disable the IP Allow list, run the following command:
 Set-IPAllowListConfig -Enabled $false

To enable the IP Allow list, run the following command:

Set-IPAllowListConfig -Enabled $true

How do you know this worked?

To verify that you successfully enabled or disabled the IP Allow list, run the following command and verify that the
value displayed is the value you configured.

Get-IPAllowListConfig | Format-List *Enabled

Use the Shell to configure the IP Allow list

To configure the IP Allow list, use the following syntax:

Set-IPAllowListConfig [-ExternalMailEnabled <$true | $false>] [-InternalMailEnabled <$true | $false>

This example configures the IP Allow list to filter incoming connections from internal and external mail servers. By
default, connections are filtered from external mail servers only (ExternalMailEnabled is set to $true , and
InternalMailEnabled is set to $false ). Non-authenticated connections and authenticated connections from
external partners are considered external.

Set-IPAllowListConfig -InternalMailEnabled $true

How do you know this worked?

To verify that you successfully configured the IP Allow list, run the following command and verify that the values
displayed are the values you configured.

Get-IPAllowListConfig | Format-List *MailEnabled

Use the Shell to view IP Allow list entries

To view all IP Allow list entries, run the following command:

Get-IPAllowListEntry

Note that each IP Allow list entry is identified by an integer value. The identity integer is assigned in ascending
order when you add entries to the IP Block list and the IP Allow list.
To view a specific IP Allow list entry, use the following syntax:

Get-IPAllowListEntry <-Identity IdentityInteger | -IPAddress IPAddress>

For example, to view the IP Allow list entry that contains the IP address 192.168.1.13, run the following command:
 Get-IPAllowListEntry -IPAddress 192.168.1.13

NOTE
When you use the IPAddress parameter, the resulting IP Allow list entry can be an individual IP address, an IP address range,
or a Classless InterDomain Routing (CIDR) IP. To use the Identity parameter, you specify the integer value that's assigned to
the IP Allow list entry.

Use the Shell to add IP Allow list entries

To add IP Allow list entries, use the following syntax:

Add-IPAllowListEntry <-IPAddress IPAddress | -IPRange IP range or CIDR IP> [-ExpirationTime <DateTime>] [-

Comment "<Descriptive Comment>"]

This example adds the IP Allow list entry for the IP address range 192.168.1.10 through 192.168.1.15 and
configures the IP Allow list entry to expire on July 4, 2014 at 15:00.

Add-IPAllowListEntry -IPRange 192.168.1.10-192.168.1.15 -ExpirationTime "7/4/2014 15:00"

How do you know this worked?

To verify that you successfully added an IP Allow list entry, run the following command and verify that the new IP
Allow list entry is displayed.

Get-IPAllowListEntry

Use the Shell to remove IP Allow list entries

To remove IP Allow list entries, use the following syntax:

Remove-IPAllowListEntry <IdentityInteger>

The following example removes the IP Allow list entry that has the Identity value 3.

Remove-IPAllowListEntry 3

This example removes the IP Allow list entry that contains the IP address 192.168.1.12 without using the Identity
integer value. Note that the IP Allow list entry can be an individual IP address or an IP address range.

Get-IPAllowListEntry -IPAddress 192.168.1.12 | Remove-IPAllowListEntry

How do you know this worked?

To verify that you successfully removed an IP Allow list entry, run the following command and verify that the IP
Allow list entry you removed is gone.
 Get-IPAllowListEntry

IP Allow List provider procedures

These procedures apply to IP Allow List providers. They don't apply to the IP Allow list.
Use the IPAllowListProvidersConfig cmdlets to view and configure how connection filtering uses all IP Allow
List providers. Use the IPAllowListProvider cmdlets to view, configure, and test IP Allow List providers.

Use the Shell to view the configuration of all IP Allow List providers
To view how connection filtering uses all IP Allow List providers, run the following command:

Get-IPAllowListProvidersConfig | Format-List *Enabled

Use the Shell to enable or disable all IP Allow List providers

To disable all IP Allow List providers, run the following command:

Set-IPAllowListProvidersConfig -Enabled $false

To enable all IP Allow List providers, run the following command:

Set-IPAllowListProvidersConfig -Enabled $true

How do you know this worked?

To verify that you enabled or disabled all IP Allow List providers, run the following command and verify that the
value displayed is the value you configured.

Get-IPAllowListProvidersConfig | Format-List Enabled

Use the Shell to configure all IP Allow List providers

To configure how connection filtering uses all IP Allow List providers, use the following syntax:

Set-IPAllowListProvidersConfig [-ExternalMailEnabled <$true | $false>] [-InternalMailEnabled <$true | $false>]

This example configures all IP Allow List providers to filter incoming connections from internal and external mail
servers. By default, connections are filtered from external mail servers only (ExternalMailEnabled is set to $true ,
and InternalMailEnabled is set to $false ). Non-authenticated connections and authenticated connections from
external partners are considered external.

Set-IPAllowListProvidersConfig -InternalMailEnabled $true

For more information, see Set-IPBlockListProvidersConfig.

How do you know this worked?
To verify that you successfully configured all IP Allow List providers, run the following command and verify that
the values displayed are the values you configured.

Get-IPAllowListProvidersConfig | Format-List *MailEnabled

Use the Shell to view IP Allow List providers

To view the summary list of all the IP Allow List providers, run the following command.

Get-IPAllowListProvider

To view the details of a specific provider, use the following syntax.

Get-IPAllowListProvider <IPAllowListProviderIdentity>

This example show the details of the provider named Contoso IP Allow List Provider.

Get-IPAllowListProvider "Contoso IP Allow List Provider" | Format-List

Name,Enabled,Priority,LookupDomain,*Match

Use the Shell to add an IP Allow List provider

To add an IP Allow List provider, use the following syntax:

Add-IPAllowListProvider -Name "<Descriptive Name>" -LookupDomain <FQDN> [-Priority <Integer>] [-Enabled <$true
| $false>] [-AnyMatch <$true | $false>] [-BitmaskMatch <IPAddress>] [-IPAddressesMatch
<IPAddressStatusCode1,IPAddressStatusCode2...>]

This example creates an IP Allow List provider named "Contoso IP Allow List Provider" with the following options:
FQDN to use the provider: allow.contoso.com
Bitmask code to use from the provider: 127.0.0.1

Add-IPAllowListProvider -Name "Contoso IP Allow List Provider" -LookupDomain allow.contoso.com -BitmaskMatch

127.0.0.1

NOTE
When you add a new IP Allow List provider, it's enabled by default (the value of Enabled is $true ), and the priority value is
incremented (the first entry has the Priority value 1).

For more information, see Add-IPBlockListProvider.

How do you know this worked?

To verify that you successfully added an IP Allow List provider, run the following command and verify that the new
IP Allow List provider is displayed.
 Get-IPAllowListProvider

Use the Shell to enable or disable an IP Allow List provider

To enable or disable a specific IP Allow List provider, use the following syntax.

Set-IPAllowListProvider <IPAllowListProviderIdentity> -Enabled <$true | $false>

This example disables the provider named Contoso IP Allow List Provider.

Set-IPAllowListProvider "Contoso IP Allow List Provider" -Enabled $false

This example enables the provider named Contoso IP Allow List Provider.

Set-IPAllowListProvider "Contoso IP Allow List Provider" -Enabled $true

How do you know this worked?

To verify that you successfully enabled or disabled an IP Allow List provider, run the following command and verify
that the value displayed is the value you configured.

Get-IPAllowListProvider <IPAllowListProviderIdentity> | Format-List Enabled

Use the Shell to configure an IP Allow List provider

The configuration options that are available on the Set-IPAllowListProvider cmdlet are identical to those on the
New-IPAllowListProvider cmdlet.
To configure an existing IP Allow List provider, use the following syntax:

Set-IPAllowListProvider <IPAllowListProviderIdentity> -Name "<Descriptive Name>" -LookupDomain <FQDN> [-

Priority <Integer>] [-AnyMatch <$true | $false>] [-BitmaskMatch <IPAddress>] [-IPAddressesMatch
<IPAddressStatusCode1,IPAddressStatusCode2...>]

For example, to add the IP address status code 127.0.0.1 to the list of existing status codes for the provider named
Contoso IP Allow List Provider, run the following command:

Set-IPAllowListProvider "Contoso IP Allow List Provider" -IPAddressesMatch @{Add="127.0.0.1"}

For more information, see Set-IPBlockListProvider.

How do you know this worked?

To verify that you successfully configured an IP Allow List provider, run the following command and verify that the
values displayed are the values you configured.

Get-IPAllowListProvider <IPAllowListProviderIdentity> | Format-List

Use the Shell to test an IP Allow List provider
To test an IP Allow List provider, use the following syntax:

Test-IPAllowListProvider <IPAllowListProviderIdentity> -IPAddress <IPAddressToTest>

The following example tests the provider named Contoso IP Allow List Provider by looking up the IP address
192.168.1.1.

Test-IPAllowListProvider "Contoso IP Allow List Provider" -IPAddress 192.168.1.1

Use the Shell to remove an IP Allow List provider

To remove an IP Allow List provider, use the following syntax:

Remove-IPAllowListProvider <IPAllowListProviderIdentity>

This example removes the IP Allow List provider named Contoso IP Allow List Provider.

Remove-IPAllowListProvider "Contoso IP Allow List Provider"

How do you know this worked?

To verify that you successfully removed an IP Allow List provider, run the following command and verify that the
IP Allow List provider you removed is gone.

Get-IPAllowListProvider
 Recipient filtering on Edge Transport servers
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Recipient filtering is an anti-spam feature in Microsoft Exchange Server 2013 that relies on the RCPT TO SMTP
header to determine what action, if any, to take on an inbound message. Recipient filtering is performed by the
Recipient Filter agent.
The Recipient Filter agent blocks messages according to the characteristics of the intended recipient in the
organization. The Recipient Filter agent can help you prevent the acceptance of messages in the following
scenarios:
Nonexistent recipients: You can prevent delivery to recipients that aren't in the organization's address
book. For example, you may want to stop delivery to frequently misused account names, such as
[email protected] or [email protected].
Restricted distribution lists: You can prevent delivery of Internet mail to distribution lists that should be
used only by internal users.
Mailboxes that should never receive messages from the Internet: You can prevent delivery of Internet
mail to a specific mailbox or alias that's typically used inside the organization, such as Helpdesk.
The Recipient Filter agent acts on recipients stored in one or both of the following data sources:
Recipient Block list: An administrator-defined list of recipients who should never receive messages from
the Internet.
Recipient Lookup: Queries Active Directory to verify the recipient exists in the organization. On an Edge
Transport server, Recipient Lookup requires access to Active Directory information provided by EdgeSync to
the local instance of Active Directory Lightweight Directory Services (AD LDS ).
When you enable the Recipient Filter agent, one of the following actions is taken on inbound messages according
to the characteristics of the recipients. These recipients are indicated by the RCPT TO header.
If the inbound message contains a recipient that is on the Recipient Block list, the Exchange server sends a
550 5.1.1 User unknown SMTP session error to the sending server.

If the inbound message contains a recipient that doesn't match any recipients in Recipient Lookup, the
Exchange server sends a 550 5.1.1 User unknown SMTP session error to the sending server.
If the recipient isn't on the Recipient Block list and the recipient is in Recipient Lookup, the Exchange server
sends a 250 2.1.5 Recipient OK SMTP response to the sending server, and the next anti-spam agent in the
chain processes the message.

Configuring recipient lookup

One of the most effective ways to reduce spam is to validate recipients before accepting inbound messages from
the Internet. You enable the blocking of messages sent to recipients who don't exist in the Exchange organization,
and the blocking of specific recipients using the Set-RecipientFilterConfig cmdlet in the Exchange Management
Shell. For more information, see Manage recipient filtering on Edge Transport servers.
If you have an Edge Transport server installed in your perimeter network, it's a good idea to configure the AD LDS
instance that runs on the Edge Transport server to synchronize with Active Directory. By default, AD LDS is
installed and configured on the Edge Transport server. However, you must configure AD LDS to communicate with
an Active Directory domain-joined global catalog server by subscribing the Edge Transport server to your
organization. For more information, see Use an Exchange 2010 or 2007 Edge Transport server in Exchange 2013.

Tarpitting functionality
Recipient Lookup functionality enables the sending server to determine whether an email address is valid or
invalid. As mentioned earlier, when the recipient of an inbound message is a known recipient, the Exchange server
sends back a 250 2.1.5 Recipient OK SMTP response to the sending server. This functionality provides an ideal
environment for a directory harvest attack.
A directory harvest attack is an attempt to collect valid email addresses from a particular organization so that the
email addresses can be added to a spam database. Because all spam income relies on trying to make people open
email messages, addresses known to be active are a commodity that malicious users, or spammers, pay for.
Because the SMTP protocol provides feedback for known senders and unknown senders, a spammer can write an
automated program that uses common names or dictionary terms to construct email addresses to a specific
domain. The program collects all email addresses that return a 250 2.1.5 Recipient OK SMTP response and
discards all email addresses that return a 550 5.1.1 User unknown SMTP session error. The spammer can then sell
the valid email addresses or use them as recipients for unsolicited messages.
To combat directory harvest attacks, Exchange 2013 includes tarpitting functionality. Tarpitting is the practice of
artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of
spam or other unwelcome messages. The intent of tarpitting is to slow down the communication process for such
email traffic so that the cost of sending spam increases for the person or organization sending the spam. Tarpitting
makes directory harvest attacks too costly to automate efficiently.
If tarpitting isn't configured, the Exchange server immediately returns a 550 5.1.1 User unknown SMTP session
error to the sender when a recipient isn't located in Recipient Lookup. Alternatively, if tarpitting is configured,
SMTP waits a specified number of seconds before it returns the 550 5.1.1 User unknown error. This pause in the
SMTP session makes automating a directory harvest attack more difficult and less cost-effective for the spammer.
By default, tarpitting is configured for 5 seconds on Receive connectors.
To configure the delay before SMTP returns the 550 5.1.1 User unknown error, you set the tarpitting interval using
the TarpitInterval parameter on the Set-ReceiveConnector cmdlet. The syntax is:

Set-ReceiveConnector <Receive Connector> -TarpitInterval <00:00:00 to 00:10:00>

The default value is 00:00:05 or 5 seconds. The name of the default Receive connector on an Edge Transport
server is Default internal receive connector <server name> .
Use caution if you decide to change the tarpitting interval. An overly long interval could disrupt ordinary mail flow,
whereas an overly brief interval may not be as effective in thwarting a directory harvest attack. If you change the
tarpitting interval, do so in small increments and verify the results. For example, if 5 seconds isn't effective, try
changing the interval to 10 seconds.

Multiple namespaces
The Recipient Filter agent performs recipient lookups only for authoritative domains. If your organization accepts
and forwards messages on behalf of another domain that's configured as an internal relay or external relay
domain, the Recipient Filter agent doesn't perform a recipient lookup on recipients in those domains. However, if
the recipient is specified in the Recipient Block list, the recipient will still be blocked by the Recipient Filter agent.
Note that you can also configure accepted domains locally on an Edge Transport server. If the domain is
configured as internal relay or external relay domain, the Recipient Filter agent on the Edge Transport server also
doesn't perform a recipient lookup on recipients in those domains.
 Manage recipient filtering on Edge Transport servers
6/10/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Recipient filtering is provided by the Recipient Filter agent. When recipient filtering is enabled on an Exchange
server, it filters inbound messages that come from the Internet but aren't authenticated. These messages are
handled as external messages.

NOTE
Although the Recipient Filter agent is available on Mailbox servers, you shouldn't configure it. When recipient filtering on a
Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the message is
rejected. If you install the anti-spam agents on a Mailbox server, the Recipient Filter agent is enabled by default. However, it
isn't configured to block any recipients. For more information, see Enable anti-spam functionality on Mailbox servers.

What do you need to know before you begin?

Estimated time to complete each procedure: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
topic.
You can only use the Shell to perform this procedure.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
The AddressBookEnabled parameter on the Set-AcceptedDomain cmdlet enables or disables recipient
filtering for recipients in an accepted domain. By default, recipient filtering is enabled for authoritative
domains, and disabled for internal relay domains and external relay domains. To view the status of the
AddressBookEnabled parameter for the accepted domains in your organization, run the following
command:

Get-AcceptedDomain | Format-List Name,AddressBookEnabled

If you disable recipient filtering using the procedure in this topic, recipient filtering functionality will be
disabled, but the underlying Recipient Filter agent will remain enabled.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable recipient filtering

To disable recipient filtering, run the following command:

Set-RecipientFilterConfig -Enabled $false

To enable recipient filtering, run the following command:

Set-RecipientFilterConfig -Enabled $true

NOTE
When you disable recipient filtering, the underlying Recipient Filter agent is still enabled. To disable the Recipient Filter agent,
run the command: Disable-TransportAgent "Recipient Filter Agent" .

How do you know this worked?

To verify that you have successfully enabled or disabled recipient filtering, do the following:
1. Run the following command:

Get-RecipientFilterConfig | Format-List Enabled

2. Verify the value displayed is the value you configured.

Use the Shell to enable or disable the Recipient Block list

Run the following command:

Set-RecipientFilterConfig -BlockListEnabled <$true | $false>

This example enables the Recipient Block list:

Set-RecipientFilterConfig -BlockListEnabled $true

How do you know this worked?

To verify that you have successfully enabled or disabled the Recipient Block list, do the following:
1. Run the following command:

Get-RecipientFilterConfig | Format-List BlockListEnabled

2. Verify the value displayed is the value you configured.

Use the Shell to configure the Recipient Block list

To replace the existing values, run the following command:

Set-RecipientFilterConfig -BlockedRecipients <recipient1,recipient2...>

This example configures the Recipient Block list with the [email protected] and [email protected]:

Set-RecipientFilterConfig -BlockedRecipients [email protected],[email protected]

To add or remove entries without modifying any existing values, run the following command:

Set-RecipientFilterConfig -BlockedRecipients @{Add="<recipient1>","<recipient2>"...; Remove="<recipient1>","

<recipient2>"...}

This example adds [email protected] to the list of recipients, and removes [email protected] from the list of
recipients in the Recipient Block list:

Set-RecipientFilterConfig -BlockedRecipients @{Add="[email protected]"; Remove="[email protected]"}

How do you know this worked?

To verify that you have successfully configured the Recipient Block list, do the following:
1. Run the following command:

Get-RecipientFilterConfig | Format-List BlockedRecipients

2. Verify the values displayed are the values you configured.

Use the Shell to enable or disable Recipient Lookup

Run the following command:

Set-RecipientFilterConfig -RecipientValidationEnabled <$true | $false>

To block messages to recipients that don't exist in your organization, run the following command:

Set-RecipientFilterConfig -RecipientValidationEnabled $true

How do you know this worked?

To verify that you have successfully enabled or disabled Recipient Lookup, do the following:
1. Run the following command:

Get-RecipientFilterConfig | Format-List RecipientValidationEnabled

2. Verify the value displayed is the value you configured.

 Attachment filtering on Edge Transport servers
5/20/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can use attachment filtering on Edge Transport servers to control the
attachments that users receive in email messages. Attachment filtering is performed by the Attachment Filtering
agent, which is available only on Edge Transport servers.

Types of attachment filtering

You can use the following types of attachment filtering to control attachments that enter or leave your organization
through an Edge Transport server:
Filtering based on file name or file name extension: You specify the exact file name or file name
extension that you want to filter. An example of a file name filter is BadFileName.exe . An example of a file
name extension filter is *.exe .
Filtering based on file MIME content type: You specify the MIME content type value that you want to
filter. The MIME content type value indicates what the attachment is: for example, a JPEG image, an
executable file, or a Microsoft Excel file. Content types are expressed as type/subtype . For example, a JPEG
image file is expressed as image/jpeg .
To view a complete list of file name extensions and content types that attachment filtering can detect, run the
following command on the Edge Transport server:

Get-AttachmentFilterEntry | Format-List

After you define the files to look for, you can configure the action to take on messages that contain these
attachments. You can't specify different actions for different types of attachments. You configure one of the
following actions for all the messages that match any of the attachment filters:
Reject (block) the message: The message is blocked. The sender receives a non-delivery report (NDR )
that explains that the message wasn't delivered because it contained an unacceptable attachment. You can
customize the text in the NDR. The default text is: Message rejected due to unacceptable attachments .
Strip the attachment but allow the message through: The attachment is removed from the message.
However, the message itself and any other attachments that don't match the filter are allowed through. If an
attachment is stripped, it's replaced with a text file that explains why the attachment was removed. This is
the default action.
Silently delete the message: The message is deleted. Neither the sender nor the recipient receives
notification.
For more information, see Manage attachment filtering on Edge Transport servers.
NOTE
You can't retrieve messages that have been blocked or attachments that have been stripped. When you configure
attachment filters, carefully examine all possible file name matches and verify that legitimate attachments won't be affected
by the filter.
Also, don't remove attachments from digitally signed, encrypted, or rights-protected email messages. If you remove
attachments from such messages, you invalidate the digitally signed messages and make encrypted and rights-protected
messages unreadable.
 Manage attachment filtering on Edge Transport
servers
6/10/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Attachment filtering is provided by the Attachment Filter agent that's available only on Edge Transport servers.
Attachment filtering can help prevent files that are attached in email messages from entering your organization.
You can configure one or more attachment filter entries to filter attachments either by content type or by file name.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions
and the "Transport agents" entry in the Mail flow permissions topic.
Configuration changes that you make to attachment filtering on an Edge Transport server are made only to
the local computer. If you have multiple Edge Transport servers in your perimeter network, you need to
configure attachment filtering on each Edge Transport server separately.
You can only use the Shell to perform this procedure.
When you disable attachment filtering and restart the Microsoft Exchange Transport service, all attachment
filtering features stop working.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to enable or disable attachment filtering

When you enable or disable the Attachment Filtering agent, the change takes effect after you restart the Microsoft
Exchange Transport service. When you restart the Microsoft Exchange Transport service on an Edge Transport
server, mail flow on the server is temporarily interrupted.
To disable attachment filtering, run the following command:

Disable-TransportAgent "Attachment Filtering Agent"

To enable attachment filtering, run the following command:

Enable-TransportAgent "Attachment Filtering Agent"

After you enable or disable attachment filtering, restart the Microsoft Exchange Transport service by running the
following command:
 Restart-Service MSExchangeTransport

How do you know this worked?

To verify that you successfully enabled or disabled attachment filtering, do the following:
1. Run the following command:

Get-TransportAgent "Attachment Filtering Agent"

2. If the value of Enabled is True , attachment filtering is enabled. If the value is False , attachment filtering is
disabled.

Use the Shell to view attachment filtering entries

Attachment filtering entries define the message attachments that you want to keep out of your organization. To
view the attachment filtering entries that are used by the Attachment Filtering agent, run the following command:

Get-AttachmentFilterEntry | Format-Table

To view a specific MIME content type entry, use the following syntax:

Get-AttachmentFilteringEntry ContentType:<MIMEContentType>

For example, to view the content type entry for JPEG images, run the following command:

Get-AttachmentFilteringEntry ContentType:image/jpeg

To view a specific file name or file name extension entry, use the following syntax:

Get-AttachmentFilteringEntry FileName:<FileName or FileNameExtension>

For example, to view the file name extension entry for JPEG attachments, run the following command:

Get-AttachmentFilteringEntry FileName:*.jpg

Use the Shell to add attachment filtering entries

To add an attachment filtering entry that filters attachments by MIME content type, use the following syntax:

Add-AttachmentFilterEntry -Name <MIMEContentType> -Type ContentType

The following example adds a MIME content type entry that filters JPEG images.

Add-AttachmentFilterEntry -Name image/jpeg -Type ContentType

To add an attachment filtering entry that filters attachments by file name or file name extension, use the following
syntax:
 Add-AttachmentFilterEntry -Name <FileName or FileNameExtension> -Type FileName

The following example filters attachments that have the .jpg file name extension.

Add-AttachmentFilterEntry -Name *.jpg -Type FileName

How do you know this worked?

To verify that you successfully added an attachment filtering entry, do the following:
1. Run the following command to verify that the filtering entry exists.

Get-AttachmentFilterEntry | Format-Table

2. Send a test message that contains a prohibited attachment from an external mailbox to an internal recipient
and verify that the message is rejected, stripped, or deleted.

Use the Shell to remove attachment filtering entries

To remove an attachment filtering entry that filters attachments by MIME content type, use the following syntax:

Remove-AttachmentFilterEntry ContentType:<ContentType>

The following example removes the MIME content type entry for JPEG images.

Remove-AttachmentFilterEntry ContentType:image/jpeg

To remove an attachment filtering entry that filters attachments by file name or file name extension, use the
following syntax:

Remove-AttachmentFilterEntry FileName:<FileName or FileNameExtension>

The following example removes the file name entry for the .jpg file name extension.

Remove-AttachmentFilterEntry FileName:*.jpg

How do you know this worked?

To verify that you successfully removed an attachment filtering entry, do the following:
1. Run the following command to verify that the filtering entry was removed.

Get-AttachmentFilterEntry | Format-Table

2. Send a test message that contains an allowed attachment from an external mailbox to an internal recipient
and verify that the message was successfully delivered with the attachment.

Use the Shell to view the attachment filtering action

To view the attachment filtering action that's used when a prohibited attachment is detected in a message, run the
following command:

Get-AttachmentFilterListConfig

Use the Shell to configure the attachment filtering action

To configure the attachment filtering action that will be used when a prohibited attachment is detected in a
message, use the following syntax:

Set-AttachmentFilterListConfig [-Action <Reject | Strip | SilentDelete>] [-RejectResponse "<Message text>"] [-

AdminMessage "<Replacement file text>"] [-ExceptionConnectors <ConnectorGUID>]

This example makes the following changes to the attachment filtering configuration:
Reject (block) messages that have prohibited attachments.
Use a custom response for rejected messages.

Set-AttachmentFilterListConfig -Action Reject -RejectResponse "This message contains a prohibited attachment.

Your message can't be delivered. Please resend the message without the attachment."

For more information, see Set-AttachmentFilterListConfig.

How do you know this worked?

To verify that you successfully configured the attachment filtering action, send a test message that contains a
prohibited attachment from an external mailbox to an internal recipient and verify that the message and the
attachment are processed as you expect.
 Spam quarantine
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Many organizations are bound by legal or regulatory requirements to preserve or deliver all legitimate email
messages. In Microsoft Exchange Server 2013, spam quarantine is a feature of the Content Filter agent that
reduces the risk of losing legitimate messages. Spam quarantine provides a temporary storage location for
messages identified as spam that shouldn't be delivered to a user mailbox inside the organization.
Messages identified by the Content Filter agent as spam are wrapped in a non-delivery report (NDR ) and
delivered to a spam quarantine mailbox inside the organization. You can manage messages delivered to the spam
quarantine mailbox and take appropriate actions. For example, you can delete messages or let messages flagged
as false positives in anti-spam filtering be routed to their intended recipients. In addition, you can configure the
spam quarantine mailbox to automatically delete messages after a designated time period.

Spam confidence level

When an external user sends email messages to a server running Exchange that runs the anti-spam features, the
anti-spam features cumulatively evaluate characteristics of the messages and act as follows:
Those messages suspected to be spam are filtered out.
A rating is assigned to messages based on the probability that a message is spam. This rating is stored with
the message as a message property called the spam confidence level (SCL ) rating.
Spam quarantine uses the SCL rating to determine whether mail has a high probability of being spam. The SCL
rating is a numeric value from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered most
likely to be spam.
You can configure mail that has a certain SCL rating to be deleted, rejected, or quarantined. The rating that
triggers any of these actions is referred to as the SCL quarantine threshold. Within content filtering, you can
configure the Content Filter agent to base its actions on the SCL quarantine threshold. For example, you can set
the following conditions:
SCL delete threshold is set to 8.
SCL reject threshold is set to 7.
SCL quarantine threshold is set to 6.
SCL Junk Email folder threshold is set to 5.
Based on the preceding SCL thresholds, all email with an SCL of 6 will be delivered to the spam quarantine
mailbox.
For more information, see Manage content filtering.

Spam quarantine
When messages are received by the Exchange server that's running all default anti-spam agents, the content filter
is applied as follows:
If the SCL rating is greater than or equal to the SCL quarantine threshold but less than either the SCL
 delete threshold or SCL reject threshold, the message goes to the spam quarantine mailbox.
If the SCL rating is lower than the spam quarantine threshold, it's delivered to the recipient's Inbox.
The message administrator uses Microsoft Outlook to monitor the spam quarantine mailbox for false positives. If
a false positive is found, the administrator can send the message to the recipient's mailbox.
The message administrator can review the anti-spam stamps if either of the following conditions is true:
Too many false positives are filtered into the spam quarantine mailbox.
Not enough spam is being rejected or deleted.
For more information, see Anti-spam stamps.
You can then adjust the SCL settings to more accurately filter the spam coming into the organization. For more
information, see Spam Confidence Level Threshold.
To use spam quarantine, you need to follow these steps:
1. Verify content filtering is enabled.
2. Create a dedicated mailbox for spam quarantine.
3. Specify the spam quarantine mailbox.
4. Configure the SCL quarantine threshold.
5. Manage the spam quarantine mailbox.
6. Adjust the SCL quarantine threshold as needed.
For detailed instructions, see Configure a spam quarantine mailbox.
 Configure a spam quarantine mailbox
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Messages determined to be spam by the Content Filter agent can be directed to a spam quarantine mailbox. If the
spam confidence level (SCL ) quarantine threshold is enabled, all messages that are quarantined are wrapped as
non-delivery reports (NDR ) and are sent to the SMTP address that you specify as the spam quarantine mailbox.
You can review quarantined messages and release them to their intended recipients by using the Send Again
feature in Microsoft Outlook.

What do you need to know before you begin?

Estimated time to complete this task: 45 minutes.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you
only enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior
anti-spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
The person responsible for the spam quarantine mailbox can view potentially private and sensitive
messages, and then send mail on behalf of anybody in the Exchange organization.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Verify content filtering is enabled

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions topic.
1. Run the following command to verify the Content Filter agent is installed and enabled on the Exchange
server:

Get-TransportAgent "Content Filter Agent"

2. Run the following command to verify content filtering is enabled:

Get-ContentFilterConfig | Format-List Enabled

For more information, see Manage content filtering.

Step 2: Create a dedicated mailbox for spam quarantine

To create a dedicated spam quarantine mailbox, follow these steps:
 Create a dedicated Exchange database: We recommend that you create a dedicated database for the
spam quarantine mailbox. The spam quarantine mailbox should have a large database, because if the
storage quota limit is reached, messages will be lost. For more information, see Manage mailbox databases
in Exchange 2013.
Create a dedicated mailbox and user account: We recommend that you create a dedicated mailbox and
Active Directory user account for the spam quarantine mailbox. For more information, see Create user
mailboxes.
You may apply recipient policies, such as messaging records management, mailbox quotas, and delegation
rights, according to your organization's compliance policies and needs. For more information, see
Messaging records management.

NOTE
If a quarantined message is rejected because of a storage quota, the message will be lost. Exchange doesn't generate
NDRs for quarantined messages because the quarantined messages are wrapped as NDRs.

Configure Outlook: You need to configure the Outlook delegate access permissions to meet the needs of
your organization. In addition, we recommend that you configure the Outlook profile to show the original
Sender[#0x0069001E] , Recipient[#0x0E04001E] , and Bcc[#0x0E02001E] fields in the Message view. For more
information, see Release quarantined messages from the spam quarantine mailbox.

Step 3: Specify the spam quarantine mailbox

You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-spam features" entry in the Anti-spam and anti-malware permissions topic.
Run the following command:

Set-ContentFilterConfig -QuarantineMailbox <SmtpAddress>

This example sends all messages that exceed the spam quarantine threshold to [email protected].

Set-ContentFilterConfig -QuarantineMailbox [email protected]

How do you know this step worked?

To verify that you have successfully specified the spam quarantine mailbox, do the following:
1. Run the following command:

Get-ContentFilterConfig | Format-List QuarantineMailbox

2. Verify the value displayed is the value you configured.

Step 4: Configure the SCL quarantine threshold

The SCL quarantine threshold is the value at which a particular message identified as potential spam is delivered
to the spam quarantine mailbox. You can set the SCL quarantine threshold to a value from 0 through 9, where 0 is
considered less likely to be spam, and 9 is considered most likely to be spam.
For more information about how to adjust SCL thresholds to suit your organization's requirements and how to
adjust per-recipient SCL thresholds, see Manage content filtering.

Step 5: Manage the spam quarantine mailbox

When you manage your spam quarantine mailbox, follow these guidelines:
Release items that have been sent to the spam quarantine mailbox by using the Send Again feature in
Outlook to resend the original message.
For more information, see Release quarantined messages from the spam quarantine mailbox.
Monitor the spam quarantine mailbox so that the size of the spam quarantine mailbox remains in an
acceptable range. The volume of email messages can change because of a larger set of recipients, the
natural trend of larger messages, or the threshold on the SCL quarantine action.
Monitor the spam quarantine mailbox for false positives. If your spam quarantine mailbox includes many
false positives, adjust your SCL quarantine threshold. For more information about how to determine why
false positives are being delivered to the spam quarantine mailbox, see Anti-spam stamps.
Use the same Outlook profile to recover quarantined messages from the spam quarantine mailbox.
Applying permissions to a different Outlook profile to recover messages isn't supported. You can't use a
different Outlook profile to recover or release messages from the spam quarantine mailbox.

IMPORTANT
NDRs identified as spam are deleted, even if their SCL rating indicates that they should be quarantined. NDRs aren't
delivered to the spam quarantine mailbox. To track such messages, use the agent log or the message tracking log. For more
information, see Anti-spam agent logging.

Step 6: Adjust the SCL quarantine threshold

After you configure the SCL quarantine threshold, periodically monitor the settings and adjust them based on
your organization's needs. For example, if too many false positives are filtered into the spam quarantine mailbox,
raise the SCL quarantine threshold to a larger number. For more information about how to adjust the SCL
quarantine threshold, see Spam Confidence Level Threshold.
 Configure Outlook to show the original sender in the
quarantine mailbox
6/7/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages. Spam
quarantine provides a temporary storage location for messages that are identified as spam and that shouldn't be
delivered to a user mailbox inside the organization.
When a message meets the spam quarantine threshold, it's wrapped in a non-delivery report (NDR ) and delivered
to the spam quarantine mailbox. Because the quarantined messages are stored as NDRs in the quarantine mailbox,
the postmaster address of your organization will be listed as the From: address for all messages. However, having
the original sender address, the original recipient address, and the original spam confidence level (SCL ) in the field
list would make it easier to locate the message you want to recover.
By default, you can't select these fields in Microsoft Outlook. Before you can add these fields in the message view,
you must first create an Outlook form that adds the original sender, original recipient, and original SCL as optional
fields you can select. After you create this custom form, you can configure Outlook to display these fields in the
message view.

What do you need to know before you begin?

Estimated time to complete this procedure: 15 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox access" entry in the Mail flow permissions topic.
This procedure requires that you've configured the anti-spam quarantine mailbox. For more information,
see Configure a spam quarantine mailbox.
To access the quarantine mailbox, you need to configure an Outlook profile for that mailbox and then open
the mailbox using Outlook. For more information about configuring and using multiple Outlook profiles,
see Overview of Outlook e-mail profiles.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Use Notepad to create a custom Outlook form

1. Open Notepad, and copy the following code into the document.

[Description]
MessageClass=IPM.Note
CLSID={00020D31-0000-0000-C000-000000000046}
DisplayName=Quarantine Extension Form
Category=Standard
Subcategory=Form
 Comment=This form allows the Original Sender (ReceivedRepresentingEmailAddress), Original Recipient
(To), and Original SCL (OriginalScl) values to be viewed as columns.
LargeIcon=IPML.ico
SmallIcon=IPMS.ico
Version=3.0
Locale=enu
Hidden=1
Owner=Microsoft Corporation
Contact=Your Name

[Platforms]
Platform1=Win16
Platform2=NTx86
Platform9=Win95

[Platform.Win16]
CPU=ix86
OSVersion=Win3.1

[Platform.NTx86]
CPU=ix86
OSVersion=WinNT3.5

[Platform.Win95]
CPU=ix86
OSVersion=Win95

[Properties]
Property01=ReceivedRepresentingEmailAddress
Property02=DisplayTo
Property03=OriginalScl

[Property.ReceivedRepresentingEmailAddress]
Type=31
NmidInteger=0x0078
DisplayName=ReceivedRepresentingEmailAddress

[Property.DisplayTo]
Type=31
NmidInteger=0x0E04
DisplayName=DisplayTo

[Property.OriginalScl]
Type=3
NmidPropset={41F28F13-83F4-4114-A584-EEDB5A6B0BFF}
NmidString=OriginalScl
DisplayName=OriginalScl

[Verbs]
Verb1=1

[Verb.1]
DisplayName=&Open
Code=0
Flags=0
Attribs=2

[Extensions]
Extensions1=1

[Extension.1]
Type=31
NmidPropset={00020D0C-0000-0000-C000-000000000046}
NmidInteger=1
Value=1000000000000000

2. Save the file in your Office Forms folder using the following values:
 Path: <Office Install Path>\<OfficeVersion>\Forms\<LCID>
<Office Install Path>: For 32-bit versions of Office on 32-bit versions of Microsoft Windows,
or 64-bit versions of Office on 64-bit versions of Windows, the default path is
C:\Program Files\Microsoft Office . For 32 -bit versions of Office on 64 -bit versions of
Windows, the default path is C:\Program Files (x86)\Microsoft Office .
<OfficeVersion>: For Outlook 2007, the value is Office12 . For Outlook 2010, the value is
Office14 . For Outlook 2013, the value is Office15 .

<LCID>: This is your locale ID (LCID ) value. For example, the LCID for US English is 1033. For
more information, see KB221435: List of supported locale identifiers in Word.
Name: For the rest of this procedure, assume the file is named QTNE.cfg . The name of the file isn't
important, but be sure to enclose the value in quotation marks so the file is saved as QTNE.cfg and
not QTNE.cfg.txt.
For example, for a 32-bit US English version of Outlook 2013 installed on a 64-bit version of Windows, save
the file as:

"C:\Program Files (x86)\Microsoft Office\Office15\Forms\1033\QTNE.cfg"

NOTE
If Windows User Access Control (UAC) prevents you from saving the file in the correct location, save it first to a temporary
location, and then copy it.

Step 2: Configure Outlook to use the custom Outlook form

Use one of the following procedures based on the version of Outlook that's installed on your computer.

Configure Outlook 2010 or Outlook 2013

1. In Outlook 2010 or Outlook 2013, click File > Options > Advanced.
2. In the Developers section, click Custom Forms.
3. In the Options dialog box, click Manage Forms.
4. In the Forms Manager dialog box, click Install. Browse to the location of the QTNE.cfg file, select it, and
click Open. In the Form Properties dialog box, review the information, and then click OK to install the
Quarantine Extension Form in your Personal Forms library.
5. In the Forms Manager dialog box, click Close. Click OK twice to close the remaining dialog boxes and
return to the main Outlook interface.
6. On the Home tab in the Mail view of the Inbox, right-click the column heading row (you may need to
expand the width of the message list to see the columns), and then select View Settings.
7. In the Advanced View Settings dialog box, click Columns.
8. In the Show Columns dialog box, in the Select available columns from drop-down list, scroll to the end
of the list and select Forms.
9. In the Select Enterprise forms for this folder dialog box, in the Selected Forms field, select Message
and click Remove. In the Personal Forms field, select Quarantine Extension Form, and then click Add.
 When you are finished, click Close.
10. In the Show Columns dialog box, in the Available Columns section, select one or more of the following
fields and click Add after each field you select.
ReceivedRepresentingEmailAddress: Original sender
DisplayTo: Original recipient (note that this appears as To after you add it)
OriginalScl: Original SCL
Use the Move Up or Move Down buttons to position the columns in the view. For best results, position
the three new fields after the Attachment field, and before the From field. When you are finished, click OK
twice to return to the main Outlook interface.

Configure Outlook 2007

1. In Outlook 2007, click Tools > Options.
2. In the Options dialog box, click the Other tab, and then under General, click Advanced Options.
3. In the Advanced Options dialog box, click Custom Forms, and then in the Custom Forms dialog box,
click Manage Forms.
4. In the Forms Manager dialog box, click Install. Browse to the location of the QTNE.cfg file, select it, and
click Open. In the Form Properties dialog box, review the information, and then click OK to install the
Quarantine Extension Form in your Personal Forms library.
5. Close the Forms Manager dialog box, and then click OK three times to close the remaining dialog boxes
and return to the main Outlook 2007 interface.
6. In the Mail view of the Inbox, right-click the column heading row (you may need to expand the width of the
message list to see the columns), and then select Customize Current View.
7. In the Customize View: Messages dialog box, click Show Fields.
8. In the Show Fields dialog box, in the Select available fields from drop-down list, scroll to the end of the
list and select Forms.
9. In the Select Enterprise forms for this folder dialog box, in the Selected Forms field, select Message
and click Remove. In the Personal Forms field, select Quarantine Extension Form, and then click Add.
When you are finished, click Close.
10. In the Show Fields dialog box, in the Available Fields section, select one or more of the following fields
and click Add after each field you select.
ReceivedRepresentingEmailAddress: Original sender
DisplayTo: Original recipient (note that this appears as To after you add it)
OriginalScl: Original SCL
Use the Move Up or Move Down buttons to position the columns in the view. For best results, position
the three new fields after the Attachment field, and before the From field. When you are finished, click OK
twice to return to the main Outlook 2007 interface.

How do you know this worked?

You know this procedure worked if you can see the original sender, original recipient, or original SCL values for
quarantined messages in the spam quarantine mailbox using Outlook.
 Release quarantined messages from the spam
quarantine mailbox
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use Microsoft Outlook to recover a quarantined message from the spam quarantine mailbox.
Spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages. When
a message meets the spam quarantine threshold, it's wrapped in a non-delivery report (NDR ) and delivered to the
spam quarantine mailbox. For more information about the spam quarantine feature, see Spam quarantine.

What do you need to know before you begin?

Estimated time to complete each procedure: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox access" entry in the Mail flow permissions topic.
This procedure requires that you've configured the anti-spam quarantine mailbox. For more information,
see Configure a spam quarantine mailbox.
To access the quarantine mailbox, you need to configure an Outlook profile for that mailbox and then open
the mailbox using Outlook. For more information about configuring and using multiple Outlook profiles,
see Overview of Outlook e-mail profiles.
To make it easier to locate the message you want to recover, you can create a custom Outlook form and
modify the default view to expose the original sender address in the list of messages. For detailed steps, see
Configure Outlook to show the original sender in the quarantine mailbox.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use Outlook 2010 or Outlook 2013 to release a message from the

spam quarantine mailbox
1. Open the quarantine mailbox using Outlook 2010 or Outlook 2013 on a client computer.
2. In the Mail view, find the message you want to recover in the Inbox, and then double-click the message to
open it.
3. In the Move section of the Ribbon, click Actions > Resend this Message.
4. When the message opens, click Send to resend the message to the intended recipient.

Use Outlook 2007 to release a message from the spam quarantine

mailbox
1. Open the quarantine mailbox using Outlook 2007 on a client computer.
2. In the Mail Folders view, find the message you want to recover in the Inbox, and then double-click the
message to open it.
3. On the Report tab, in the Respond group, click Send Again.
4. When the message opens, click Send to resend the message to the intended recipient.

How do you know this worked?

To verify that you have successfully released the message from the spam quarantine mailbox, contact the recipient
and verify they received the message.
 Anti-spam stamps
5/20/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or stamps, such as
sender-specific information, puzzle validation results, and content filtering results, to messages as they pass
through the anti-spam features that filter inbound messages from the Internet. There are three anti-spam stamps:
the phishing confidence level stamp, the spam confidence level stamp, and the Sender ID stamp.
You can use anti-spam stamps as diagnostic tools to determine what actions to take on false-positives and on
suspected spam messages that individuals receive in their mailboxes.

NOTE
On November 1, 2016, Microsoft stopped producing spam definition updates for the SmartScreen filters in Exchange and
Outlook. The existing SmartScreen spam definitions will be left in place, but their effectiveness will likely degrade over time.
For more information, see Deprecating support for SmartScreen in Outlook and Exchange.

Viewing anti-spam stamps

You can view anti-spam stamps by using Microsoft Outlook. For more information, see View anti-spam stamps in
Outlook.

Understanding the anti-spam report

The anti-spam report is a summary report of the anti-spam filter results that have been applied to an email
message. The Content Filter agent applies this stamp to the message envelope in the form of an X-header as
follows.

X-MS-Exchange-Organization-Antispam-Report: DV:<DATVersion>;CW:CustomList;PCL:PhishingVerdict
<verdict>;P100:PhishingBlock;PP:Presolve;SID:SenderIDStatus <status>;TIME:
<SendReceiveDelta>;MIME:MimeCompliance

The following table describes the filter information that can appear in an anti-spam report.

NOTE
The anti-spam report only displays information from the filters that were applied to the specific message. An anti-spam
report doesn't usually contain all the information listed in the following table. For example, you may receive the following
anti-spam report:
DV:3.1.3924.1409;SID:SenderIDStatus Fail;PCL:PhishingLevel
SUSPICIOUS;CW:CustomList;PP:Presolved;TIME:TimeBasedFeatures
.

Filter information in an anti-spam report

STAMP DESCRIPTION

SID The Sender ID (SID) stamp is based on the sender policy

framework (SPF) that authorizes the use of domains in
email. The SPF is displayed in the message envelope as
Received-SPF . The Sender ID evaluation process
generates a Sender ID status for the message. This status
can be returned as one of the following values:
Pass Both the IP address and Purported
Responsible Address (PRA) passed the Sender ID
verification check.
Neutral Published Sender ID data is explicitly
inconclusive.
Soft fail The IP address for the PRA may be in
the not permitted set.
Fail The IP Address is not permitted; no PRA is
found in the incoming mail or the sending domain
does not exist.
None No published SPF data exists in the
sender's DNS.
TempError A temporary DNS failure occurred,
such as an unavailable DNS server.
PermError The DNS record is invalid, such as an
error in the record format.
The Sender ID stamp is displayed as an X-Header in the
message envelope as follows:
X-MS-Exchange-Organization-SenderIdResult:
<status>

For more information about Sender ID, see Sender ID.

DV The DAT version (DV) stamp indicates the version of the

spam definition file that was used when scanning the
message.

SA The signature action (SA) stamp indicates that the

message was either recovered or deleted because of a
signature that was found in the message.

SV The signature DAT version (SV) stamp indicates the

version of the signature file that was used when scanning
the message.
STAMP DESCRIPTION

PCL The phishing confidence level (PCL) stamp displays the

rating of the message based on its content and is applied
when the message is processed by the Content Filter
agent. This status can be returned as one of the following
values:
Neutral The message's content isn't likely to be
phishing.
Suspicious The message's content is likely to be
phishing.
The PCL value can range from 1 through 8. A PCL rating
from 1 through 3 returns a status of Neutral . This
means that the message's content isn't likely to be
phishing. A PCL rating from 4 through 8 returns a status
of Suspicious . This means that the message is likely to
be phishing.
The values are used to determine what action Outlook
takes on messages. Outlook uses the PCL stamp to block
the content of suspicious messages.
The PCL stamp is displayed as an X-header in the
message envelope as follows:
X-MS-Exchange-Organization-PCL:\

SCL The spam confidence level (SCL) stamp of the message

displays the rating of the message based on its content.
The Content Filter agent uses Microsoft SmartScreen
technology to assess the contents of a message and to
assign an SCL rating to each message. The SCL value is
from 0 through 9, where 0 is considered less likely to be
spam, and 9 is considered more likely to be spam. The
actions that Exchange and Outlook take depend on your
SCL threshold settings.
The SCL stamp is displayed as an X-header in the
message envelope as follows:
X-MS-Exchange-Organization-SCL:\
For more information about SCL thresholds and actions,
see Spam Confidence Level Threshold.

CW The custom weight (CW) stamp of a message indicates

that the message contains an unapproved word or
phrase and that the SCL value, or weight, of that
unapproved word or phrase was applied to the final SCL
score:
Unapproved phrases, or Block phrases, have
maximum weight and change the SCL score to 9.
Approved words or phrases, or Allow phrases,
have minimum weight and change the SCL score
to 0.
For more information about how to add approved and
unapproved words or phrases to the Content Filtering
agent, see Manage content filtering.
STAMP DESCRIPTION

PP The presolved puzzle (PP) stamp indicates that if a

sender's message contains a valid, solved computational
postmark, based on Outlook E-mail Postmark validation
functionality, it's unlikely that the sender is a malicious
sender. In this case, the Content Filter agent would reduce
the SCL rating.
The Content Filter agent doesn't change the SCL rating if
the E-mail Postmark validation feature is enabled and
either of the following conditions is true:
An inbound message doesn't contain a
computational postmark header.
The computational postmark header isn't valid.
For more information about the postmark validation
feature, see Content filtering.

TIME:TimeBasedFeatures The TIME stamp indicates that there was a significant

time delay between the time that the message was sent
and the time that the message was received. The TIME
stamp is used to determine the final SCL rating for the
message.

MIME:MIMECompliance The MIME stamp indicates that the email message isn't
MIME compliant.

P100:PhishingBlock The P100 stamp indicates that the message contains a

URL that's present in a phishing definition file.

IPOnAllowList The IPOnAllowList stamp indicates that the sender's IP

address is on the IP Allow list. For more information
about the IP Allow list, see Understanding Connection
Filtering.

MessageSecurityAntispamBypass The MessageSecurityAntispamBypass stamp indicates

that the message wasn't filtered for content and that the
sender has been granted permission to bypass the anti-
spam filters.

SenderBypassed The SenderBypassed stamp indicates that the Content

Filter agent doesn't process any content filtering for
messages that are received from this sender. For more
information, see Manage content filtering.
STAMP DESCRIPTION

AllRecipientsBypassed The AllRecipientsBypassed stamp indicates that one of the

following conditions was met for all recipients listed in the
message:
The AntispamBypassedEnabled parameter on the
recipient's mailbox is set to $true . This is a per-
recipient setting that can only be set by an
administrator using the Set-Mailbox cmdlet.
The message sender is in the recipient's Outlook
Safe Senders List. For more information about the
Safe Senders List, see Manage safelist aggregation.
The Content Filter agent doesn't process any
content filtering for messages that are sent to this
recipient. For more information about recipient
exceptions, see Manage content filtering.
 View anti-spam stamps in Outlook
6/6/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use Microsoft Outlook to view the anti-spam stamps that Microsoft Exchange applied to an email
message. Anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or
stamps, such as sender-specific information, puzzle validation results, and content filtering results to messages as
the messages pass through the anti-spam agents that filter inbound messages from the Internet.

What do you need to know before you begin?

Estimated time to complete each procedure: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Mailbox access" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use Outlook 2010 or Outlook 2013 to view anti-spam stamps

1. In Outlook 2010 or Outlook 2013, on a client computer, in the Mail view, double-click a message to open it.
2. In the Tags section of the Ribbon, click the Options icon to display the message Properties dialog box.
3. In the Properties dialog box, in the Internet headers section, use the scroll bar to view the anti-spam
stamps as shown in the following example.

X-MS-Exchange-Organization-PCL:7
X-MS-Exchange-Organization-SCL:6
X-MS-Exchange-Organization-Antispam-Report: DV:3.1.3924.1409;SID:SenderIDStatus Fail;PCL:PhishingLevel
SUSPICIOUS;CW:CustomList;PP:Presolved;TIME:TimeBasedFeatures

Use Outlook 2007 to view anti-spam stamps

1. In Outlook 2007, on a client computer, in the Mail view, double-click a message to open it.
2. On the Message tab, in the Options group, click Message Options.
3. In the Message Options dialog box, in the Internet headers section, use the scroll bar to view the anti-
spam stamps as shown in the following example.

X-MS-Exchange-Organization-PCL:7
X-MS-Exchange-Organization-SCL:6
X-MS-Exchange-Organization-Antispam-Report: DV:3.1.3924.1409;SID:SenderIDStatus Fail;PCL:PhishingLevel
SUSPICIOUS;CW:CustomList;PP:Presolved;TIME:TimeBasedFeatures
 Anti-malware protection
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Microsoft Exchange Server 2013 anti-malware protection feature helps combat malware in your email
messaging environment. Malware is comprised of viruses and spyware. Viruses infect other programs and data,
and they spread throughout your computer looking for programs to infect. Spyware refers to malware that
gathers your personal information, such as sign-in information and personal data, and sends it back to its author.
There are several anti-malware protection options in Exchange 2013:
Built-in anti-malware protection in Exchange 2013: You can use the built-in Exchange on-premises
anti-malware protection feature in order to help you combat malware. This basic anti-malware protection
can be turned off, replaced, or paired with a cloud-based service (such as Microsoft Exchange Online
Protection) to provide a layered defense. For more information about typical questions and answers
regarding the product's built-in anti-malware capabilities, see Anti-malware FAQ. For information about
configuring your anti-malware policies so that they are tailored to best meet the needs of your
organization, see Configure anti-malware policies.
Cloud-hosted anti-malware protection: The service leverages partnerships with several best of breed
anti-malware engines, thereby providing efficient, cost effective, multi-layered anti-malware protection.
EOP anti-malware protection features are included in Microsoft Exchange Online. For more information
about these features, see Anti-malware protection.
Third-party anti-malware protection: You can also use a third-party anti-malware protection program.
In this case, you may want to disable the built-in anti-malware protection; for more information, see
Disable or bypass anti-malware scanning.

For more information

Download engine and definition updates
Rescan messages already malware scanned by the hosted filtering service
Anti-Virus Software in the Operating System on Exchange Servers
 Anti-malware FAQ
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic provides frequently asked questions about malware filtering (scanning) in Microsoft Exchange Server
2013.
Q. Where does malware scanning occur?
A. Malware scanning is performed on messages sent to or received from a mailbox server. Malware scanning is
not performed on a message accessed from a mailbox because it should have already been scanned. If a message
is re-sent from a mailbox, it's rescanned.
Q. Do I need Internet access in order to download engine and definition updates?
A. To download updates, you must be able to access the Internet and be able to establish a connection on TCP port
80 (HTTP ). We strongly recommend that you manually download anti-malware engine and definition updates on
your Exchange server prior to placing it in production. For more information, see Download engine and definition
updates.
Q. How often are the malware definitions updated?
A. Each server checks for new malware definitions every hour.
What are some advantages of pairing the built-in malware scanning feature with Exchange Online
Protection (EOP ))?
A. There are several advantages:
The service uses multiple anti-malware engines whereas the built-in anti-malware protection uses a single
engine.
The service has reporting capabilities including malware statistics.
The service provides the message trace feature for self-troubleshooting mail flow problems including
malware detections.
Q. Why did this malware make it past the filter?
A. There are two possible reasons why you may have received malware.
The first, and more likely scenario, is that the attachment received does not contain any active malicious code. In
these situations, some anti-malware engines that run on computers may be more aggressive and stop messages
with truncated payloads.
The second is that the malware you received is a new variant and our anti-malware engine has not yet released a
pattern file for the service to deploy.
Q. How can I submit malware that made it past the filter to Microsoft?
A. If you have received malware such as a virus that made it past the filter, please save a copy of the email message
with its attached virus, go to the Malware Protection Center and submit a sample using the detailed instructions on
that page. When submitting the file, in the Product drop-down list select Other, select the I believe this file
contains malware option, and in the Comments field specify Exchange Server 2013. After we receive the
sample, we'll investigate and if it's determined that the sample contains malware, we'll take corrective action to
prevent the virus from going undetected.
Q. How can I submit a file that I believe was incorrectly detected as malware?
A. Similar to submitting malware, go to the Malware Protection Center and submit a sample using the detailed
instructions on that page. When submitting the file, in the Product drop-down list select Other, select the I
believe this file should not be detected as malware option, and in the Comments field specify Exchange
Server 2013. After we receive the sample, we'll investigate and if it's determined that the sample is clean, we'll take
corrective action to prevent the file from being detected as malware.
Q. I received an email with an attachment that I am not familiar with. Is this malware or can I disregard
this attachment?
A. We strongly advise that you do not open any attachments that you do not recognize. If you would like us to
investigate the attachment, go to the Malware Protection Center and submit the possible malware to us as
described previously.
Q. Where can I get the messages that have been deleted by the malware filter?
A. The messages contain active malicious code and therefore we do not allow access to these messages. They are
simply deleted.
Q. I am not able to receive a specific attachment because it's being falsely filtered by your malware
filter. Can I allow this attachment through via Exchange transport rules?
A. No. Transport rules cannot be used to bypass the malware filter. If you would like this attachment to bypass the
malware filter, send the attachment to the intended recipient within a password protected .zip file. Any password
protected file is bypassed by malware filtering.
Q. Can I turn off the product's built-in anti-malware protection?
A. The built-in anti-malware scanning can be permanently disabled or temporarily bypassed by following the steps
in Disable or bypass anti-malware scanning.

For more information

Configure anti-malware policies
Anti-malware protection
 Download engine and definition updates
6/6/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 administrators can manually download anti-malware engine and definition
(signature) updates. We strongly recommend that you download engine and definition updates on your Exchange
server prior to placing it in production.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You can only use the Shell to perform this procedure. To learn how to open the Shell in your on-premises
Exchange organization, see Open the Shell.
To download updates, your computer must be able to access the Internet and be able to establish a
connection on TCP port 80 (HTTP ). If your organization uses a proxy server for Internet access, see the Use
the Shell to configure proxy server settings for anti-malware updates section in this topic.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-malware" entry in the Anti-spam and anti-malware permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to manually download engine and definition updates

To download engine and definition updates, run the following command:

& $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity <FQDN of server>

This example manually downloads the engine and definition updates on the Exchange server named
mailbox01.contoso.com:

& $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity mailbox01.contoso.com

Optionally, you can use the EngineUpdatePath parameter to download updates from somewhere other than the
default location of http://forefrontdl.microsoft.com/server/scanengineupdate . You can use this parameter to
specify an alternate HTTP address or a UNC path. If you specify a UNC path, the network service must have
access to the path.
This example manually downloads engine and definition updates on the Exchange server named
mailbox01.contoso.com from the UNC path \\FileServer01\Data\MalwareUpdates :
 & $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity mailbox01.contoso.com -
EngineUpdatePath \\FileServer01\Data\MalwareUpdates

How do you know this worked?

In order to verify that updates were downloaded successfully, you need to access Event Viewer and view the event
log. We recommend that you filter only FIPFS events, as described in the following procedure.
1. From the Start menu, click All Programs > Administrative Tools > Event Viewer.
2. In Event Viewer, expand the Windows Logs folder, and then click Application.
3. In the Actions menu, click Filter Current Log.
4. In the Filter Current Log dialog box, from the Event sources drop-down list, select the FIPFS check box,
and then click OK.
If engine updates were downloaded successfully, you will see Event ID 6033, which will appear similar to the
following:
MS Filtering Engine Update process performed a successful scan engine update.

Scan Engine: Microsoft

Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate

Last Update time: 2012-08-16T13:22:17.000Z

Engine Version: 1.1.8601.0

Signature Version: 1.131.2169.0

Use the Shell to configure proxy server settings for anti-malware

updates
If your organization uses a proxy server to control access to the Internet, you need to identify the proxy server so
anti-malware engine and definition updates can be downloaded successfully. Proxy server settings that are
available using the Netsh.exe tool, Internet Explorer connection settings, and the InternetWebProxy parameter on
the Set-ExchangeServer cmdlet don't affect how anti-malware updates are downloaded.
To configure the proxy server settings for anti-malware updates, perform the following steps.
1. Run the following command:

Add-PsSnapin Microsoft.Forefront.Filtering.Management.Powershell

2. Use the Get-ProxySettings and Set-ProxySettings cmdlets to view and configure the proxy server
settings that are used to download anti-malware updates. The Set-ProxySettings cmdlet uses the
following syntax:

Set-ProxySettings -Enabled <$true | $false> -Server <Name or IP address of proxy server> -Port <TCP
port of proxy server>

For example, to configure anti-malware updates to use the proxy server at address 172.17.17.10 on TCP
port 80, run the following command.
 Set-ProxySettings -Enabled $true -Server 172.17.17.10 -Port 80

To verify the proxy server settings, run the Get-ProxySettings cmdlet.

For more information

Configure anti-malware policies
 Configure anti-malware policies
5/28/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

By default, malware filtering is enabled in Microsoft Exchange Server 2013. The default anti-malware policy
controls your company-wide malware filtering settings. As an administrator, you can view and edit, but not delete,
the default anti-malware policy so that it is tailored to best meet the needs of your organization. For greater
granularity, you can also create custom malware filter policies and apply them to specified users, groups, or
domains in your organization. Custom policies always take precedence over the default policy, but you can change
the priority (that is, the running order) of your custom policies. For more information, see Use the EAC to
configure the default anti-malware policy.

What do you need to know before you begin?

We recommend that you manually download anti-malware engine and definition updates on your
Exchange server prior to placing it in production. For more information, see Download engine and
definition updates.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-malware" entry in the Anti-spam and anti-malware permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure the default anti-malware policy

1. In the Exchange admin center (EAC ), navigate to Protection > Malware filter.
2. Do one of the following:
Double-click the default policy in order to edit this company-wide policy.
Click the New icon in order to create a new policy that can be applied to users, groups, and
domains in your organization. You can also edit existing custom policies by double-clicking them.
3. For custom policies only, specify a name for this policy. You can optionally specify a more detailed
description as well. You cannot rename the default policy.

NOTE
When creating a new policy, all configuration settings appear on a single screen, whereas when editing a policy you
must navigate through different screens. The settings are the same in either case, but the rest of this procedure
describes how to access these settings when editing a policy.

4. Click the Settings menu option. In the Malware Detection Response section, use the option buttons to
select the action to take when malware is detected in a message:
 Delete the entire message: Prevents the entire message, including attachments, from being
delivered to the intended recipients. This is the default value.
Delete all attachments and use default alert text: Deletes all message attachments, not just the
infected one, and inserts the following default alert text into a text file that replaces the attachments:
"Malware was detected in one or more attachments included with this email. All attachments have
been deleted."
Delete all attachments and use custom alert text: Deletes all message attachments, not just the
infected one, and inserts a custom message into a text file that replaces the attachments. Selecting
this option enables the Custom alert text field where you must type a custom message.

IMPORTANT
If malware is detected in the message body, the entire message, including all attachments, will be deleted
regardless of which option you select. This action is applied to both inbound and outbound messages.

5. In the Notifications section, you have the option to send a notification email message to senders or
administrators when a message is detected as malware and is not delivered. These notifications are only
sent when the entire message is deleted.
a. In the Sender Notifications section, select the check boxes to Notify internal senders (those
within your organization) or to Notify external senders (those outside your organization) when a
detected message is not delivered.
b. Similarly, in the Administrator Notifications section, select the check boxes to Notify
administrator about undelivered messages from internal senders or to Notify administrator
about undelivered messages from external senders. Specify the email address or addresses of
the administrator in their respective Administrator email address fields after selecting one or both
of these check boxes.
The default notification text is "This message was created automatically by mail delivery software.
Your email message was not delivered to the intended recipients because malware was detected."
The language in which the default notification text is sent is dependent on the locale of the message
being processed.
c. In the Customize Notifications section, you can create customized notification text to be used in
place of the default notification text for sender and administrator notifications. Select the Use
customized notification text check box, and then specify values in the following required fields:
From name: The name you want to be used as the sender of the customized notification.
From address: The email address you want to be used as the sender of the customized
notification.
Messages from internal senders: The Subject and Message of the notification if the
detected message originated from an internal sender.
Messages from external senders: The Subject and Message of the notification if the
detected message originated from an external sender.

NOTE
The default Subject text is "Undeliverable message."

d. For custom policies only, click the Apply to menu item and then create a condition-based rule to
 specify the users, groups, and/or domains for whom to apply this policy. You can create multiple
conditions provided that they are unique.
To select users, select The recipient is. In the subsequent dialog box, select one or more
senders from your company from the user picker list and then click add. To add senders who
aren't on the list, type their email addresses and click Check names. In this box, you can also
use wildcards for multiple email addresses (for example: *@domainname). When you are
done with your selections, click ok to return to the main screen.
To select groups, select The recipient is a member of and then, in the subsequent dialog
box, select or specify the groups. Click ok to return to the main screen.
To select domains, select The recipient domain is and then, in the subsequent dialog box,
add the domains. Click ok to return to the main screen.
You can create exceptions within the rule, for example you can filter messages from all domains
except for a certain domain. Click add exception and then create your exception conditions similar
to the way you created the other conditions.
e. Click Save. A summary of your default policy settings appears in the right pane.

TIP
You can select or clear the check boxes in the ENABLED column to enable or disable your custom policies. All policies
are enabled by default, and the default policy cannot be disabled.
To delete a custom policy, select the policy, click the Delete icon, and then confirm that you want to delete the
policy. The default policy cannot be deleted.
Custom policies always take precedence over the default policy. Custom policies run in the reverse order that you
created them (from oldest to newest), but you can change the priority (running order) of your custom policies by
clicking the up arrow and down arrow. The policy with a PRIORITY of 0 will run first, followed by 1, then 2, and
so on.

How do you know this worked?

The following procedure provides instructions for using the EICAR.TXT antivirus test file to verify that malware
filtering is working correctly.

IMPORTANT
The EICAR.TXT file is not a virus. However, because users often have the need to test that installations function correctly, the
antivirus industry, through the European Institute for Computer Antivirus Research, has adopted the EICAR standard in
order to meet this need.

1. Create a new text file, and then name the file EICAR.TXT.
2. Copy the following line into the text file:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Make sure that this is the only string in the file. When done, you will have a 68-byte file.
 NOTE
If you are using a desktop antivirus program, make sure that the folder you are saving the file to is excluded from
scanning.

3. Attach this file to an email message that will be filtered by Exchange 2013.
Check the recipient mailbox of the test message. Depending on the malware detection response you have
configured, the entire message will be deleted, or the attachment will be deleted and replaced with the alert
text file. Any configured notifications will also be distributed.
4. Delete the EICAR.TXT file after testing is completed so that other users are not unnecessarily alarmed.

For more information

Anti-malware FAQ
Rescan messages already malware scanned by the hosted filtering service
Disable or bypass anti-malware scanning
 Rescan messages already malware scanned by the
hosted filtering service
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can configure Microsoft Exchange Server 2013 to rescan email messages already scanned for malware by the
hosted email filtering service. Enabling this functionality provides another layer of defense against malware
because the cloud-hosted filtering only scans inbound and outbound messages. Internal messages are scanned by
the built-in anti-malware protection capabilities of Exchange 2013. By default, messages scanned in the cloud are
not resubmitted for malware scanning on-premises.

NOTE
This topic only applies to Microsoft Exchange Server 2013 customers who are using cloud-hosted email filtering.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You can only use the Shell to perform this procedure.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-malware" entry in the Anti-spam and anti-malware permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to rescan messages already malware scanned by the

hosted filtering service
1. To rescan messages already malware scanned by the hosted filtering service, run the following command:

Set-MalwareFilteringServer -ForceRescan $true

NOTE
To return to the default setting of not rescanning messages, re-set the above parameter to $false .

How do you know this step worked?

To verify that your Exchange 2013 server is rescanning messages for malware, run the following command and
confirm that it returns a value of True:
Get-MalwareFilteringServer | Format-List ForceRescan
 Disable or bypass anti-malware scanning
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can disable or bypass malware filtering of all email messages in transit on
a server. This must be done on a Mailbox server.
You may want to disable Exchange 2013 malware filtering if you are using another product for malware filtering.
When malware filtering is disabled, the Exchange malware agent is unhooked and not running, and engine
updates are not kept up-to-date.

IMPORTANT
Bypassing malware filtering should only be done when troubleshooting a problem. When malware filtering is bypassed, the
Exchange malware agent remains hooked, and engine updates are kept up-to-date. However, malware filtering is skipped
while you attempt to resolve whatever problems you are encountering. After you have finished troubleshooting, you should
restore malware filtering.

What do you need to know before you begin?

Estimated time to complete each procedure: 15 minutes
You can only use the Shell to perform this procedure.
Disabling or enabling malware filtering restarts the Microsoft Exchange Transport service on the server.
This may temporarily disrupt mail flow in your organization.
Bypassing or restoring malware filtering doesn't require you to restart any services. However, changes to
the setting may take up to 10 minutes to take effect.
If you have multiple Exchange servers performing malware filtering, you must perform these steps on each
server.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Anti-malware" entry in the Anti-spam and anti-malware permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to disable malware filtering on a specific Exchange server

To disable malware filtering, run the following command:

& $env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1
 NOTE
To re-enable malware filtering, use Enable-Antimalwarescanning.ps1 instead of Disable-Antimalwarescanning.ps1 .

How do you know this step worked?

To verify that malware filtering is disabled, run the following command and confirm that it returns a value of False:

Get-TransportAgent "Malware Agent"

Use the Shell to temporarily bypass malware filtering on a specific

Exchange server
IMPORTANT
Bypassing malware filtering should only be done when troubleshooting a problem. You should restore malware filtering after
you have finished troubleshooting.

To temporarily bypass malware filtering, run the following command:

Set-MalwareFilteringServer <ServerIdentity> -BypassFiltering $true

To restore malware filtering, run the following command:

Set-MalwareFilteringServer <ServerIdentity> -BypassFiltering $false

How do you know this step worked?

To verify that malware filtering is being bypassed, run the following command and confirm that it returns a value
of True:

Get-MalwareFilteringServer | Format-List BypassFiltering

 Anti-Virus Software in the Operating System on
Exchange Servers
6/11/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic describes the effects of file-level antivirus programs on computers that are running Microsoft Exchange
Server 2013. If you implement the recommendations described in this topic, you can help enhance the security
and health of your Exchange organization.
File-level scanners are frequently used. However, if they are configured incorrectly, they can cause problems in
Exchange 2013. There are two types of file-level scanners:
Memory-resident file-level scanning refers to a part of file-level antivirus software that is loaded in memory
at all times. It checks all the files that are used on the hard disk and in computer memory.
On-demand file-level scanning refers to a part of file-level antivirus software that you can configure to scan
files on the hard disk manually or on a schedule. Some versions of antivirus software start the on-demand
scan automatically after virus signatures are updated to make sure that all files are scanned with the latest
signatures.
The following problems may occur when you use file-level scanners with Exchange 2013:
File-level scanners may scan a file when the file is being used or at a scheduled interval. This can cause the
scanners to lock or quarantine an Exchange log or a database file while Exchange 2013 tries to use the file.
This behavior may cause a severe failure in Exchange 2013 and may also cause -1018 event log errors.
File-level scanners don't provide protection against email viruses, such as Storm Worm. Storm Worm was a
backdoor Trojan horse program that propagated itself through email messages. The worm joined the
infected computer to a botnet, where the computer was used to send spam in periodic bursts.

Recommendations for using file-level scanning with Exchange 2013

If you're deploying file-level scanners on Exchange 2013 servers, make sure that the appropriate exclusions, such
as directory exclusions, process exclusions, and file name extension exclusions, are in place for both memory-
resident and file-level scanning. This section describes recommended directory exclusions, process exclusions, and
file name extension exclusions.

Directory exclusions
You must exclude specific directories for each Exchange server on which you run a file-level antivirus scanner. This
section describes the directories that you should exclude from file-level scanning.
Mailbox servers
Mailbox databases
Exchange databases, checkpoint files, and log files. By default, these are located in sub-folders
under the %ExchangeInstallPath%Mailbox folder. To determine the location of a mailbox
database, transaction log, and checkpoint file, run the following command:
Get-MailboxDatabase -Server <servername>| Format-List *path*

Database content indexes. By default, these are located in the same folder as the database file.
 Group Metrics files. By default, these files are located in the
%ExchangeInstallPath%GroupMetrics folder.
General log files, such as message tracking and calendar repair log files. By default, these files
are located in subfolders under the %ExchangeInstallPath%TransportRoles\Logs folder and
%ExchangeInstallPath%Logging folder. To determine the log paths being used, run the
following command in the Exchange Management Shell:
Get-MailboxServer <servername> | Format-List *path*

The Offline Address Book files. By default, these are located in subfolders under the
%ExchangeInstallPath%ClientAccess\OAB folder.
IIS system files in the %SystemRoot%\System32\Inetsrv folder.
The Mailbox database temporary folder: %ExchangeInstallPath%Mailbox\MDBTEMP
Members of Database Availability Groups
All the items listed in the Mailbox databases list, and the cluster quorum database that exists
at %Windir%\Cluster.
The witness directory files. These files are located on another server in the environment,
typically a Client Access server that isn't installed on the same computer as a Mailbox server.
By default, the witness directory files are located in
%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>.
Transport service
Log files, for example, message tracking and connectivity logs. By default, these files are
located in subfolders under the %ExchangeInstallPath%TransportRoles\Logs folder. To
determine the log paths being used, run the following command in the Exchange
Management Shell: Get-TransportService <servername> | Format-List *logpath*,*tracingpath*
Pickup and Replay message directory folders. By default, these folders are located under the
%ExchangeInstallPath%TransportRoles folder. To determine the paths being used, run the
following command in the Exchange Management Shell:
Get-TransportService <servername>| Format-List *dir*path*

The queue databases, checkpoints, and log files. By default, these are located in the
%ExchangeInstallPath%TransportRoles\Data\Queue folder.
The Sender Reputation database, checkpoint, and log files. By default, these are located in the
%ExchangeInstallPath%TransportRoles\Data\SenderReputation folder.
The temporary folders that are used to perform conversions:
By default, content conversions are performed in the Exchange server's %TMP% folder.
By default, rich text format (RTF ) to MIME/HTML conversions are performed in
%ExchangeInstallPath%\Working\OleConverter folder.
The content scanning component is used by the Malware agent and data loss prevention
(DLP ). By default, these files are located in the %ExchangeInstallPath%FIP -FS folder.
Mailbox Transport service
Log files, for example, connectivity logs. By default, these files are located in subfolders under the
%ExchangeInstallPath%TransportRoles\Logs\Mailbox folder. To determine the log paths being
used, run the following command in the Exchange Management Shell:
Get-MailboxTransportService <servername> | Format-List *logpath*
 Unified Messaging
The grammar files for different locales, for example en-EN or es-ES. By default, these are
stored in the subfolders in the %ExchangeInstallPath%UnifiedMessaging\grammars folder.
The voice prompts, greetings and informational message files. By default, these are stored in
the subfolders in the %ExchangeInstallPath%UnifiedMessaging\Prompts folder
The voicemail files that are temporarily stored in the
%ExchangeInstallPath%UnifiedMessaging\voicemail folder.
The temporary files generated by Unified Messaging. By default, these are stored in the
%ExchangeInstallPath%UnifiedMessaging\temp folder.
Setup
Exchange Server setup temporary files. These files are typically located in
%SystemRoot%\Temp\ExchangeSetup.
Exchange Search service
Temporary files used by the Exchange Search service and Microsoft Filter Pack to perform file
conversion in a sandboxed environment. These files are located in
%SystemRoot%\Temp\OICE_<GUID>\.
Client Access servers
Web components
For servers using Internet Information Services (IIS ) 7.0, the compression folder that is used
with Microsoft Outlook Web App. By default, the compression folder for IIS 7.0 is located at
%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files.
IIS system files in the %SystemRoot%\System32\Inetsrv folder
Inetpub\logs\logfiles\w3svc
Sub-folders in %SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary
ASP.NET Files
POP3 and IMAP4 protocol logging
POP3 folder: %ExchangeInstallPath%Logging\POP3
IMAP4 folder: %ExchangeInstallPath%Logging\IMAP4
Front End Transport service
Log files, for example, connectivity logs and protocol logs. By default, these files are located in
subfolders under the %ExchangeInstallPath%TransportRoles\Logs\FrontEnd folder. To determine
the log paths being used, run the following command in the Exchange Management Shell:
Get-FrontEndTransportService <servername> | Format-List *logpath*
Setup
Exchange Server setup temporary files. These files are typically located in
%SystemRoot%\Temp\ExchangeSetup.

Process exclusions
Many file-level scanners now support the scanning of processes, which can adversely affect Microsoft Exchange if
the incorrect processes are scanned. Therefore, you should exclude the following processes from file-level
scanners.
PROCESS PATH COMMENTS SERVERS

Dsamain.exe %SystemRoot%\System3 Active Directory Edge Transport servers

2 Lightweight Directory
Services (AD LDS) on
subscribed Edge
Transport servers.

EdgeTransport.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in Transport service worker
process Edge Transport servers

fms.exe %ExchangeInstallPath%F Content scanning Mailbox servers

IP-FS\Bin component that's used
by the Malware agent
and DLP.

hostcontrollerservice.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in\Search\Ceres\HostCo Search Host Controller
ntroller service Client Access servers
(HostControllerService)

inetinfo.exe %SystemRoot%\System3 Internet Information Mailbox servers

2\inetsrv Services (IIS)
Client Access servers

Microsoft.Exchange.Antis %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

pamUpdateSvc.exe in Anti-spam Update
service Edge Transport servers
(MSExchangeAntispamU
pdate)

Microsoft.Exchange.Cont %ExchangeInstallPath%T Content Filter agent Mailbox servers

entFilter.Wrapper.exe ransportRoles\agents\Hy
giene Edge Transport servers

Microsoft.Exchange.Diag %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

nostics.Service.exe in Diagnostics service
(MSExchangeDiagnostics Client Access servers
) Edge Transport servers

Microsoft.Exchange.Direc %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

tory.TopologyService.exe in Active Directory
Topology service Client Access servers
(MSExchangeADTopolog
y)

Microsoft.Exchange.Edge %ExchangeInstallPath%B Microsoft Exchange Edge Transport servers

CredentialSvc.exe in Credential service
(MSExchangeEdgeCrede
ntial)
PROCESS PATH COMMENTS SERVERS

Microsoft.Exchange.Edge %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

SyncSvc.exe in EdgeSync service
(MSExchangeEdgeSync)

Microsoft.Exchange.Imap ExchangeInstallPath%Fro Microsoft Exchange Client Access servers

4.exe ntEnd\PopImap IMAP4 service
(MSExchangeImap4)

Microsoft.Exchange.Imap %ExchangeInstallPath%C Microsoft Exchange Mailbox servers

4service.exe lientAccess\PopImap IMAP4 Backend service
(MSExchangeIMAP4BE)

Microsoft.Exchange.Pop %ExchangeInstallPath%F Microsoft Exchange Client Access servers

3.exe rontEnd\PopImap POP3 service
(MSExchangePop3)

Microsoft.Exchange.Pop %ExchangeInstallPath%C Microsoft Exchange Mailbox servers

3service.exe lientAccess\PopImap POP3 Backend service
(MSExchangePOP3BE)

Microsoft.Exchange.Prot %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

ectedServiceHost.exe in Service Host service
(MSExchangeServiceHos Client Access servers
t) Edge Transport servers

Microsoft.Exchange.RPC %ExchangeInstallPath%B Microsoft Exchange RPC Mailbox servers

ClientAccess.Service.exe in Client Access service
(MSExchangeRPC)

Microsoft.Exchange.Sear %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

ch.Service.exe in Search service
(MSExchangeFastSearch)

Microsoft.Exchange.Servi %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

cehost.exe in Service Host service
(MSExchangeServiceHos Client Access servers
t) Edge Transport servers

Microsoft.Exchange.Stor %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

e.Service.exe in Information Store
service (MSExchangeIS)

Microsoft.Exchange.Stor %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

e.Worker.exe in Information Store
service worker process
PROCESS PATH COMMENTS SERVERS

Microsoft.Exchange.UM. %ExchangeInstallPath%F Microsoft Exchange Client Access servers

CallRouter.exe rontEnd\CallRouter Unified Messaging Call
Router service
(MSExchangeUMCR)

MSExchangeDagMgmt.e %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

xe in DAG Management
service
(MSExchangeDagMgmt)

MSExchangeDelivery.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in Mailbox Transport
Delivery service
(MSExchangeDelivery)

MSExchangeFrontendTra %ExchangeInstallPath%B Microsoft Exchange Client Access servers

nsport.exe in Frontend Transport
service
(MSExchangeFrontEndTr
ansport)

MSExchangeHMHost.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in Health Manager service
(MSExchangeHM) Client Access servers
Edge Transport servers

MSExchangeHMWorker. %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

exe in Health Manager service
worker process Client Access servers
Edge Transport servers

MSExchangeMailboxAssi %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

stants.exe in Mailbox Assistants
service
(MSExchangeMailboxAss
istants)

MSExchangeMailboxRepl %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

ication.exe in Mailbox Replication
service
(MSExchangeMailboxRe
plication)

MSExchangeMigrationW %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

orkflow.exe in Migration Workflow
service
(MSExchangeMigration
Workflow)
PROCESS PATH COMMENTS SERVERS

MSExchangeRepl.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in Replication service
(MSExchangeRepl)

MSExchangeSubmission. %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

exe in Mailbox Transport
Submission service
(MSExchangeSubmission
)

MSExchangeTransport.ex %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

e in Transport service
(MSExchangeTransport) Edge Transport servers

MSExchangeTransportLo %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

gSearch.exe in Transport Log Search
service Edge Transport servers
(MSExchangeTransportL
ogSearch)

MSExchangeThrottling.e %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

xe in Throttling service
(MSExchangeThrottling)

Noderunner.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in\Search\Ceres\Runtime Search service
\1.0 (MSExchangeFastSearch)

OleConverter.exe %ExchangeInstallPath%B Converts rich text Mailbox servers

in format (RTF) messages
to MIME/HTML for
external recipients.

ParserServer.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in\Search\Ceres\ParserSe Search service
rver (MSExchangeFastSearch)

Powershell.exe C:\Windows\System32\ Exchange Management Mailbox servers

WindowsPowerShell\v1. Shell
0 Client Access servers
Edge Transport servers

ScanEngineTest.exe %ExchangeInstallPath%F Content scanning Mailbox servers

IP-FS\Bin component that's used
by the Malware agent
and DLP.
 PROCESS PATH COMMENTS SERVERS

ScanningProcess.exe %ExchangeInstallPath%F Content scanning Mailbox servers

IP-FS\Bin component that's used
by the Malware agent
and DLP.

TranscodingService.exe %ExchangeInstallPath%C WebReady Document Mailbox servers

lientAccess\Owa\Bin\Doc Viewing in Outlook Web
umentViewing App.

UmService.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in Unified Messaging
service
(MSExchangeUM)

UmWorkerProcess.exe %ExchangeInstallPath%B Microsoft Exchange Mailbox servers

in Unified Messaging
service worker process

UpdateService.exe %ExchangeInstallPath%F Content scanning Mailbox servers

IP-FS\Bin component that's used
by the Malware agent
and DLP.

W3wp.exe %SystemRoot%\System3 Internet Information Mailbox servers

2\inetsrv Services (IIS)
Client Access servers

File name extension exclusions

In addition to excluding specific directories and processes, you should exclude the following Exchange-specific file
name extensions in case directory exclusions fail or files are moved from their default locations.
Application-related extensions:
.config
.dia
.wsb
Database-related extensions:
.chk
.edb
.jrs
.jsl
.log
.que
Offline address book-related extensions:
.lzx
Content Index-related extensions:
.ci
.dir
.wid
.000
.001
.002
Unified Messaging-related extensions:
.cfg
.grxml
Group Metrics-related extensions:
.dsc
.txt
 Mail flow
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, mail flow occurs through the transport pipeline. The transport pipeline is a
collection of services, connections, components, and queues that work together to route all messages to the
categorizer in the Transport service on a Mailbox server inside the organization.
Looking for a list of all mail flow topics? See Mail flow documentation.
For information about how to configure mail flow in a new Exchange 2013 organization, see Configure mail
flow and client access.

The transport pipeline

The transport pipeline consists of the following services:
Front End Transport service on Client Access servers: This service acts as a stateless proxy for all
inbound and (optionally) outbound external SMTP traffic for the Exchange 2013 organization. The Front
End Transport service doesn't inspect message content, doesn't communicate with the Mailbox Transport
service on Mailbox servers, and doesn't queue any messages locally.
Transport service on Mailbox servers: This service is virtually identical to the Hub Transport server
role in previous versions of Exchange. The Transport service handles all SMTP mail flow for the
organization, performs message categorization, and performs message content inspection. Unlike
previous versions of Exchange, the Transport service never communicates directly with mailbox
databases. That task is now handled by the Mailbox Transport service. The Transport service routes
messages between the Mailbox Transport service, the Transport service, the Front End Transport service,
and (depending on your configuration) the Transport service on Edge Transport servers. The Transport
service on Mailbox servers is described in more detail later in this topic.
Mailbox Transport service on Mailbox servers: This service consists of two separate services: the
Mailbox Transport Submission service and Mailbox Transport Delivery service. The Mailbox Transport
Delivery service receives SMTP messages from the Transport service on the local Mailbox server or on
other Mailbox servers, and connects to the local mailbox database using an Exchange remote procedure
call (RPC ) to deliver the message. The Mailbox Transport Submission service connects to the local
mailbox database using RPC to retrieve messages, and submits the messages over SMTP to the
Transport service on the local Mailbox server, or on other Mailbox servers. The Mailbox Transport
Submission service has access to the same routing topology information as the Transport service. Like
the Front End Transport service, the Mailbox Transport service also doesn't queue any messages locally.
Transport service on Edge Transport servers: This service is very similar to the Transport service on
Mailbox servers. If you have an Edge Transport server installed in the perimeter network, all mail coming
from the Internet or going to the Internet flows through the Transport service Edge Transport server. This
service is described in more detail later in this topic.
The following figure shows the relationships among the components in the Exchange 2013 transport pipeline.
Overview of the transport pipeline in Exchange 2013.
Messages from external senders
Messages from outside the organization enter the transport pipeline through a Receive connector in the Front
End Transport service on the Client Access server and are then routed to the Transport service on the Mailbox
server.
If you have an Exchange 2013 Edge Transport server installed in the perimeter network, messages from outside
the organization enter the transport pipeline through a Receive connector in the Transport service on the Edge
Transport server. Where the messages go next depends on how your internal Exchange servers are configured.
Mailbox server and Client Access server installed on the same computer: In this configuration, the
Client Access server is used for inbound mail flow. Mail flows from the Transport service on the Edge
Transport server to the Front End Transport service on the Client Access server, and then to the Transport
service on the Mailbox server.
Mailbox server and Client Access server installed on different computers: In this configuration,
the Client Access server is bypassed for inbound mail flow. Mail flows from the Transport service on the
Edge Transport server to the Transport service on the Mailbox server.

NOTE
If you have an Exchange 2010 or Exchange 2007 Edge Transport server installed in your perimeter network, mail flow
always occurs directly between the Edge Transport server and the Transport service on the Mailbox server. For more
information, see Use an Exchange 2010 or 2007 Edge Transport server in Exchange 2013.
Messages from internal senders
SMTP messages from inside the organization enter the transport pipeline through the Transport service on a
Mailbox server in one of the following ways:
Through a Receive connector.
From the Pickup directory or the Replay directory.
From the Mailbox Transport service.
Through agent submission.
The message is routed based on the routing destination or delivery group. For more information, see Mail
routing.
If the message has external recipients, the message is routed from the Transport service on the Mailbox server
to the Internet, or from the Mailbox server to the Front End Transport service on a Client Access server and
then to the Internet if the Send connector is configured to proxy outbound connections through the Client
Access server. For more information, see Create a Send connector for email sent to the Internet.
If you have an Edge Transport server installed in the perimeter network, messages that have external recipients
are never routed through the Front End Transport service on a Client Access server. The message is routed from
the Transport service on a Mailbox server to the Transport service on the Edge Transport server

Transport service on Mailbox servers

Every message that's sent or received in an Exchange 2013 organization must be categorized in the Transport
service on a Mailbox server before it can be routed and delivered. After a message has been categorized, it's put
in a delivery queue for delivery to the destination mailbox database, the destination database availability group
(DAG ), Active Directory site, or Active Directory forest, or to the destination domain outside the organization.
The Transport service on a Mailbox server consists of the following components and processes:
SMTP Receive: When messages are received by the Transport service, message content inspection is
performed and antispam inspection is performed if is enabled. The SMTP session has a series of events
that work together in a specific order to validate the contents of a message before it's accepted. After a
message has passed completely through SMTP Receive and isn't rejected by receive events, or by an
antispam agent, it's put in the Submission queue.
Submission: Submission is the process of putting messages into the Submission queue. The categorizer
picks up one message at a time for categorization. Submission happens in three ways:
From SMTP Receive through a Receive connector.
Through the Pickup directory or the Replay directory. These directories exist on Mailbox servers
and Edge Transport servers. Correctly formatted message files that are copied into the Pickup
directory or the Replay directory are put directly into the Submission queue.
Through a transport agent.
Categorizer: The categorizer picks up one message at a time from the Submission queue. The
categorizer completes the following steps:
Recipient resolution, which includes top-level addressing, expansion, and bifurcation.
Routing resolution.
Content conversion.
 Additionally, transport rules that are defined by the organization are applied. After messages have
been categorized, they're put into a delivery queue that's based on the destination of the message.
Messages are queued by the destination mailbox database, DAG, Active Directory site, Active
Directory forest or external domain.
SMTP Send: How messages are routed from the Transport service depends on the location of the
message recipients relative to the Mailbox server where categorization occurred. The message could be
routed to one of the following locations:
To the Mailbox Transport service on the same Mailbox server.
To the Mailbox Transport service on a different Mailbox server that's part of the same DAG.
To the Transport service on a Mailbox server in a different DAG, Active Directory site, or Active
Directory forest.
For delivery to the Internet through a Send connector on the same Mailbox server, through the
Transport service on a different Mailbox server, through the Front End Transport service on a
Client Access server, or through the Transport service on an Edge Transport server in the
perimeter network.

Transport service on Edge Transport servers

The components of the Transport service on Edge Transport servers are identical to the components of the
Transport service on Mailbox servers. However, what actually happens during each stage of processing on Edge
Transport servers is different. The differences are described in the following list.
SMTP Receive: When an Edge Transport server is subscribed to an internal Active Directory site, the
default Receive connector is automatically configured to accept mail from internal Mailbox servers and
from the Internet. When Internet messages arrive at the Edge Transport server, anti-spam agents filter
connections and message contents, and help identify the sender and the recipient while the message is
being accepted into the organization. The anti-spam agents are installed and enabled by default.
Additional attachment filtering and connection filtering features are available, but built-in malware
filtering is not. Also, transport rules are controlled by the Edge Rule agent. Compared to the Transport
Rule agent on Mailbox servers, only a small subset of transport rule conditions are available on Edge
Transport servers. But, there are unique transport rule actions related to SMTP connections that are
available only on Edge Transport servers.
Submission: On an Edge Transport server, messages typically enter the Submission queue through a
Receive connector. However, the Pickup directory and the Replay directory are also available.
Categorizer: On an Edge Transport server, categorization is a short process in which the message is put
directly into a delivery queue for delivery to internal or external recipients.
SMTP Send: When an Edge Transport server is subscribed to an internal Active Directory site, two Send
connectors are automatically created and configured. One is responsible for sending outbound mail to
Internet recipients; the other is responsible for sending inbound mail from the Internet to internal
recipients. Inbound mail is sent to the Transport service on an available Mailbox server in the subscribed
Active Directory site.

Mail flow documentation

The following table contains links to topics that will help you learn about and manage mail flow in Exchange
2013.
TOPIC DESCRIPTION

Mail routing Mail routing describes how messages are transmitted

between messaging servers.

Connectors Connectors define where and how messages are

transmitted to and from Exchange servers.

Domains Accepted domains define the SMTP address spaces that

are used in the Exchange organization. Remote domains
configure message formatting and encoding settings for
messages sent to external domains.

Transport agents Transport agents act on messages as they travel

through the Exchange transport pipeline.

Transport high availability Transport high availability describes how Exchange 2013
keeps redundant copies of messages during transit and
after delivery.

Transport logs Transport logs record what happens to messages as

they flow through the transport pipeline.

Manage message approval Moderated transport requires approval for messages

sent to specific recipients.

Content conversion Content conversion controls the Transport Neutral

encoding format (TNEF) message conversion options for
external recipients, and the MAPI conversion options for
internal recipients.

DSNs and NDRs in Exchange 2013 Delivery status notifications (DSNs) are the system
messages that are sent to message senders, for
example, non-delivery reports (NDRs).

Track messages with delivery reports Delivery Reports is a message tracking tool that you can
use to search for delivery status on email messages sent
to or from users in your organization's address book,
with a certain subject. You can track delivery information
about messages sent by or received from any specific
mailbox in your organization.

Message size limits This topic describes the size and individual component
limits that are imposed on messages.

Queue Viewer You use the Queue Viewer in the Exchange Toolbox to
view and act upon queues and message in queues.
TOPIC DESCRIPTION

Pickup directory and Replay directory The pickup and replay directories are used to insert
message files into the transport pipeline.

Use an Exchange 2010 or 2007 Edge Transport server in This topic describes the considerations for using an Edge
Exchange 2013 Transport server from previous versions of Exchange in
Exchange 2013.
 Mail routing
6/14/2019 • 22 minutes to read • Edit Online

Applies to: Exchange Server 2013

The primary task of the Transport service that exists on all Mailbox servers in your Microsoft Exchange Server
2013 organization is to route messages received from users and external sources to their ultimate destinations.
Routing decisions are made during message categorization. The categorizer is a component of the Transport
service on a Mailbox server that processes all incoming messages and determines what to do with the message
based on information about their destinations.
Routing in Exchange 2013 is now fully aware of Database Availability Groups (DAGs), and uses DAG
membership as a routing boundary. Why? In Exchange 2013, all Mailbox servers host the Transport service.
Therefore, when a Mailbox server belongs to a DAG, the primary mechanism for routing messages is closely
aligned with the DAG. And when a DAG spans multiple Active Directory sites, using the Active Directory site as
the primary routing boundary is inefficient. Exchange 2013 also uses Active Directory site membership as a
routing boundary for Mailbox servers that don't belong to DAGs, and for routing interoperability with previous
versions of Exchange. Other notable changes to Exchange 2013 routing include:
The Transport service on a Mailbox server never communicates directly with a mailbox database. Instead,
the Transport service communicates with the Mailbox Transport service on the Mailbox server. Only the
Mailbox Transport service communicates with the mailbox database on the local Mailbox server. When the
Mailbox server is a member of a DAG, only the Mailbox Transport service on the Mailbox server that holds
the active copy of the mailbox database accepts the message for the destination recipient.
Remote procedure calls (RPCs) are only used by the Mailbox Transport service when sending messages to
or receiving messages from the local mailbox database. When the Mailbox server is a member of a DAG,
the Mailbox Transport service only uses RPCs to communicate locally with the active copies of the mailbox
databases. In other words, RPC is never used for cross-server communication. Instead, the Mailbox
Transport service and the Transport service on different Mailbox servers always communicate using
SMTP.
Exchange 2013 uses more precise queuing for remote destinations. Instead of using one queue for all
destinations in a remote Active Directory site, Exchange 2013 queues messages for specific destinations
within the Active Directory site, such as individual Send connectors.
Linked connectors have been deprecated. A linked connector was a Receive connector that was linked to a
Send connector. All messages received by the Receive connector were automatically forwarded to the
Send connector.

Routing components
When a message is received by the Transport service on an Exchange 2013 Mailbox server, the message must be
categorized. The first phase of message categorization is recipient resolution. After the recipient has been
resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that
destination. Routing in Exchange 2013 has been generalized for increased flexibility and decreased complexity by
introducing the concepts of routing destinations and delivery groups.

Routing destinations
In Exchange 2013, the ultimate destination for a message is called a routing destination. The following routing
destinations exist in Exchange 2013:
A mailbox database: This is the routing destination for any recipient with a mailbox on a Mailbox server
in the Exchange organization. In Exchange 2013, public folders are a type of mailbox, so routing messages
to public folder recipients is the same as routing messages to mailbox recipients.
A connector: A connector is a Send connector for SMTP messages when used as a routing destination. A
Delivery Agent connector or a Foreign connector is used as a routing destination for non-SMTP
messages.
A distribution group expansion server: This is the routing destination when a distribution group has a
designated expansion server that's responsible for expanding the membership list of the group. A
distribution group expansion server is always a Hub Transport server or an Exchange 2013 Mailbox server.
Note that these same routing destinations also existed in previous versions of Exchange.

Delivery groups
Each routing destination in Exchange 2013 has a collection of one or more transport servers that are responsible
for delivering messages to that routing destination. This collection of transport servers is called a delivery group.
A transport server could be an Exchange 2013 Mailbox server, or an Exchange 2010 server or Exchange 2007
server that has the Hub Transport server role installed. When the routing destination is a mailbox database, the
transport servers in the delivery group are the same version of Exchange as the mailbox database. When the
routing destination is a connector or a distribution group expansion server, the delivery group may contain a
mixture of Exchange 2013 Mailbox servers and Exchange 2010 or Exchange 2007 Hub Transport servers. How
the message is routed depends on the relationship between the source transport server and the destination
delivery group:
If the source transport server is in the destination delivery group, the routing destination itself is the next
hop for the message. The message is delivered by the source transport server to the mailbox database or
connector on a transport server in the delivery group. Note that when a distribution group expansion
server is the routing destination, the distribution group is already expanded by the time messages reach
the routing stage of categorization on the distribution group expansion server. Therefore, the routing
destination from the distribution group expansion server is always a mailbox database or a connector.
If the source transport server is outside the destination delivery group, the message is relayed along the
least-cost routing path to the destination delivery group. Depending on the size and complexity of the
Exchange topology, the message is relayed to other transport servers along the least cost routing path, or
the message is relayed directly to a transport server in the destination delivery group.
The following types of delivery groups exist in Exchange 2013:
Routable DAG: This is a collection of Exchange 2013 Mailbox servers that belong to one DAG. The
mailbox databases in the DAG are the routing destinations that are serviced by this delivery group. After
the message arrives at the Transport service on a Mailbox server that belongs to the DAG, the Transport
service routes the message to the Mailbox Transport service on the Mailbox server in the DAG that
currently holds the active copy of the destination mailbox database. The Mailbox Transport service on the
destination Mailbox server then delivers the message to the local mailbox database. Although a DAG may
contain Mailbox servers located in different Active Directory sites, the DAG is the delivery group
boundary.
Mailbox delivery group: This is a collection of Exchange servers of the same version located in one
Active Directory site. The Active Directory site is the delivery group boundary. The routing destinations
and the delivery groups that service them are separated by the major release versions of Exchange in the
Active Directory site. The mailbox databases located on Exchange 2010 Mailbox servers are serviced by
the Exchange 2010 Hub Transport servers located in the Active Directory site. The mailbox databases
 located on Exchange 2007 Mailbox servers are serviced by the Exchange 2007 Hub Transport servers
located in the Active Directory site. The mailbox databases located on Exchange 2013 Mailbox servers in
Active Directory site that don't belong to a DAG are serviced by the Transport service on Exchange 2013
Mailbox servers in the Active Directory site. How the message is delivered to the mailbox database
depends on version of Exchange:
Exchange 2013: After the message arrives at the destination Mailbox server in the destination
Active Directory site, the Transport service uses SMTP to transfer the message to the Mailbox
Transport service. The Mailbox Transport service then delivers the message to the local mailbox
database using RPC.
Exchange 2010 or Exchange 2007: After the message arrives at a random Hub Transport server
of the same version in the destination Active Directory site, the store driver on the Hub Transport
server uses RPC to write the message to the mailbox database.
Connector source servers: This is a mixed collection of Exchange 2010 or Exchange 2007 Hub Transport
servers, or Exchange 2013 Mailbox servers that are scoped as the source server for a Send connector, a
Delivery Agent connector or a Foreign connector. The connector is the routing destination that's serviced
by this routing group. When a connector is scoped to a specific server, only that server is allowed to route
messages to destination defined by the connector. This delivery group may contain Exchange 2010 or
Exchange 2007 Hub Transport servers, or Exchange 2013 Mailbox servers located in different Active
Directory sites.
AD site: In some circumstances, an Active Directory site isn't the ultimate destination of a message, but
the message must pass through an Exchange 2010 or Exchange 2007 Hub Transport server or Exchange
2013 Mailbox server in that Active Directory site. Those circumstances include:
When the Active Directory site is configured as a hub site. When the hub site exists on the least-cost
routing path for message delivery, the messages queue and are processed by a transport server in
the hub site before they're relayed to their ultimate destination.
When an Edge Transport server is subscribed to the Active Directory site. These subscribed Edge
Transport servers aren't directly accessible from other Active Directory sites. Note that the Edge
Transport server could be Exchange 2013, Exchange 2010 or Exchange 2007.

NOTE
Delayed fan-out is only used when the delivery group is an Active Directory site. Delayed fan-out attempts
to reduce the number of message transmissions when multiple recipients share any part of the least-cost
routing path.

Server list: This is a collection of one or more Exchange 2010 or Exchange 2007 Hub Transport servers or
Exchange 2013 Mailbox servers that are configured as distribution group expansion servers. The
distribution group expansion server is the routing destination serviced by this delivery group.
Delivery group membership isn't mutually exclusive. For example, an Exchange 2013 Mailbox server that's a
member of a DAG can also be the source server of a scoped Send connector. This Mailbox server would belong
to the routable DAG delivery group for the mailbox databases in the DAG, and also a connector source server
delivery group for the scoped Send connector.
The following table maps the routing destinations to the delivery group based on the version of Exchange
involved:
 EXCHANGE 2010 OR
EXCHANGE 2013 MAILBOX EXCHANGE 2007 HUB EDGE TRANSPORT SERVER IN
SERVER TRANSPORT SERVER THE PERIMETER NETWORK

Mailbox database in a Routable DAG Mailbox delivery group n/a

DAG

Mailbox database not in Mailbox delivery group Mailbox delivery group n/a
a DAG

Connector Connector source Connector source AD site

servers servers

Distribution group Server list Server list n/a

expansion server

Queues
From the perspective of the sending server, each delivery queue represents the destination for a particular
message. When the Transport service on the Exchange 2013 Mailbox server selects the destination for a
message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message
is being sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving
server also performs message categorization and queues the message for delivery. After a message is queued,
you can examine the delivery type for a particular queue to determine whether a message will be relayed again
when it reaches the next hop destination. Every unique value of the NextHopSolutionKey attribute corresponds
to a separate delivery queue.
For more information, see the "NextHopSolutionKey" section in the Queues topic.

Routing messages
When a message needs to be delivered to a remote delivery group, a routing path must be determined for the
message. Exchange 2013 uses the following logic to select the routing path for a message. This logic is basically
unchanged from Exchange 2010:
1. Calculate the least-cost routing path by adding the cost of the IP site links that must be traversed to reach
the destination. If the destination is a connector, the cost assigned to the address space is added to the cost
to reach the selected connector. If multiple routing paths are possible, the routing path with the lowest
aggregate cost is used.
2. If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated
and the routing path with the least number of hops is used.
3. If more than one routing path is still available, the name assigned to the Active Directory sites before the
destination is considered. The routing path where the Active Directory site nearest the destination is
lowest in alphanumeric order is used. If the site nearest the destination is the same for all routing paths
being evaluated, an earlier site name is considered.
In Exchange 2010, each message recipient is always associated with only one Active Directory site, and there is
only one least cost routing from the source Active Directory site to the destination Active Directory site. In
Exchange 2013, a delivery group may span multiple Active Directory sites, and there may be multiple least-cost
routing paths to those multiple Active Directory sites. Exchange 2013 designates a single Active Directory site in
the destination delivery group as the primary site. The primary site is closest Active Directory site based on the
routing logic described earlier. To successfully route messages between delivery groups, Exchange 2013 takes the
following issues into consideration:
The presence of one or more hub sites along the least-cost routing path: If the least-cost routing
path to the primary site contains any hub sites, the message must be routed through the hub sites. The
closest hub site along the least-cost routing path is selected as a new delivery group of the type AD site,
which includes all transport servers in the hub site. After the message traverses the hub site, routing of the
message along the least-cost routing path continues. If the primary site happens to be a hub site, the
primary site is still considered a hub site for the following reasons:
If the destination delivery group spans multiple Active Directory sites, the source server should
only attempt to connect to the servers in the hub site.
The servers in the hub site that actually belong to the target delivery group are preferred.
As in previous version of Exchange, any hub sites that aren't in the least-cost routing path to the
primary site are ignored.
The target Exchange server to select in the destination routing group: When the destination
delivery group spans multiple Active Directory sites, the routing path to specific servers within the
delivery group may have different costs. Servers located in the closest Active Directory site are selected as
the target servers for the delivery group based on the least-cost routing path, and the Active Directory site
those servers are in is selected as the primary site.
Fallback options when connection attempts to all servers in the destination routing group fail: If
the destination delivery group spans multiple Active Directory sites, the first fallback option is all other
servers in the destination delivery group in other Active Directory sites that aren't selected as target
servers. Server selection is made based on the cost of the routing path to those other Active Directory
sites. If the destination delivery group has any servers in the local Active Directory site, there are no other
fallback options because the message is already as close to the target routing destination as possible. If the
destination delivery group has servers in remote Active Directory sites, the option is to try to connect to all
other servers in the primary site. If that fails, a backoff path in the least-cost routing path to the primary
site is used. Exchange 2013 tries to deliver the message as close to the destination as possible by backing
off, hop by hop, along the least-cost routing path until a connection is made.

Routing messages between Active Directory sites

The way that Exchange 2013 routes messages between Active Directory sites is virtually the same as Exchange
2010. For more information, see Route mail between Active Directory sites.

Routing in the Front End Transport service on Client Access servers

This acts as a stateless proxy for all inbound and (optionally) outbound external SMTP traffic for the Exchange
2013 organization. For outgoing messages, the Transport service uses Send connectors to communicate with the
Front End Transport service on a Client Access server. Specifically, outgoing messages are proxied through the
Front End Transport service when the FrontEndProxyEnabled parameter on an applicable Send connector is set
to $true , or when the Proxy through Client Access server option is selected in the Send Connector
properties in the Exchange admin center (EAC ). Any Client Access server in the local Active Directory site will be
selected. Note that the Front End Transport service doesn't have Send connectors.
For incoming messages, the Front End Transport service must quickly find a single, healthy Transport service on
a Mailbox server to receive the message transmission, regardless of the number or type of recipients. Failure to
do so results in the email service being perceived as unavailable by the external senders. Like the Transport
service, the Front End Transport service loads routing tables based on information from Active Directory, and
uses delivery groups to determine how to route messages. However, the routing tables used by the Front End
Transport service have the following unique characteristics:
The Front End Transport service is never considered a member of a delivery group, even when the
Mailbox server and the Client access server are installed on the same physical server. This forces the Front
End Transport service to communicate with the Transport service only.
The routing tables don't contain any Send connector routes.
The routing tables contain a special list of Mailbox servers in the local Active Directory site for fast fail-
over purposes.
Routing in the Front End Transport service resolves message recipients to mailbox databases. The list of Mailbox
servers used by the Front End Transport service is based on the mailbox databases of the message recipients.
Note that it's possible that none of the recipients have mailboxes, for example, if the recipient is a distribution
group or a mail user. For each mailbox database, the Front End Transport service looks up the delivery group and
the associated routing information. The delivery groups used by the Front End Transport service are:
Routable DAG
Mailbox delivery group
AD site
Depending on the number and type of recipients, the Front End Transport service performs one of the following
actions:
For messages with a single mailbox recipient, select a Mailbox server in the target delivery group, and give
preference to the Mailbox server based on the proximity of the Active Directory site. Routing the message
to the recipient may involve routing the message through a hub site.
For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the
closest delivery group, based on the proximity of the Active Directory site. Note that message bifurcation
doesn't occur in Front-End Transport, so only one Mailbox server is ultimately selected, regardless of
number of recipients in a message.
If the message has no mailbox recipients, select a random Mailbox server in the local Active Directory site.

Routing in the Mailbox Transport service on Mailbox servers

This consists of two separate services: the Mailbox Transport Submission service and Mailbox Transport Delivery
service. For incoming messages, the Mailbox Transport Delivery service receives SMTP messages from the
Transport service, and connects to the local mailbox database using RPC to deliver the message. For outgoing
messages, the Mailbox Transport Submission service connects to the local mailbox database using RPC to
retrieve messages, and submits the messages over SMTP to the Transport service. The Mailbox Transport service
is stateless, and doesn't queue any messages locally.
Like the Transport service, the Mailbox Transport service loads routing tables based on information from Active
Directory, and uses delivery groups to determine how to route messages. However, there are routing aspects that
are unique to the Mailbox Transport service:
Because the Transport service and the Mailbox Transport service exist on the same Exchange 2013
Mailbox server, the Mailbox Transport service always belongs to the same delivery group as the Mailbox
server. This delivery group is referred to as the local delivery group.
The Mailbox Transport Submission service doesn't automatically send messages to the Transport service
on the local Mailbox server or on other Mailbox servers in its own local delivery group. The Mailbox
Transport Submission service has access to the same routing topology information as the Transport
service, so the Mailbox Transport submission service can send messages to the Transport service on
 Mailbox servers outside the delivery group. The Mailbox servers in the local delivery group are used as
fallback options, and for delivery to non-mailbox recipients.
The Mailbox Transport service only communicates with the Transport service on Exchange 2013 Mailbox
servers.
The Mailbox Transport service only communicates with mailbox databases on the local Exchange 2013
Mailbox server. The Mailbox Transport service never communicates with mailbox databases on other
Mailbox servers.
When a user sends a message from their mailbox, the Mailbox Transport Submission service resolves the
message recipients to mailbox databases. The list of Mailbox servers used by the Mailbox Transport Submission
service is based on the mailbox databases of the message recipients. Note that it's possible that none of the
recipients have mailboxes, for example, if the recipient is a distribution group or a mail user. For each mailbox
database, the Mailbox Transport Submission service looks up the delivery group and the associated routing
information. The delivery groups used by the Mailbox Transport Submission service are:
Routable DAG
Mailbox delivery group
AD site
Depending on the number and type of recipients, the Mailbox Transport Submission service performs one of the
following actions:
For messages with a single mailbox recipient, select a Mailbox server in the target delivery group, and give
preference to the Mailbox server based on the proximity of the Active Directory site. Routing the message
to the recipient may involve routing the message through a hub site.
For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the
closest delivery group, based on the proximity of the Active Directory site.
If the message has no mailbox recipients, select a Mailbox server in the local delivery group.
When the Mailbox Transport Delivery service receives a message from the Transport service, it accepts or rejects
the message for delivery to a local mailbox database. The Mailbox Transport Delivery service can deliver the
message if the recipient resides in an active copy of a local mailbox database. But, if the recipient doesn't reside in
an active copy of a local mailbox database, the Mailbox Transport Delivery service can't deliver the message, and
must provide a non-delivery response to the Transport service. For example, if the active copy of the mailbox
database recently moved to another server, the Transport service might erroneously transmit a message to a
Mailbox server that now holds an inactive copy of the mailbox database. The non-delivery responses that the
Mailbox Transport Delivery service returns to the Transport service include:
Retry delivery
Generate an NDR
Reroute the message

Routing in the Transport service on Edge Transport servers

If you have an Edge Transport server installed in your perimeter network, the Transport service on the Edge
Transport server provides SMTP relay and smart host services for all Internet-facing mail flow. Messages that
come and go from the Internet are queued locally on the Edge Transport server. The queues correspond to
external domains or Send connectors. For more information, see the "NextHopSolutionKey" section in the
Queues topic.
Typically, when you install an Edge Transport server in your perimeter network, you subscribe the Edge Transport
server to an Active Directory site. The Active Directory site contains the Mailbox servers that will relay messages
to and from the Edge Transport server. The Edge Subscription process creates an Active Directory site
membership affiliation for the Edge Transport server. The site affiliation enables the Mailbox servers in the Active
Directory site to relay messages to the Edge Transport server for delivery to the Internet without having to
configure explicit Send connectors.
In multi-site configurations, outbound mail from internal recipients to external recipients is first routed to the
subscribed Active Directory site. The target Active Directory site is the delivery group. The routing destination is
the intra-organization Send connector in the Transport service on any of the Mailbox servers in the subscribed
Active Directory site. The intra -organization Send connector is special Send connector that exists in the Transport
service on every Mailbox server. This Send connector is implicitly created, invisible, requires no management,
and is used to relay messages between Exchange servers.
Outbound mail for external recipients is routed from the Mailbox server to the Edge Transport server. The Client
Access server is not involved in routing mail to a subscribed Edge Transport server. Mail is transmitted from the
intra-organization Send connector in the Transport service on the Mailbox server to a Receive connector in the
Transport service on the Edge Transport server. On a subscribed Edge Transport server, the default Receive
connector is configured to listen for connections from internal Mailbox servers in the subscribed Active Directory
site and anonymous connections from the Internet. After the message is categorized by the Transport service on
the Edge Transport server, the message is queued locally for delivery to the Internet by using the dedicated Send
connector that's created during the Edge Subscription.
Inbound mail from external recipients arrives on the Edge Transport through the default Receive connector, and
the messages are categorized and queued for delivery. The messages are relayed through the dedicated Send
connector that's created by the Edge Subscription to send mail into the Exchange organization. Where the
messages go next depends on how the internal Exchange servers are configured.
Mailbox server and Client Access server installed on the same computer: In this configuration, the
Client Access server is used for inbound mail flow. Mail flows from the Send connector in the Transport
service on the Edge Transport server to the default Receive connector in the Front End Transport service
on the Client Access server, and then to the default Receive connector in the Transport service on the
Mailbox server.
Mailbox server and Client Access server installed on different computers: In this configuration, the
Client Access server is bypassed for inbound mail flow. Mail flows from the Send connector in the
Transport service on the Edge Transport server to the default Receive connector in the Transport service
on the Mailbox server.
If you have an Exchange 2007 or Exchange 2010 Edge Transport server installed in the perimeter network,
inbound and outbound mail flow always occurs directly between the Edge Transport server and the Mailbox
server. The Client Access server isn't used.
 Planning to use Active Directory sites for routing mail
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 recognizes Active Directory sites and database availability groups (DAGs) as
routing boundaries. However, Exchange 2013 still uses Active Directory site topology to determine how messages
are transported between Exchange servers in different DAGs or sites within the organization. For more
information, see Mail routing.
The Transport service on a Mailbox server provides message transport inside the Exchange organization. When
you're deploying a pure Exchange 2013 organization, or introducing Exchange 2013 into a pure Exchange Server
2010 organization, no additional configuration is required to establish routing in the forest.

How Exchange 2013 uses Active Directory site membership

Exchange 2013 is a site-aware application. Site-aware applications can determine their own Active Directory site
membership and the site membership of other servers by querying Active Directory. Exchange 2013 uses site
membership to determine which domain controllers and global catalog servers to use for processing Active
Directory queries. Additionally, when a server running Exchange has to determine the Active Directory site
membership of another Exchange server, it can query Active Directory to retrieve the site name.
In Exchange 2013, the Microsoft Exchange Active Directory Topology service is responsible for updating the site
attribute of the Exchange server object. Because the Active Directory site membership is a server object attribute,
Exchange doesn't have to query DNS to resolve a server address to a subnet associated with an Active Directory
site. Stamping the Active Directory site attribute on an Exchange server object also enables Active Directory site
membership to be assigned to a server that isn't a domain member, such as a subscribed Edge Transport server.
The Exchange 2013 servers use Active Directory site membership information as follows:
Mail submission: The Mailbox Transport Submission service on an Exchange 2013 Mailbox server uses
Active Directory site membership information to determine the other Exchange 2013 Mailbox servers that
are located in the same Active Directory site. If the source Mailbox server doesn't belong to a DAG, or if the
DAG doesn't span multiple Active Directory sites, the Mailbox Transport Submission service on the source
Mailbox server submits messages for routing and transport to the Transport service on an Exchange 2013
Mailbox server in the same Active Directory site.
Mail delivery: The Transport service on an Exchange 2013 Mailbox server performs recipient resolution
and queries Active Directory to match an email address to a recipient account. The recipient account
information includes the fully qualified domain name (FQDN ) of the user's mailbox database. The Transport
service queries Active Directory to determine the Active Directory site of the user's mailbox database. If the
mailbox database doesn't belong to a DAG, it will deliver the message to that Mailbox server. Otherwise, it
will relay the message to another Mailbox server in the same site as the target Mailbox server for delivery.
Message routing: The Transport service on Exchange 2013 Mailbox servers retrieves information from
Active Directory to determine how mail should be routed inside the organization. Exchange 2013 uses the
concept of delivery groups to determine where and how to route messages. Depending on the destination,
the message could be routed to the Transport service or the Mailbox Transport Delivery service on an
Exchange 2013 Mailbox server, or to a Hub Transport server that's running a previous version of Exchange.
For more information, see Mail routing.
Unified Messaging message submission: The Unified Messaging service on Exchange 2013 Mailbox
 servers uses Active Directory site membership information to find the other Mailbox servers that are
located in the same Active Directory site. The Unified Messaging service submits messages for routing to
the Transport service on a Mailbox server within the same Active Directory site. The Transport service
server performs recipient resolution and queries Active Directory to match a telephone number, E.164
number, or a SIP address to a recipient account. After the recipient resolution completes, the Transport
service delivers the message to the target mailbox in the same way as a regular email message.
Client connections to Client Access server: When the Client Access server receives a user connection
request, it queries Active Directory to determine which Mailbox server is hosting the user's mailbox. The
Client Access server then retrieves the Active Directory site membership of that Mailbox server and proxies
the connection to the Mailbox server.

Determine Active Directory site membership

Active Directory clients assume site membership by matching their assigned IP address to a subnet defined in
Active Directory Sites and Services and associated with an Active Directory site. The client then uses this
information to determine which domain controllers and global catalog servers exist in that site and communicates
with those directory servers for authentication and authorization purposes. Exchange 2013 takes advantage of this
relationship by also preferring to retrieve information about recipients from directory servers in the same site as
the Exchange 2013 server.
All computers that are part of the same Active Directory site are considered well connected, with a high-speed,
reliable network connection. By default, when an Active Directory forest is first deployed, there's a single site
named Default-First-Site-Name . If no other sites are manually configured by the administrator, all server and
client computers in the forest are considered members of Default-First-Site-Name .
When more than one site is defined, the Active Directory administrator must define the subnets present in the
organization and associate those subnets with Active Directory sites.
The Microsoft Exchange Active Directory Topology service checks the site membership attribute on the Exchange
server object when the server starts. If the site attribute has to be updated, the Microsoft Exchange Active
Directory Topology service stamps the attribute with the new value. The Microsoft Exchange Active Directory
Topology service verifies the site attribute value every 15 minutes and updates the value if site membership has
changed. The Microsoft Exchange Active Directory Topology service uses the Net Logon service to obtain current
site membership. The Net Logon service updates site membership every five minutes. This means that up to a 20
minute latency period may pass between the time that site membership changes and the new value is stamped on
the site attribute.

Overview of IP site links

Relationships between Active Directory sites are defined by IP site links. The IP site link consists of two or more
Active Directory sites. All Active Directory sites that are part of the link communicate at the same cost. The IP site
link properties include a cost assignment, a schedule, and an interval. The schedule and interval properties are only
used for determining Active Directory replication frequency. Exchange 2013 uses the cost assignment to determine
the lowest cost route for traffic to follow when multiple paths exist to the destination. The cost of the route is
determined by aggregating the cost of all site links in a transmission path. The Active Directory administrator
assigns the cost to a link based on relative network speed and available bandwidth compared to other available
connections.
By default, the Transport service on a Mailbox server always tries a direct connection to the Transport service or
the Mailbox Transport Delivery service on a Mailbox server in another Active Directory site. Messages in transport
don't relay through the Transport service on each Mailbox server in a site link path. However, Mailbox servers in
intermediate Active Directory sites along the routing path may perform message relay in the following scenarios:
Direct relay between Mailbox servers won't occur when a hub site exists along the least cost routing path.
 You can configure an Active Directory site as a hub site so that messages are routed through the hub site
before the messages are relayed to the target server. Hub sites are discussed later in this topic.
Exchange 2013 uses the routing path derived from IP site link information when communication to the
destination Active Directory site fails. If no Mailbox server in the destination Active Directory site responds,
message delivery backs off along the least cost routing path until a connection is made to a Mailbox server
in an Active Directory site along the routing path. The messages are queued in that Active Directory site and
the queue will be in a retry state. This behavior is called queue at point of failure.
In Exchange 2013 organizations without DAGs, the Transport service on a Mailbox server can also use the
IP site link information to optimize routing of messages sent to multiple recipients. The Mailbox server
delays bifurcation of messages until it reaches a fork in the routing paths to the recipients. The bifurcated
message is relayed to each recipient destination by a Mailbox server in the Active Directory site that
represents the fork in the individual routing paths. This functionality is called delayed fan-out.

Designate hub sites

You can use the Set-AdSite cmdlet to configure an Active Directory site as a hub site. When a hub site exists along
the least cost routing path between two transport servers, messages are routed through the hub site for
processing before they are relayed to the destination server. For this routing behavior to occur, the hub site must
exist along the least cost routing path between two transport servers. This configuration should only be used when
it's required by the network topology, such as when firewalls exist between Active Directory sites and prevent
direct relay of SMTP communications. For more information, see Configure Exchange mail routing settings in
Active Directory.

Set an Exchange-specific cost on an IP site link

You can use the Set-AdSiteLink cmdlet in the Exchange Management Shell to configure an Exchange-specific cost
to an Active Directory IP site link. The Exchange-specific cost is a separate attribute used instead of the Active
Directory-assigned cost to determine the Exchange routing path. This configuration is useful when the Active
Directory IP site link costs don't result in an optimal Exchange message routing topology. For more information,
see Configure Exchange mail routing settings in Active Directory.

Set message size restrictions on IP site links

By default, Exchange 2013 doesn't impose a maximum message size limit on messages relayed between Mailbox
servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a maximum message
size on an Active Directory IP site link, routing generates a non-delivery report (NDR ) for any message that has a
size larger than the maximum message size limit configured on any Active Directory site link in the least cost
routing path. This configuration is useful for restricting the size of messages sent to remote Active Directory sites
that must communicate over low -bandwidth connections.

Exchange 2013 server placement in Active Directory sites

For message routing between Exchange 2013 servers to occur correctly, all Exchange servers deployed in the
forest must belong to an Active Directory site. Make sure that the IP addresses that you have assigned are in
subnets that are correctly associated with Active Directory sites.
The first step in planning the placement of Exchange 2013 servers in the Active Directory site topology is to
document the current topology. Your documentation should include the following:
Sites
Subnets and their site association
 IP site links and their member sites
IP site link costs
Directory servers in each site
Physical network connections
Firewall locations
After you have diagrammed these objects, plan the placement of Exchange servers. Consider the following
information when deciding where to put servers:
A Mailbox server needs to communicate directly with a global catalog server to perform Active Directory
lookups.
We recommend that you deploy more than one Mailbox server in each Active Directory site to provide load
balancing and fault tolerance.
DAGs and site resilience
The Unified Messaging service on Mailbox servers submits voice mail messages to the Transport service on
Mailbox servers for delivery to mailboxes. The Client Access server that's running the Unified Messaging
Call Router service may be located in a hub site or near the IP or Voice over IP (VoIP ) gateway, IP Private
Branch eXchange (IP PBX), SIP -enabled PBX, or session border controllers (SBC ). The Transport service on
a Mailbox server that has the same site membership as the Client Access server will receive voice mail
messages for transport and route the messages to the Transport service on other Mailbox servers in the
organization.
Client Access servers provide a connectivity point to the Exchange organization for users who are accessing
Exchange remotely. A Client Access server must be deployed in each Active Directory site that contains
Mailbox servers.
After you plan your Exchange 2013 server placement, you may identify areas where you can modify the Active
Directory site topology to improve communication flow. You may want to adjust IP site links and site link costs to
optimize mail delivery. An efficient Active Directory topology doesn't require any changes to support Exchange
2013
 Configure Exchange mail routing settings in Active
Directory
6/6/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

By default Microsoft Exchange Server 2013 references the IP site link objects in Active Directory to help
determine the least-cost routing path. However, if you determine the Active Directory IP site link costs and traffic
flow patterns aren't optimal for mail routing in Exchange, you can configure settings in Active Directory that are
only used by Exchange to help optimize mail flow.

What do you need to know before you begin?

Estimated time to complete each procedure: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Active Directory site and site link management" entry in the Mail flow
permissions topic.
You can only use the Shell to perform this procedure.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure an Exchange-specific cost on an Active

Directory IP site link
Determine the name of the Active Directory IP site link for which you want to set an Exchange cost. A lower cost
value indicates a more preferred route. You can examine the contents of the routing table logs and view the data in
the ADTopologyPath ID section to view details about the calculated least cost routing path between two Active
Directory sites.
To set an Exchange-specific cost on an Active Directory site link, run the following command:

Set-AdSiteLink <ADSiteLinkIdentity> -ExchangeCost <Integer | $null>

This example sets an Exchange-specific cost of 10 on the IP site link named IPSiteLinkAB.

Set-AdSiteLink IPSiteLinkAB -ExchangeCost 10

This example clears the Exchange cost from the IP site link named IPSiteLinkAB.

Set-AdSiteLink IPSiteLinkAB -ExchangeCost $null

How do you know this worked?
To verify that you have successfully set an Exchange cost on an Active Directory site link, do the following:
1. Run the following command:

Get-AdSiteLink | Format-List Name,ExchangeCost

2. Verify the Exchange cost is configured on the Active Directory site link.

Use the Shell to configure an Active Directory site as a hub site

When a hub site exists along the least cost routing path for a message, the message must be routed through the
hub site. Examine the contents of the routing table logs and view the data in the ADTopologyPath ID section to
verify that the selected site exists along the least cost routing path between two Active Directory sites. If this isn't
the case, you need to assign Exchange-specific costs to the IP site links to make the least cost routing path go
through the selected sites.
To configure an Active Directory site as a hub site, run the following command:

Set-AdSite <ADSiteIdentity> -HubSiteEnabled $true

This example configures the Active Directory site named Site A as a hub site.

Set-AdSite "Site A" -HubSiteEnabled $true

This example removes the hub site attribute from the Active Directory site named Site B.

Set-AdSite "Site B" -HubSiteEnabled $false

How do you know this worked?

To verify that you have successfully configured an Active Directory site as a hub site, do the following:
1. Run the following command:

Get-AdSite | Format-List Name,HubSiteEnabled

2. Verify the HubSiteEnabled value is True for the Active Directory site.
 Route mail between Active Directory sites
6/14/2019 • 13 minutes to read • Edit Online

Applies to: Exchange Server 2013

An Active Directory site is a logical configuration component that's based on the physical aspects of the network.
The primary purpose for creating an Active Directory site is to define which subnets in the network are connected
in a way that optimizes control of Active Directory replication traffic. Microsoft Exchange Server 2013 recognizes
both database availability groups (DAGs) and Active Directory sites as routing boundaries, and Exchange 2013
servers make routing decisions based on the Active Directory site topology.
By default, an Active Directory forest contains only one Active Directory site. The default name for this Active
Directory site is Default-First-Site-Name . If no other Active Directory sites are created, all domain member
computers in the forest are members of Default-First-Site-Name . You don't have to configure a subnet-to-site
association. If additional Active Directory sites are created, you need specify the subnets that are assigned to that
Active Directory site.

Determining site membership

Each Active Directory site is associated with one or more IP subnets. An administrator assigns Active Directory site
membership to computers that are configured as domain controllers and global catalog servers. Other domain
member computers, such as Exchange servers, are assigned Active Directory site membership automatically when
they're configured to use an IP address that's in an IP subnet that's associated with an Active Directory site.
Computers that have the same Active Directory site membership are presumed to have good network connectivity.
A server is always a member of a single Active Directory site.
When an application can determine the Active Directory site membership of the computer where it's installed and
of other computers in the forest, and then use that information to control communication flow, it's a site-aware
application. When site-aware applications must use the services of another server, such as a domain controller or
global catalog server, priority is given to the servers that have the same Active Directory site membership as the
computer that's requesting those services.
Exchange 2013 is a site-aware application and uses the Active Directory topology for message routing and to
communicate with the services that are running on other Exchange 2013 computers. The Active Directory site isn't
only a routing boundary. It's also a service discovery boundary.
Determining site membership for a domain member computer depends on a series of DNS queries to compare
the local IP address to defined subnets and then determine the appropriate site membership association. To reduce
the overhead that's associated with DNS queries, the Exchange 2013 Active Directory schema additions include
the msExchServerSite attribute for the Exchange server object. The value of this attribute is the distinguished
name of the Active Directory site of an Exchange server. This attribute is a property of each Exchange server object.
When site membership affinity is stored as an attribute of the server object, the current topology can be read
directly from Active Directory instead of relying on DNS queries and a site membership association is enabled for
a non-domain computer, such as a subscribed Edge Transport server.
The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active
Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site
membership for the computer. The Net Logon service uses that information to locate domain controllers that are
located in the same Active Directory site as the local computer and then directs authorization and authentication
requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName
API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's
distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory.
The following table shows how an organization might define Active Directory sites. In this example, three Active
Directory sites are defined, and each Active Directory site is associated with more than one IP subnet.
Example of an Active Directory site-to-subnet association

ACTIVE DIRECTORY SITE NAME ASSOCIATED IP SUBNETS

Site A 192.168.1.0/24
192.168.2.0/24

Site B 192.168.3.0/24
192.168.4.0/24

Site C 192.168.5.0/24
192.168.6.0/24

If a server named Mailbox01 has the IP address of 192.168.1.1, it's a member of Site A. By changing the IP address
of a server, you may change its site membership. If you change the IP address of Mailbox01 to 192.168.2.1, it won't
change the server's Active Directory site membership because that subnet is also associated with Site A. However,
if you move the server and the IP address changes to 192.168.3.1, the server would be considered a member of
Site B.
A change in site membership can also occur if you change the association of subnets to Active Directory sites. For
example, if you remove the subnet 192.168.3.0 from association with Site B and associate it with Site A, the site
membership of a server that has the IP address of 192.168.3.1 also changes to Site A. Whenever a change in site
membership occurs, Exchange must update its configuration data so that the change is considered when Exchange
makes routing decisions. Some latency occurs between the time that a change in an Active Directory site
membership occurs and the topology change is fully propagated.

IP site links
Site links are logical paths between Active Directory sites. A site link object represents a set of sites that can
communicate at a uniform cost. Site links don't correspond to the actual path taken by network packets on the
physical network. However, the cost assigned to the site link by the administrator typically relates to the underlying
network reliability, speed, and available bandwidth. For example, the Active Directory administrator would assign a
lower cost to a network connection with a speed of 100 megabits per second (Mbps) than to a network connection
with a speed of 10 Mbps.
By default, all site links are transitive. This means that if Site A has a link to Site B, and Site B has a link to Site C,
Site A is transitively linked to Site C. The transitive link between Site A and Site C is also known as a site-link
bridge.
Exchange uses only IP site links to determine its Active Directory site routing topology. The cost that's assigned to
the IP site link will be considered by the routing component of Exchange when calculating a routing table. These
costs are used to calculate the least-cost routing path to the ultimate destination for a message.
Every Active Directory site must be associated with at least one IP site link. There is a single default IP site link
named DEFAULTIPSITELINK . When you create an Active Directory site, you need to associate that site to an IP site
link. You can create additional IP site links to implement the desired topology, or you can associate every Active
Directory site to the DEFAULTIPSITELINK . Each Active Directory site that's part of an IP site link can communicate
directly with every other site in that link at a uniform cost.
In the following figure, four Active Directory sites are configured in the forest. Every site has been associated with
the DEFAULTIPSITELINK . Therefore, each Active Directory site communicates directly with every other site by using
the same cost metric. More than one communication path is indicated, but only a single IP site link is defined.
Full mesh topology with a single IP site link

In the following figure, four Active Directory sites are configured in the forest. In this topology, the administrator
has configured IP site links to create a hub -and -spoke topology of Active Directory sites. Each spoke site can
communicate directly with the central site, and the spoke sites can communicate with one another by using the
transitive IP site links.
Hub-and-spoke topology of Active Directory IP site links

It's important to note that Exchange uses site links when determining the least-cost path, but will always try to
deliver messages directly to the destination Exchange server. For example, if a user in Site B in the topology shown
in the preceding figure sends a message to another user in Site C, the Mailbox server in Site B will connect directly
to the Mailbox server in Site C. If you want to force messages to go through Site A, you must enable that site as a
hub site. For more information about hub sites, see "Implementing Hub Sites" later in this topic.
An Active Directory administrator implements the topology that best represents the connectivity and
communication requirements of the forest. Because the same topology is used by Exchange, you need to make
sure that the current topology supports efficient messaging communication.
The default cost for a site link is 100. A valid site link cost can be any number from 1 through 99,999. If you specify
redundant links, the link with the lowest cost assignment is always preferred. An Exchange organization
administrator can assign an Exchange-specific cost to an IP site link. If an Exchange cost is assigned to an IP site
link, it will be used by Exchange. Otherwise, the Active Directory cost is used. For more information about how to
set an Exchange cost on an IP site link, see "Controlling IP Site Link Costs" later in this topic. An administrator who
has membership in the Enterprise Administrators group can create additional IP site links.
For more information about Active Directory site configuration, see Designing the Site Topology.
Controlling IP site link costs
Active Directory IP site links costs are based on relative network speed compared to all network connections in the
WAN and are designed to produce a reliable and efficient replication topology. Therefore, in most cases, the
existing IP site link costs should work well for Exchange message routing. However, if after documenting the
existing Active Directory site and IP site link topology, you verify that the Active Directory IP site link costs and
traffic flow patterns aren't optimal for Exchange, you can make adjustments to the costs evaluated by Exchange.
Changing the cost assigned to the IP site link by using Active Directory tools would impact the entire environment.
Instead, use the Set-AdSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to
the IP site link. For example, to configure the Exchange-specific cost value of 25 on the IP site link named
SITELINKAB, run the following command in the Shell: Set-AdSiteLink SITELINKAB -ExchangeCost 25 .
When an Exchange-specific cost is assigned to an IP site link, the Exchange cost overrides the Active Directory cost
for message routing purposes, and routing only considers the Exchange cost when it evaluates the least-cost
routing path.
Adjusting IP site link costs can be useful when the message routing topology has to diverge from the Active
Directory replication topology. Exchange costs can be used to force all message routes to use a hub site. Exchange
costs can also be used to control where messages are queued when communication to an Active Directory site
fails. The following figure shows an Active Directory topology with four sites.
Topology with Exchange costs configured on IP site links

In the preceding figure, the network connection between Site C and Site D is a low bandwidth connection that's
only used for Active Directory replication and shouldn't be used for message routing. However, the Active
Directory IP site link costs cause that link to be included in the least-cost routing path from any other Active
Directory site to Site D. Therefore, messages are delivered to the Site D queue in Site C. The Exchange
administrator prefers that the least-cost routing path include Site B instead so that if Site D is unavailable, the
messages will queue at Site B. Configuring a high Exchange cost on the IP site link between Site C and Site D
prevents that IP site link from being included in the least-cost routing path to Site D.
Exchange provides support for configuration of a maximum message size limit on an Active Directory IP site link.
By default, Exchange doesn't impose a maximum message size limit on messages that are relayed between
Exchange servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a
maximum message size on an Active Directory IP site link, routing generates a non-delivery report (NDR ) for any
message that has a size larger than the maximum message size limit that's configured on any Active Directory site
link in the least-cost routing path. This configuration is useful for restricting the size of messages that are sent to
remote Active Directory sites that must communicate over low -bandwidth connections. For more information, see
Message size limits.

Implementing hub sites

In your Exchange organization, you may want to force all message delivery through a specific Active Directory site.
You can use the Shell to designate an Active Directory site as a hub site. When you do this, you cause additional
overall overhead because more servers are involved in message delivery. For example, consider a message that's
sent from Site A to Site E. If the least-cost routing path is Site A-Site B -Site C -Site D -Site E, and you designate
Site C as a hub site, the message is relayed from Site A to Site C and then relayed from Site C to Site E.
You use the Set-AdSite cmdlet to specify an Active Directory site as a hub site. Whenever a hub site exists along
the least-cost routing path for message delivery, the messages are queued and are processed by the Transport
service on Mailbox servers in the hub site before they're relayed to their ultimate destination.
After the least-cost routing path is chosen, routing determines whether there's a hub site along that routing path. If
a hub site is configured, messages stop at a Mailbox server in the hub site before they're relayed to the target
destination. If there's more than one hub site along the least-cost routing path, messages stop at each hub site
along the routing path.
This variation to direct relay routing only is in effect when the hub site is located along the least-cost routing path.
The following figure shows the correct use of a hub site. In this diagram, Site B is configured as a hub site.
Messages that are relayed from Site A to Site D are relayed through Site B before they're delivered to Site D.
Message delivery with a hub site

The following figure shows how IP site link costs affect routing to a hub site. In this scenario, Site B has been
designated as a hub site. However, Site B doesn't exist along the least-cost routing path between any other sites.
Therefore, messages that are relayed from Site A to Site D are never relayed through Site B. An Active Directory
site is never used as a hub site if it isn't on the least-cost routing path between two other sites.
Misconfigured hub site
You can configure any Active Directory site as a hub site. However, for this configuration to work correctly, you
must have at least one Mailbox server in the hub site.

Topology discovery
The Active Directory topology is made available to Exchange by the following required elements:
The Microsoft Exchange Active Directory Topology service.
The topology discovery module inside the Microsoft Exchange Transport service.
The Microsoft Exchange Active Directory Topology service runs on all Exchange 2013 Client Access servers and
Mailbox servers. These servers use the Microsoft Exchange Active Directory Topology service to discover the
domain controllers and global catalog servers that can be used by the Exchange servers to read and write Active
Directory data. Exchange 2013 binds to the identified directory servers whenever Exchange has to read from or
write to Active Directory.
The topology discovery module is part of the Microsoft Exchange Transport service and provides information
about the Active Directory topology to Exchange servers. This API discovers the Exchange servers and roles in the
organization and determines their relationship to the Active Directory configuration objects. Configuration data is
retrieved from Active Directory and then cached so that it can be accessed by the Exchange services that are
running on that computer.
The topology discovery module performs the following steps to generate an Exchange routing topology:
1. Data is read from Active Directory. All the following objects are retrieved:
Active Directory sites.
IP site links.
All Exchange servers.
2. The data that's retrieved in step 1 is used to create the initial topology and to begin linking and mapping the
related configuration objects.
3. Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the
Exchange server object that's stored in Active Directory.
4. Routing tables are updated with the collection of information retrieved.
This process makes every Exchange 2013 server aware of the other Exchange servers in the organization and of
how close the Exchange servers are to one another.
 Recipient resolution
6/14/2019 • 20 minutes to read • Edit Online

Applies to: Exchange Server 2013

Recipient resolution is the process of expanding and resolving all the recipients in a message. The act of resolving
the recipients matches a recipient to the corresponding Active Directory object in the Microsoft Exchange
organization. The act of expanding the recipients expands all distribution groups into a list of individual recipients.
Recipient resolution allows message limits and alternative recipients to be applied correctly to each recipient.
In a Microsoft Exchange Server 2013 organization, recipient resolution is performed by the categorizer in the
Transport service on Mailbox servers. Categorization on each message happens after a newly arrived message is
put in the Submission queue. Recipient resolution, in addition to content conversion and routing, is performed on
the message before the message is put in a delivery queue. The categorizer performs recipient resolution before
routing. The component of the categorizer that's responsible for recipient resolution is frequently called the
resolver.

Top-level resolution
Top -level resolution is the first stage of recipient resolution. Top-level resolution associates each recipient in an
incoming message to a matching recipient object in Active Directory. During top-level resolution, the categorizer
creates a list that contains the sender and the initial, unexpanded recipient email addresses that exist within the
message. The categorizer then uses that list of email addresses to query Active Directory to find any mail-enabled
objects that have matching email address attributes. When a match is found, the properties of matching Active
Directory objects are cached for later use. Any sender message restrictions are also enforced.

Recipient email addresses

Top-level resolution begins with a message and the initial, unexpanded list of recipients from the message
envelope. The message envelope contains the commands that are used to transmit messages among SMTP
messaging servers. The sender's email address is contained in the MAIL FROM: command. Each recipient's email
address is contained in a separate RCPT TO: command. The envelope sender and envelope recipients are typically
created from the sender and recipients in the To: , From: , Cc: , and Bcc: header fields in the message header.
However, this isn't always true. The To: , From: , Cc: , and Bcc: header fields in a message are easily forged and
may not match the actual sender or recipient email addresses that were used to transmit the message.

Encapsulated email addresses

Standard SMTP email addresses follow the specifications of RFC 2821 and RFC 2822, such as [email protected],
for example. However, an email address can also be a non-SMTP email address that's encapsulated inside a valid
SMTP address. Exchange supports encapsulated addresses that use the Internet Mail Connector Encapsulated
Address (IMCEA) encapsulation method.
This encapsulation method requires the encoding of any characters that are invalid in SMTP email addresses.
Alphanumeric characters, the equal sign (=) and the hyphen (-) don't require encoding. Other characters use the
following encoding syntax:
A forward slash (/) is replaced by an underscore (_).
Other US -ASCII characters are replaced by a plus sign (+) and the two digits of its ASCII value are written
in hexadecimal. For example, the space character has the encoded value +20 .
The IMCEA encapsulation method uses the following syntax: IMCEA<Type>-<address>@<domain>

The placeholder <Type> identifies the type of non-SMTP address, for example EX , X400 , or FAX .

NOTE
Although SMTP and X500 are theoretically valid values for <Type>, Exchange recipient resolution rejects any IMCEA-
encoded addresses that use either of these types.

The placeholder <address> is the encoded original address. The placeholder <domain> represents the SMTP
domain that's used to encapsulate the non-SMTP address, for example, contoso.com
With the IMCEA encapsulation method, addresses are unencapsulated only when the domain matches the default
authoritative domain in the Exchange organization. For more information about accepted domains, see Accepted
domains.
The maximum length for an SMTP email address in Exchange is 571 characters. This limit includes the following:
315 characters for the name part of the address
255 characters for the domain name
The at sign (@) character that separates the name part of the address from the domain name
Note that Exchange doesn't support messages that are encoded with the IMCEA encapsulation method when the
name part of the address exceeds 315 characters, even if the complete email address is less than 571 characters.

Address resolution
For each message, the sender email address and all recipient email addresses are added to a list that's used to
query Active Directory. Any encapsulated addresses are unencapsulated before they're added to the list of email
addresses. The Active Directory query is performed on up to 20 email addresses at a time. If the Active Directory
query encounters any transient errors, the message is returned to the Submission queue and deferred for the time
that's specified by the ResolverRetryInterval key in the %ExchangeInstallPath%Bin\EdgeTransport.exe.config XML
application configuration file that's associated with the Microsoft Exchange Transport service. The default value is
30 minutes.
The following table describes the recipient objects that are found in Active Directory. For more information about
Exchange recipient types, see Recipients.
Recipient objects in Active Directory
ACTIVE DIRECTORY RECIPIENT TYPE DESCRIPTION

DistributionGroup Any mail-enabled group object. The distribution group

object types are as follows:
MailUniversalDistributionGroup A universal
distribution group object
MailUniversalSecurityGroup A universal
security group (USG) object that has an email
address
MailNonUniversalGroup A local security group
object or global security group object that has an
email address
 ACTIVE DIRECTORY RECIPIENT TYPE DESCRIPTION

DynamicDistributionGroup An object that has the Active Directory class

msExchDynamicDistributionList. For more information,
see Manage dynamic distribution groups.

Mailbox A user object that has an email address and a defined

Database parameter

MailUser A user object that has an email address without a defined

Database parameter. For more information, see Manage
mail users.

MailContact A contact object that has an email address. Typically, a

mail contact is used for recipients outside the Exchange
organization. A mail contact is also used in cross-forest
Exchange environments. For more information, see
Manage mail contacts.

MailPublicFolder A public folder object that has an email address.

MicrosoftExchangeRecipient An object that has the Active Directory class

msExchExchangeServerRecipient. For more information
about the Microsoft Exchange recipient object, see
Recipients.

SystemAttendantMailbox An object that has the Active Directory class

exchangeAdminService. There should be only one
system attendant mailbox in the Exchange organization.

SystemMailbox A user object that has an email address and that's located
in the Microsoft Exchange System Objects container. There
should be one system mailbox for each mailbox database
in the Exchange organization.

An object that contains missing or malformed critical properties is classified by the Active Directory query as an
invalid object. For example, a dynamic distribution group object without an email address is considered invalid.
Messages that are sent to recipients that are classified as invalid objects generate a non-delivery report (NDR ).
For each email address, a single initial query is performed for all possible recipient properties, such as the recipient
identifiers, recipient type, message limits, email addresses, and alternative recipients. The applicable properties for
the recipient are cached for later use. Recipient resolution classifies the recipients based on similarities in how the
recipients are resolved, and the similarity of the applicable recipient properties.
The LDAP filter that's used for address resolution is described as follows:
For the EX email address type, the LDAP filter is based on the recipient legacyExchangeDN Active
Directory attribute or the recipient proxyAddresses Active Directory attribute. The legacyExchangeDN
Active Directory attribute takes precedence.
For all other email addresses types, the recipient proxyAddresses Active Directory attribute is used as the
LDAP filter.
If the email address that's used in the message doesn't match the primary SMTP address of the corresponding
Active Directory object, the categorizer rewrites the email address in the message to match the primary SMTP
address. The original email address is saved in the ORCPT= entry in the RCPT TO: command in the message
envelope.

Sender message restrictions

The size that's used for the sender message size restriction is the value of the X-MS -Exchange-Organization-
OriginalSize: header field in the message header. Exchange uses this header field to record the original message
size of the message when it entered the Exchange organization. Whenever the message is checked against the
specified message size limits, the lower value of the current message size or the original message size header is
used. The size of the message can change because of content conversion, encoding, and agent processing. If this
header field doesn't exist, it's created by using the current message size value. If the message is too large, an NDR
is generated and additional message processing is stopped.
The sender recipient limit is only enforced in the Transport service on the first Mailbox server that processes the
message. The original, unexpanded message envelope recipient count is compared to the sender recipient limit.
The original, unexpanded message envelope recipient count is used to avoid the partial message delivery
problems that occured in Microsoft Exchange Server 2003 when nested distribution lists used remote expansion
servers.
The message sender and all recipients are marked as resolved by stamping an extended property in the message.
This extended property allows the message to bypass top-level resolution if the message must go through
recipient resolution again. A message may have to go through recipient resolution again because the Microsoft
Exchange Transport service restarted.

Expansion
Expansion occurs after top-level resolution. Expansion completely expands nested levels of recipients into
individual recipients. Expansion may require multiple trips through the expansion process to expand all recipients.
Not all recipients have to be expanded. However, all recipients must go through the expansion process. The
expansion process also enforces recipient message restrictions for all kinds of recipients.
The following list describes the kinds of recipients that require expansion:
Distribution groups and dynamic distribution groups: Distribution groups are expanded based on the
memberOf Active Directory property. Dynamic distribution groups are expanded by using the Active
Directory query definition. If the ExpansionServer parameter is set on the group, the group isn't expanded
by the current server. The distribution group is routed to the specified server for expansion.

NOTE
If you select a specific transport server in your organization as the expansion server, the distribution group usage
becomes dependent on the availability of the expansion server. If the expansion server is unavailable, any messages
that are sent to the distribution group can't be delivered. If you plan to use specific expansion servers for your
distribution groups, to reduce the risk of service interruption, you should consider implementing high availability
solutions for these servers.

Alternative recipients: The ForwardingAddress parameter may be set on mailboxes and mail-enabled
public folders. The ForwardingAddress parameter redirects all messages to the specified alternative
recipient. This is known as a forwarded recipient. When an alternative delivery address is specified in the
ForwardingAddress parameter and the DeliverToMailboxAndForward parameter is set to $true , the
message is delivered to the original recipient and the alternative recipient. This is known as delivered and
forwarded recipient.
 Contact chains: A contact chain is a mail user or mail contact that has the ExternalEmailAddress parameter
set to the email address of another recipient in the Exchange organization.

Detection of recipient loops

As the distribution groups, alternative recipients, and contacts chains are expanded, the categorizer checks for
recipient loops. A recipient loop is a recipient configuration problem that causes message delivery to the same
recipients in an endless circle. The following list describes the different types of recipient loops:
Harmless recipient loop: A harmless recipient loop results in successful message delivery. The following
list describes two scenarios when harmless recipient loops occur:
When two distribution groups contain one another as members.
When mailboxes or mail-enabled public folders are set to deliver and forward to one another. This
happens when the DeliverToMailboxAndForward parameter of both recipients is set to $true and
the ForwardingAddress parameter is set to one another.
When a harmless recipient loop is detected, the message is delivered to the recipient, but no
additional attempts are made to deliver the message to the same recipient.
Broken recipient loop: A broken recipient loop can't result in successful message delivery. An example of
a broken recipient loop is when mailboxes or mail-enabled public folders have the ForwardingAddress
parameter set to one another. When the categorizer detects a broken recipient loop, expansion activity for
the current recipient stops, and an NDR is generated for the recipient.
Detection of recipient loops doesn't prevent duplicate message delivery. For example, Distribution Group C will
experience duplicate message delivery if the following conditions are true:
Distribution Group B and Distribution Group C are members of Distribution Group A.
Distribution Group C is also a member of Distribution Group B.

Delivery report redirection for distribution groups

When a distribution group is expanded, the message type is checked to determine whether it's a delivery report
message. If the message is a delivery report, the redirection settings of the distribution group are checked to
determine whether redirection of the delivery report is required. You may want to suppress the delivery reports
because the delivery reports may disclose unwanted information about the distribution group and its membership.
The following list describes the delivery report redirection settings that are available for distribution groups and
dynamic distribution groups:
ReportToManagerEnabled: This parameter enables delivery reports to be sent to the distribution group
manager. Valid values are $true or $false . The default value is $false . For a distribution group, the
manager is controlled by the ManagedBy parameter in the Set-Group cmdlet. For a dynamic distribution
group, the manager is controlled by the ManagedBy parameter in the Set-DynamicDistributionGroup
cmdlet.
ReportToOriginatorEnabled: This parameter enables delivery reports to be sent to the sender of email
messages that are sent to this distribution group. Valid values are $true or $false . The default value is
$true .
 NOTE
The values of the ReportToManagerEnabled parameter and ReportToOriginatorEnabled parameter can't both be
$true . If one parameter is set to $true , the other must be set to $false . The values of both parameters can be
$false . This suppresses all redirection of all delivery report messages.

The following list describes the available delivery report messages:

Delivery receipt (DR): This report confirms that a message was delivered to its intended recipient.
Delivery status notification (DSN ): This report describes the result of an attempt to deliver a message.
For more information about DSN messages, see DSNs and NDRs in Exchange 2013.
Message disposition notification (MDN ): This report describes the status of a message after it has been
successfully delivered to a recipient. A read notification (RN ) and a non-read notification (NRN ) are both
examples of an MDN message. MDN messages are defined in RFC 2298 and are controlled by the
Disposition-Notification-To: header field in the message header. MDN settings that use the
Disposition-Notification-To: header field are compatible with many different message servers. MDN
settings can also be defined by using MAPI properties in Microsoft Outlook and Exchange.
Non-delivery report (NDR): This report indicates to the message sender that the message couldn't be
delivered to the specified recipients.
Non-read notification (NRN ): This report indicates that a message was deleted before it was read.
Out of office (OOF): This report indicates that the recipient won't respond to email messages. The
acronym OOF dates back to the original Microsoft messaging system where the corresponding notification
was named "out of facility."
Read notification (RN ): This report indicates that a message was read.
Recall Report: This report indicates the status of a recall request for a specific recipient. A recall request is
when a sender tries to recall a sent message by using Outlook.
When a delivery report message is sent to a distribution group, the following settings cause the report message to
be deleted:
Report redirection isn't set. Alternatively, report redirection is set to the message sender.
Report redirection is set to the distribution group manager, and the delivery report message isn't an NDR.
When a delivery report message is sent to a distribution group, the delivery report message may be delivered to
the distribution group manager. This happens when report redirection is set to the distribution group manager, and
the report message is an NDR.
When a message that isn't a delivery report message is sent to a distribution group, the message is delivered to
the distribution group members. The report request settings are summarized in the following list:
If report redirection is set to the message sender, the report request settings aren't modified.
If report redirection isn't set, all report request settings are suppressed. The NOTIFY=NEVER entry is added to
RCPT TO: for each recipient in the message envelope.
If report redirection is set to the distribution group manager, all report request settings are suppressed
except NDR messages that are sent to the distribution group manager.

Message restrictions on recipients

The expansion process also enforces any message restrictions that are configured for recipients. These restrictions
may be configured individually for each recipient or organizationally for all Hub Transport servers in the Exchange
organization. The following table describes the message restrictions that are configured for recipients.
Message restrictions on recipients
SOURCE PARAMETER DESCRIPTION

Set-DistributionGroup MaxReceiveSize The MaxReceiveSize parameter

specifies the size that's used for
Set-DynamicDistributionGroup message restrictions that are
Set-Mailbox configured for recipients is the
value of the X-MS-Exchange-
Set-MailContact Organization-OriginalSize:
Set-MailPublicFolder header field in the message header.
Exchange uses this header field to
Set-MailUser record the original message size of
the message when it entered the
Set-TransportConfig Exchange organization. Whenever
the message is checked against the
specified message size limits, the
lower value of the current message
size or the original message size
header is used. The size of the
message can change because of
content conversion, encoding, and
agent processing. If this header field
doesn't exist, it's created by using
the current message size value. If
the message is too large, an NDR is
generated and additional message
processing is stopped.

Set-DistributionGroup RequireSenderAuthenticationEnabl The

ed RequireSenderAuthenticationEnabl
Set-DynamicDistributionGroup ed parameter requires that all
Set-Mailbox messages that are sent to the
recipient come from authenticated
Set-MailContact senders. When the value of this
Set-MailPublicFolder parameter is set to $true ,
messages from unauthenticated
Set-MailUser senders are rejected. All senders
who send messages to the System
and System Attendant mailboxes
must be authenticated.
 SOURCE PARAMETER DESCRIPTION

Set-DistributionGroup AcceptMessagesOnlyFromSenders The

OrMembers AcceptMessagesOnlyFromSenders
Set-DynamicDistributionGroup OrMembers parameter specifies the
RejectMessagesFromSendersOrMe senders or distribution groups
Set-Mailbox mbers whose members are allowed to
Set-MailContact send messages to the recipient.
Set-MailPublicFolder Note that this parameter combines
the functionality of the older
Set-MailUser AcceptMessagesOnlyFrom and
AcceptMessagesOnlyFromDLMemb
ers parameters.
The
RejectMessagesFromSendersOrMe
mbers parameter specifies the
senders or distribution groups
whose members aren't allowed to
send messages to the recipient.
Note that this parameter combines
the functionality of the older
RejectMessagesFrom and
RejectMessagesFromDLMembers
parameters.
The categorizer checks the recipient
permission in two passes. The first
pass determines whether the
sender is present in the
AcceptOnlyMessagesFromSenders
OrMembers or
RejectMessagesFromSendersOrMe
mbers parameter. If the sender isn't
found in either parameter, the
distribution groups in those
parameters are fully expanded. This
complete expansion of distribution
groups may take some time. We
recommend that you minimize the
depth of nested distribution groups
in those parameters.

Certain types of messages that are sent by authenticated senders are exempt from restrictions. The following list
describes the messages that are exempt from recipient restrictions:
All messages that are sent by the Microsoft Exchange recipient: These messages include DSN
messages, journal reports, quota messages, and other system-generated messages that are sent to internal
message senders. For more information about the Microsoft recipient, see Recipients.
All messages that are sent by the external postmaster address: These messages include DSN
messages and other system-generated messages that are sent to external message senders. For more
information about the external postmaster address, see Configure the external postmaster address.
Certain types of messages are blocked when they are sent from the Exchange organization to external domains.
The settings are controlled by the following parameters in the Set-RemoteDomain cmdlet:
AllowedOOFType
AutoForwardEnabled
AutoReplyEnabled
 DeliveryReportEnabled
NDREnabled
For more information, see Remote domains.

Bifurcation and controlling recipient expansion

Because the complete list of message recipients is expanded and resolved by recipient resolution, there are
occasions when different copies of the same message must be created. These occasions are described by the
following scenarios:
When message recipients require different message settings: Message properties such as read
receipts may have to be enabled for some recipients and blocked for other recipients. Creating a new
version of the message that has slightly different properties than the original message is called bifurcation.
To limit the number of envelope recipients in a single message: The recipient expansion process can
generate thousands of individual recipients when large distribution groups are expanded. In Exchange,
instead of creating a single copy of the message that has thousands of envelope recipients, multiple copies
of the same message that have a limited number of envelope recipients are created.

Bifurcation
Recipient resolution bifurcates a message if the following conditions are true:
When the message sender in MAIL FROM:, in the message envelope, is updated. An example is when the
ReportToManagerEnabled parameter on a distribution group has a value of $true .
When auto-response messages, such as DSNs, OOF messages, and recall reports must be suppressed.
When alternative recipients are expanded.
When a Resent-From: header field must be added to the message header. Resent header fields are
informational header fields that can be used to determine whether a message has been forwarded by a user.
Resent header fields are used so that the message appears to the recipient as if it was sent directly by the
original sender. The recipient can view the message header to discover who forwarded the message. Resent
header fields are defined in section 3.6.6 of RFC 2822.
When the history of the expansion of the distribution group must be transmitted.

Controlling recipient expansion

When the number of expanded recipients is too large, the categorizer splits the message into multiple copies. This
is done to reduce system resource use during message expansion. The maximum number of envelope recipients in
a message is controlled by the ExpansionSizeLimit key in the %ExchangeInstallPath%Bin\EdgeTransport.exe.config
application configuration file. The default value is 1000.

WARNING
We recommend that you don't modify the value of the ExpansionSizeLimit key on an Exchange transport server in a
production environment.

Recipient resolution diagnostics

Reporting and diagnostic information for recipient resolution is provided by performance counters, and message
tracking log entries. These sources can help you identify and diagnose problems with recipient resolution.
Recipient resolution performance counters
The following table describes the performance counters that are available for recipient resolution.
Recipient resolution performance counters
COUNTER NAME DISPLAY NAME DESCRIPTION

AmbiguousRecipientsTotal Ambiguous Recipients This is the total number of

ambiguous recipients that were
detected during recipient
resolution. Ambiguous recipients
are different recipients that have
matching legacyExchangeDN
Active Directory attributes or
matching proxyAddresses Active
Directory attributes.

AmbiguousSendersTotal Ambiguous Senders This is the number of ambiguous

senders that were detected during
recipient resolution. Ambiguous
senders are different senders that
have matching
legacyExchangeDN Active
Directory attributes or matching
proxyAddresses Active Directory
attributes.

FailedRecipientsTotal Failed Recipients This is the number of failed

recipients that were detected
during recipient resolution.

LoopRecipientsTotal Loop Recipients This is the number of recipients that

failed recipient resolution because
of recipient loops.

MessagesChippedTotal Messages Chipped This is the total number of copies of

the same message that were
created during recipient resolution
to control the number of envelope
recipients in a single message. In
Exchange, this process is referred to
as chipping.

MessagesCreatedTotal Messages Created This is the number of messages

that were created during recipient
resolution.

MessagesRetriedTotal Messages Retried This is the number of messages

that were scheduled for retry
during recipient resolution.
 COUNTER NAME DISPLAY NAME DESCRIPTION

UnresolvedOrgRecipientsTotal Unresolved Org Recipients This is the number of unresolved

recipients from an authoritative
domain that were detected during
recipient resolution.

UnresolvedOrgSendersTotal Unresolved Org Senders This is the number of unresolved

senders from an authoritative
domain that were detected during
recipient resolution.

Recipient resolution events in the message tracking log

The following table describes the recipient resolution events that are written in the message tracking log.
Recipient resolution events in the message tracking log
MESSAGE TRACKING EVENT DESCRIPTION

EXPAND This event indicates that a distribution group was

expanded.

REDIRECT This event indicates that a message sent to a mailbox

recipient or a mail-enabled public folder recipient was
redirected to an alternative recipient as specified by the
ForwardingAddress parameter.

RESOLVE This event indicates that a recipient email address was

changed to the primary SMTP email address of the
corresponding Active Directory recipient object.

TRANSFER This event indicates that message bifurcation or chipping

occurred.

For more information about message tracking, see Message tracking.

 DNS query failure sensitivity
5/28/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can adjust the DNS query sensitivity for slightly faster message delivery
when DNS errors are encountered for the destination domain. However, depending on the DNS errors, this
adjustment may cause delivery failures in certain circumstances.

DNS queries and remote message delivery

The Exchange server that's responsible for delivering messages to external recipients must be able to find a
destination messaging server that accepts mail for the external recipients. Depending on the destination, the
messages are put in one or more remote delivery queues as they await delivery to the remote recipients. For more
information about delivery queues, see Queues.
The Exchange server queries the configured DNS servers to find the DNS records that are required to deliver the
message. The DNS servers are queried in the order in which they're listed. If one of the DNS servers is unavailable,
the query goes to the next DNS server on the list. The DNS servers are queried for the following information:
Mail exchange (MX) records for the domain part of the external recipient: The MX record contains
the fully qualified domain name (FQDN ) of the messaging server that's responsible for accepting messages
for the domain, and a preference value for that messaging server. A lower preference value indicates a
preferred messaging server. The preference value is important if the domain has more than one MX record.
To optimize fault tolerance, most organizations use multiple messaging servers and multiple MX records
that have different preference values.
Address (A ) records for the destination messaging servers: Every messaging server that's used in an
MX record should have a corresponding A record. The A record is used to find the IP address of the
destination messaging server. The subscribed Edge Transport server uses the IP address to open an SMTP
connection with the destination messaging server. Although it's technically possible to use the FQDN of a
canonical name (CNAME ) record in an MX record, this practice violates RFC 974, RFC 1034, RFC 1912, and
RFC 2181, and is therefore not supported by most messaging servers.
The required combination of iterative DNS queries and recursive DNS queries that start with a root DNS
server is used to resolve the FQDN of the messaging server that's found in the MX record into an IP
address.
In Exchange 2013, there's a DNS query limit that's not configurable of 5 seconds for each DNS server, and a one-
minute limit for the entire DNS query.

Potential DNS problems

Even when the DNS settings on the Exchange server are configured correctly, problems with the DNS records for a
specific domain or problems with any of the DNS servers that are used to find the authoritative DNS server for a
specific domain may still occur. Generally, these problems are beyond your control and need to be resolved by the
parties that own those DNS servers. These DNS -related errors may be caused by one or more of the following
conditions:
Invalid DNS records for the destination domain
Problems with DNS server utilization
 Problems with DNS server replication
In Exchange 2013, when a DNS query results in errors, the query continues to the next DNS server only if that
DNS server hasn't already returned an error for the current query.
You can control the DNS query failure sensitivity by modifying the
%ExchangeInstallPath%bin\EdgeTransport.exe.config XML application configuration file. This file is associated with
the Microsoft Exchange Transport service. Changes you save to this file are applied after you restart the Microsoft
Exchange Transport service. When you restart this service, mail flow on the server is temporarily interrupted. The
DNS query failure sensitivity is controlled by the DnsFaultTolerance key in the EdgeTransport.exe.config file. This
key uses the following values:
Lenient: When the DNS query encounters a combination of valid MX records and invalid MX records, the
DNS query continues until the DNS query time-out value of one minute is reached. The invalid MX records
are discarded, and the valid MX record that has the lowest preference value is used to deliver the message to
the destination messaging server. This is the default value.
Normal: When the DNS query first encounters an invalid MX record, any resolved MX records that have a
preference value that's greater than or equal to the invalid MX records are immediately discarded. The
remaining MX record that has the lowest preference value is used to deliver the message to the destination
messaging server without waiting for the whole DNS query to time out. Although this behavior may result
in faster message delivery, the potential drawback of this behavior is the DNS query may have no valid MX
records if the following conditions are true:
The invalid MX record is the first MX record for the destination domain.
The valid MX records have the same precedence value as the invalid MX records.
In both Normal mode and Lenient mode, the results of the DNS query for an invalid MX record are never cached.
The next time that a DNS query is executed, it will try to resolve the MX records for the destination domain.

NOTE
Any customized per-server settings you make in Exchange XML application configuration files, for example, web.config files
on Client Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be overwritten when you install an
Exchange Cumulative Update (CU). Make sure that you save this information so you can easily re-configure your server after
the install. You must re-configure these settings after you install an Exchange CU.
 Use Telnet to test SMTP communication
6/14/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

This topic explains how to use Telnet to test Simple Mail Transfer Protocol (SMTP ) communication between
messaging servers. By default, SMTP listens on port 25. If you use Telnet on port 25, you can enter the SMTP
commands that are used to connect to an SMTP server and send a message exactly as if your Telnet session was
an SMTP messaging server. You can see the success or failure of each step in the connection and message
submission process.
Here are the scenarios where you may want to use Telnet to test SMTP communication to or from the transport
servers that exist in your Microsoft Exchange organization:
Connect to your organization's Internet-facing Exchange server from a host that is located outside your
perimeter network and send a test message.
Connect to a remote messaging server from your organization's Internet-facing Exchange server and send a
test message.
The procedure in this topic shows you how to use Telnet Client, which is a component that is included with
Microsoft Windows. Third-party Telnet clients may require a syntax that is different from that of the Windows
Telnet component.

What do you need to know before you begin?

Estimated time to complete: 30 minutes
Exchange permissions don't apply to the procedures in this topic. These procedures are performed in the
operating system of the Exchange Server or a client computer.
The procedures in this topic are best used to connect to and from Internet-facing servers that allow
anonymous connections. Message transmission between internal Exchange servers is encrypted and
authenticated. To use Telnet to connect to the Hub Transport service on a Mailbox server, you'll need to
create a Receive connector that's configured to allow anonymous access or Basic authentication to receive
messages. If the connector allows Basic authentication, you need a utility to convert the text strings that are
used for the username and password into the Base64 format. Because the user name and password are
easily discernible when Basic authentication is used, we don't recommend Basic authentication without
encryption.
If you connect to a remote messaging server, consider performing the procedures in this topic on your
Internet-facing Exchange server. This will help to avoid rejection of the test message by remote messaging
servers that are configured to validate the source IP address, the corresponding domain name system
(DNS ) domain name, and the reverse lookup IP address of any Internet host that tries to send a message to
the server.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Step 1: Install the Telnet Client in Windows
By default, the Telnet Client isn't installed in most client or server versions of the Microsoft Windows operating
systems. To install it, see Install Telnet Client.

Step 2: Use Nslookup to find the FQDN or IP address in the MX record

of the remote SMTP server
To connect to a destination SMTP server by using Telnet on port 25, you must use the fully qualified domain name
(FQDN ) or the IP address of the SMTP server. If the FQDN or IP address is unknown, the easiest way to find this
information is to use the Nslookup command-line tool to find the MX record for the destination domain.
1. At a command prompt, type nslookup, and then press ENTER. This command opens the Nslookup session.
2. Type set type=mx and then press ENTER.
3. Type set timeout=20 and then press ENTER. By default, Windows DNS servers have a 15-second
recursive DNS query time-out limit.
4. Type the name of the domain for which you want to find the MX record. For example, to find the MX record
for the fabrikam.com domain, type fabrikam.com., and then press ENTER.

NOTE
The trailing period ( . ) indicates a FQDN. The use of the trailing period prevents any default DNS suffixes that are
configured for your network from being unintentionally added to the domain name.

The output of the command will resemble the following:

fabrikam.com mx preference=10, mail exchanger = mail1.fabrikam.com

fabrikam.com mx preference=20, mail exchanger = mail2.fabrikam.com
mail1.fabrikam.com internet address = 192.168.1.10
mail2 fabrikam.com internet address = 192.168.1.20

You can use any of the host names or IP addresses that are associated with the MX records as the
destination SMTP server. A lower value of preference indicates a preferred SMTP server. You can use
multiple MX records and different values of preference for load balancing and fault tolerance.
5. When you're ready to end the Nslookup session, type exit, and then press ENTER.

NOTE
Firewall or Internet proxy restrictions that are imposed on your organization's internal network may prevent you from using
the Nslookup tool to query public DNS servers on the Internet.

Step 3: Use Telnet on Port 25 to test SMTP communication

In this example, the following values are used:
Destination SMTP server: mail1.fabrikam.com
Source domain: contoso.com
Sender's e-mail address: [email protected]
Recipient's e-mail address: [email protected]
 Message subject: Test from Contoso
Message body: This is a test message

NOTE
The commands in Telnet Client are not case-sensitive. The SMTP command verbs are capitalized for clarity.
You can't use the backspace key after you have connected to the destination SMTP server within the Telnet session. If
you make a mistake as you type an SMTP command, you must press ENTER and then type the command again.
Unrecognized SMTP commands or syntax errors result in an error message that resembles the following:

500 5.3.3 Unrecognized command

1. At a command prompt, type telnet, and then press ENTER. This command opens the Telnet session.
2. Type set localecho and then press ENTER. This optional command lets you view the characters as you type
them. This setting may be required for some SMTP servers.
3. Type set logfile <filename>. This optional command enables logging of the Telnet session to the specified
log file. If you only specify a file name, the location of the log file is the current working directory. If you
specify a path and a file name, the path must be local to the computer. Both the path and the file name that
you specify must be entered in the Microsoft DOS 8.3 format. The path that you specify must already exist.
If you specify a log file that doesn't exist, it will be created for you.
4. Type open mail1.fabrikam.com 25 and then press ENTER.
5. Type EHLO contoso.com and then press ENTER.
6. Type **MAIL FROM:[email protected]** and then press ENTER.
7. Type RCPT TO:[email protected] NOTIFY=success,failure and then press ENTER. The optional
NOTIFY command defines the particular delivery status notification (DSN ) messages that the destination
SMTP server must provide to the sender. DSN messages are defined in RFC 1891. In this case, you're
requesting a DSN message for successful or failed message delivery.
8. Type DATA and then press ENTER. You will receive a response that resembles the following:

354 Start mail input; end with <CLRF>.<CLRF>

9. Type Subject: Test from Contoso and then press ENTER.

10. Press ENTER. RFC 2822 requires a blank line between the Subject: header field and the message body.
11. Type This is a test message and then press ENTER.
12. Press ENTER, type a period ( . ) and then press ENTER. You will receive a response that resembles the
following:

250 2.6.0 <GUID> Queued mail for delivery

13. To disconnect from the destination SMTP server, type QUIT and then press ENTER. You will receive a
response that resembles the following:

221 2.0.0 Service closing transmission channel

14. To close the Telnet session, type quit and then press ENTER.

Step 4: Evaluate the Results of the Telnet Session

This section provides information about responses that may be provided to the following commands, which were
used in the previous example:
Open mail1.fabrikam.com 25
EHLO contoso.com
MAIL FROM:[email protected]
RCPT TO:[email protected] NOTIFY=success,failure

NOTE
The 3-digit SMTP response codes that are defined in RFC 2821 are the same for all SMTP messaging servers. The text
descriptions may differ slightly for some SMTP messaging servers.

Open mail1.fabrikam.com 25
Successful Response: 220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at <day-date-time>

Failure Response:
Connecting to mail1.fabrikam.com...Could not open connection to the host, on port 25: Connect failed

Possible Reasons for Failure:

The destination SMTP service is unavailable.
There are restrictions on the destination firewall.
There are restrictions on the source firewall.
An incorrect FQDN or IP address for the destination SMTP server was specified.
An incorrect port number was specified.

EHLO contoso.com
Successful Response: 250 mail1.fabrikam.com Hello [<sourceIPaddress>]

Failure Response: 501 5.5.4 Invalid domain name

Possible Reasons for Failure: There are invalid characters in the domain name. Alternatively, there are connection
restrictions on the destination SMTP server.

NOTE
EHLO is the Extended Simple Message Transfer Protocol (ESMTP) verb that is defined in RFC 2821. ESMTP servers can
advertise their capabilities during the initial connection. These capabilities include their maximum accepted message size and
their supported authentication methods. HELO is the older SMTP verb that is defined in RFC 821. Most SMTP messaging
servers support ESMTP and EHLO.

MAIL FROM:[email protected]
Successful Response: 250 2.1.0 Sender OK
Failure Response: 550 5.1.7 Invalid address

Possible Reasons for Failure: There is a syntax error in the sender's e-mail address.
Failure Response: 530 5.7.1 Client was not authenticated

Possible Reasons for Failure: The destination server does not accept anonymous message submissions. You
receive this error if you try to use Telnet to submit a message directly to a Hub Transport server.

RCPT TO:[email protected] NOTIFY=success,failure

Successful Response: 250 2.1.5 Recipient OK

Failure Response: 550 5.1.1 User unknown

Possible Reasons for Failure: The specified recipient does not exist in the organization.
 Configure the external postmaster address
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The external postmaster address is used as the sender for system-generated messages and notifications sent to
message senders that exist outside of your Microsoft Exchange Server 2013 organization. An external sender is
any sender that has an email address in a domain that isn't configured as an accepted domain in your organization.
By default, the value of the external postmaster address setting is blank. This default value causes the following
behavior in your Exchange organization:
The external postmaster address is postmaster@<Default accepted domain> for all Mailbox servers and
subscribed Edge Transport servers.
The external postmaster address is postmaster@<Edge Transport server FQDN> for all unsubscribed Edge
Transport servers.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport configuration" entry in the Mail flow permissions topic.
When you configure a custom external postmaster address, that value applies to all Exchange 2013 Mailbox
servers and Exchange 2010 Hub Transport servers in your Exchange organization. However, that value isn't
replicated to Edge Transport servers. If you specify a custom value for the external postmaster address, you
need to manually configure the external postmaster address value on any Edge Transport servers.
If you have any Exchange 2007 Hub Transport servers or Edge Transport servers in your organization, you
need to configure the custom external postmaster address on each one of those servers using the Set-
TransportServer cmdlet. For more information, see Managing the External Postmaster Address.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

Use the EAC to configure the external postmaster address

1. In the EAC, navigate to Mail flow > Receive connectors > More options > Organization transport
settings > Delivery tab.
2. In the External postmaster address field, enter the SMTP email address, for example,
[email protected] . If you want to return the external postmaster address to the default value, delete
any existing value so the field is blank.
3. When you're finished, click Save.

Use the Shell to configure the external postmaster address

To configure the external postmaster address, use the following syntax.
 Set-TransportConfig -ExternalPostmasterAddress <postmaster address>

For example, to set the external postmaster address to the value [email protected] , run the following
command

Set-TransportConfig -ExternalPostmasterAddress [email protected]

To return the external postmaster address to the default value, run the following command:

Set-TransportConfig -ExternalPostmasterAddress $null

How do you know this worked?

To verify that you have successfully configured the external postmaster address, do the following:
1. Run the following command on a Mailbox server to verify the external postmaster address value:

Get-TransportConfig | Format-List ExternalPostmasterAddress

2. From an external email account, send a message to your Exchange organization that will generate a delivery
status notification (DSN ). For example, you can configure a transport rule to send a non-delivery report
(NDR ) for a message from that sender that contains specific keywords. Verify the sender's email address in
the DSN matches the value you specified.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
 Connectors
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Connectors are used to control inbound and outbound mail flow in Microsoft Exchange Server 2013. With
connectors, you can route mail to and receive mail from recipients outside of your organization, a partner through
a secure channel, or a message-processing appliance.
The most commonly used connector types are Send connectors, which control outbound messages, and Receive
connectors, which control inbound messages.

For more information

Send connectors
Receive connectors
Create a Send connector for email sent to the Internet
Create a secure Receive connector to receive email from a partner
 Send connectors
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, a Send connector controls the flow of outbound messages to the receiving
server. They are configured on Mailbox servers running the Transport service. Most commonly, you configure a
Send connector to send outbound email messages to a smart host or directly to their recipient, using DNS.
Exchange 2013 Mailbox servers running the Transport service require Send connectors to deliver messages to the
next hop on the way to their destination. Send connectors that are created on Mailbox servers are stored in Active
Directory and are available to all Mailbox servers running the Transport service in the organization.

IMPORTANT
When you deploy Exchange 2013, outbound mail flow cannot occur until you configure a Send connector to route
outbound mail to the Internet. For more information, see Create a Send connector for email sent to the Internet.

Selecting the Type for a Send connector

Typically you create a Send connector in the Mail flow section of the Exchange admin center (EAC ). When you
create a new Send connector, you choose an available Type appropriate to your connection scenario. The type
determines the default permission sets that are assigned on the connector and grants those permissions to
trusted security principals. Security principals include users, computers, and security groups.
Procedures that explain specific Type selections include Create a Send connector to route outbound email
through a smart host and Create a Send connector to send email to a partner, with Transport Layer Security (TLS )
applied.
In you prefer using the Exchange Management Shell to the EAC, you can create a Send connector and specify a
type by using the New -SendConnector cmdlet.

New Send connector features in Exchange 2013

With the relationship between the Front End Transport service on Client Access servers and the Transport service
on Mailbox servers in Exchange 2013 comes new behavior for Send connectors. Firstly, you can set a Send
connector in the Transport service of a Mailbox server to route outbound mail through a Front End transport
server in the local Active Directory site, by means of the FrontEndProxyEnabled parameter of the Set-
SendConnector cmdlet, thus consolidating how email is routed from the Transport service. Mail routing provides
more information about transport services, routing behavior, and destinations in Exchange 2013. Mail flow
provides an overview of the transport pipeline and descriptions of each transport service.
The IsCoexistenceConnector parameter has been deprecated. In most cases, when you want to configure a hybrid
environment, where a portion of your mailboxes are hosted on-premises and a portion are hosted in the cloud,
we recommend that you use the Hybrid Configuration Wizard.
LinkedReceiveConnector has been deprecated. This parameter was used to create connectors that could route
messages to a third-party anti-spam service, for instance. Now, in most cases, you route mail to your anti-spam
service by means of your MX record, and the linked-connector behavior is not necessary.
The default maximum message size, specified by the MaxMessageSize parameter, has been increased from 10MB
to 25MB. Set-SendConnector provides more information on how to set parameters on a Send connector.
TlsCertificateName has been added. It is used to authenticate the local certificate to be used for outbound
connections and minimize the risk of fraudulent certificates.
 Create a Send connector for email sent to the
Internet
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

By default, Microsoft Exchange Server 2013 doesn't allow you to send mail outside of your domain. To send mail
outside your domain, you need to create a Send connector. The following graphic illustrates mail flow when you
create a Send connector to send mail to the Internet.

Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Send connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your outbound connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create a send connector for email sent to the Internet
1. In the EAC, navigate to Mail flow > Send connectors, and then click Add .
2. In the New send connector wizard, specify a name for the send connector and then select Internet for
the Type. Click Next.
3. Verify that MX record associated with recipient domain is selected, which specifies that the connector
uses the domain name system (DNS ) to route mail. Click Next.
4. Under Address space, click Add . In the Add domain window, make sure SMTP is listed as the Type.
For Fully Qualified Domain Name (FQDN ), enter *, which indicates that this send connector applies to
messages addressed to any domain. Click Save.
5. Make sure Scoped send connector is not selected and then click Next.
6. For Source server, click Add . In the Select a server window, select a Mailbox server that will be used
to send mail to the Internet via the Client Access server and click Add . After you've selected the server,
click Add . Click OK.
7. Click Finish.
Once you have created the Send connector, it appears in the Send connector list.

Use the Shell to route mail through the Client Access server
In Exchange 2013 you can use the FrontendProxyEnabled parameter of the Set-SendConnector cmdlet to route
outbound messages through the Client Access server. This parameter is not set to $true by default, but in many
cases it can consolidate and simplify mail flow, especially if you are working with an environment with a large
number of messaging servers.
This example sets the FrontendProxyEnabled parameter to $true on a Send connector.

Set-SendConnector "Contoso.com Send Connector" -FrontendProxyEnabled $true

How do you know this worked?

To verify that you have successfully created a Send Connector for email sent to the Internet, send mail from one
of your users to an outside recipient and verify that the message arrives successfully.

For more information

Send connectors
Create a Send connector to route outbound email through a smart host
 Create a Send connector to route outbound email
through a smart host
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In some situations you may want to route email through a third-party smart host, such as in an instance where
you have a network appliance that you want to perform policy checks on outbound messages.

NOTE
The third-party smart host must use SMTP for transport. If it does not, you should use a Foreign connector or Delivery
Agent connector.

Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Send connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your outbound connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create a Send connector to route outbound email

through a smart host
1. In the EAC, navigate to Mail flow > Send connectors, and then click Add .
2. In the New send connector wizard, specify a name for the send connector and then select Custom for the
Type. You typically choose this selection when you want to route messages to computers not running
Microsoft Exchange Server 2013. Click Next.
3. Choose Route mail through smart hosts, and then click Add . In the Add smart host window, specify
the IP address, such as 192.168.100.1, or the fully qualified domain name (FQDN ), such as contoso.com.
Click Save.
For Smart host authentication, choose the type of authentication required by the smart host. If you
choose Basic authentication, you must provide a user name and password.
 NOTE
If you choose Basic authentication, we recommend that you use an encrypted connection because the user name
and password are sent in clear text.

4. Under Address space, click Add . In the Add domain window, make sure SMTP is listed as the Type.
For Fully Qualified Domain Name (FQDN ), enter * to specify that this send connector applies to
messages sent to any domain. Click Save.
5. For Source server, click Add . In the Select a server window, choose a server and click Add . Click OK.
6. Click Finish.
Once you have created the send connector, it appears in the Send connector list.

How do you know this worked?

To verify that you have successfully created a Send connector to route outbound email through a smart host, send
a message from a user in your organization (you can use the Outlook Web App) to the domain you specified for
the Address space. If the recipient receives the message, you've successfully configured the send connector.

For more information

Create a Send connector for email sent to the Internet
Send connectors
 Create a Send connector to send email to a partner,
with Transport Layer Security (TLS) applied
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

If you want to ensure secure, encrypted communication with a partner, you can create a Send connector that is
configured to enforce Transport Layer Security (TLS ) for messages sent to a partner domain. TLS provides secure
communication over the Internet.
Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Send connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your outbound connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to create a Send connector to send email to a partner,

with TLS applied
To create a Send connector for this scenario, log in to the EAC and perform the following steps:
1. In the EAC, navigate to Mail flow > Send connectors, and then click Add .
2. In the New send connector wizard, specify a name for the send connector and then select Partner for the
Type. When you select Partner, the connector is configured to allow connections only to servers that
authenticate with TLS certificates. Click Next.
3. Verify that MX record associated with recipient domain is selected, which specifies that the connector
uses the domain name system (DNS ) to route mail. Click Next.
4. Under Address space, click Add . In the Add domain window, make sure SMTP is listed as the Type.
For Fully Qualified Domain Name (FQDN ), enter the name of your partner domain. Click Save.
5. For Source server, click Add . In the Select a server window, select a Mailbox server that will be used to
send mail to the Internet via the Client Access server and click Add . After you've selected the server, click
Add . Click OK.
6. Click Finish.
Once you have created the Send connector, it appears in the Send connector list.

How do you know this worked?

To verify that you have successfully created a Send connector to send email to a partner, with TLS applied, send a
message from a user in your organization to a recipient at the partner organization. If the recipient receives the
message, the connector was created successfully.

For more information

Create a Send connector for email sent to the Internet
Create a Send connector to route outbound email through a smart host
 Configure a cross-forest Send connector
6/7/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Active Directory, the forest represents the outer boundary of your directory service. You can create Send
connectors to enable communication between forests. In this example, the connectors use Basic authentication.
For additional management tasks related to configuring connectors, see Connectors.
Interested in scenarios where this procedure is used? See the following topics:
Deploy Exchange 2013 in a cross-forest topology

What do you need to know before you begin?

Estimated time to complete: 20 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Send connectors" entry and "Receive connectors" entry in the Mail flow
permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create connectors to configure a cross-forest topology.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Create a user account in each forest

You must create a user account in each forest to use for Basic authentication. Create an account in each forest and
add each to the universal security group of the Exchange Server used for communication. This account is used by
the Send connector to authenticate to the server receiving mail in the other forest. For example, provide a user
account that has the user principal name (UPN ) [email protected] as the credentials that must be used
for authentication by the Exchange server in the Fourth Coffee domain when mail is sent to the Exchange server in
the Contoso domain.

Use the EAC to create a send connector to route email to another

Exchange 2013 forest
Establish cross-forest mail flow using Basic authentication.
1. In the EAC, navigate to mail flow > send connectors. Click Add .
2. In the new send connector wizard, specify a name for the send connector and then select Internal for the
Type. Click next.
3. Choose Route mail through smart hosts, and then click Add . In the add smart host window, specify
the IP address of the target server in the second forest, such as 64.4.6.100. Click save and then next.
 For Smart host authentication, choose Basic authentication and provide a user name and password.
Here you can choose Offer basic authentication only after starting TLS for secure communication over
TLS.

NOTE
If you use Basic authentication over TLS, the target server must be configured to use an X.509 certificate.

4. Under Address space, click Add . In the add domain window, make sure SMTP is listed as the Type. For
Fully Qualified Domain Name (FQDN ), enter the receiving domain, such as fourthcoffee.com. Click
save and then next.
5. For Source server, click Add . In the Select a server window, choose the server to use and click add .
Click ok.
6. Click finish. The connector appears in the list of Send connectors.
After you create your Send connector, create a Send connector in the second forest that sends mail to the original
forest. In this case, the Fully Qualified Domain Name (FQDN ) you specify will be the domain name of the first
forest. For example, contoso.com.

Use the Shell to set permissions on the Send connector

This example uses the Enable-CrossForestConnector.ps1 script in the Shell to set permissions on the Send
connector for use in a cross-forest topology.

.\Enable-CrossForestConnector.ps1 -Connector "Cross-Forest" -user "ANONYMOUS LOGON"

How do you know this worked?

To verify that you have successfully created Send connectors to route email to a second forest, send a message
from a user in your organization (you can use the Outlook Web App) to the domain you specified for the Address
space. If the recipient receives the message, you've successfully configured the send connector.

For more information

Create a Send connector for email sent to the Internet
Send connectors
 Receive connectors
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Receive connectors control the flow of inbound messages to your Exchange organization. They are configured on
computers running Microsoft Exchange Server 2013 with the Transport service, or in the Front End service on a
Client Access server. They can be created in the Exchange admin center (EAC ), or in the Exchange Management
Shell.
By default, the Receive connectors that are required for internal mail flow are automatically created when a Client
Access server or Mailbox server is installed.
Exchange 2013 servers running the Transport service require Receive connectors to receive messages from the
Internet, from email clients, and from other email servers. A Receive connector controls inbound connections to
the Exchange organization.
Each Receive connector listens for inbound connections that match the settings of the Receive connector. A
Receive connector listens for connections that are received through a particular local IP address and port, and
from a specified IP address range. You can create a Receive connector when you want to control which servers
receive messages from a particular IP address or IP address range, and when you want to configure special
connector properties for messages that are received from a particular IP address, such as allowing larger
messages or more recipients per message. You can also scope the Receive connector using the
TlsCertificateName parameter of the Set-ReceiveConnector cmdlet, which allows you to specify the certificate
to use for the connector.
Receive connectors are scoped to a single server and determine how that specific server listens for connections.
When you create a Receive connector on a Mailbox server running the Transport service, the Receive connector is
stored in Active Directory as a child object of the server on which it's created.
If you need additional Receive connectors for specific scenarios, you can create them by using the EAC or the
Exchange Management Shell. Each Receive connector must use a unique combination of IP address bindings, port
number assignments, and remote IP address ranges from which mail is accepted.
For more information about how to create a Receive Connector, see Receive connector procedures.

Default Receive connectors created during setup

Certain Receive connectors are created by default when you install the Mailbox server role.

Default Receive connectors created on a Mailbox server running the

Transport service
When you install a Mailbox server running the Transport service, two Receive connectors are created. No
additional Receive connectors are needed for typical operation, and in most cases the default Receive connectors
don't require a configuration change. These connectors are the following:
Default <server name>: Accepts connections from Mailbox servers running the Transport service and
from Edge servers.
Client Proxy <server name>: Accepts connections from front-end servers. Typically, messages are sent
to a front-end server over SMTP.
Each connector is assigned a TransportRole value. You can use it to determine the role the connector is running in.
This can be helpful in cases where you are running multiple roles on a single server. In the case of each Receive
connector previously mentioned, their TransportRole value is HubTransport.
To view the default Receive connectors and their parameter values, you can use the Get-ReceiveConnector cmdlet.

Default Receive connectors created on a Front End Transport server

During installation, three Receive connectors are created on the Front End transport, or Client Access server. The
default Front End Receive connector is configured to accept SMTP communications from all IP address ranges.
Additionally, there is a Receive connector that can act as an outbound proxy for messages sent to the front-end
server from Mailbox servers. Finally, there is a secure Receive connector configured to accept messages encrypted
with Transport Layer Security (TLS ). These connectors are the following:
Default FrontEnd <server name>: Accepts connections from SMTP senders over port 25. This is the
common messaging entry point into your organization.
Outbound Proxy Frontend <server name>: Accepts messages from a Send Connector on a back-end
server, with front-end proxy enabled.
Client Frontend <server name>: Accepts secure connections, with Transport Layer Security (TLS )
applied.
In a typical installation, no additional Receive connectors are required.

Receive connector types

The type determines the default security settings for each Receive connector.
The security settings for a Receive connector specify the permissions that are granted to sessions that connect to
the Receive connector and the supported authentication mechanisms.
When you use the EAC to configure a Receive connector, the new receive connector page prompts you to select
the type for the connector. Based on your selection, parameters are set to conform to the configuration you have
chosen. Specific procedures contain more information about Receive connector type settings. Examples of these
procedures are Create a Receive connector to receive email from the Internet and Create a secure Receive
connector to receive email from a partner.

Receive connector permission groups

A permission group is a predefined set of permissions that's granted to well-known security principals and
assigned to a Receive connector. Security principals include users, computers, and security groups. The use of
permission groups simplifies the configuration of permissions on Receive connectors. The PermissionGroups
property defines the groups or roles that can submit messages to the Receive connector and the permissions that
are assigned to those groups.
Permission groups include Anonymous, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, and Partner.

Receive connector type specifications

The type determines the default permission groups that are assigned to the Receive connector and the default
authentication mechanisms that are available for session authentication. The following list describes the available
types:
1. Client: Typically used to connect to clients not using Microsoft Outlook. It can use TLS authentication.
2. Custom: Typically used in a cross-forest scenario, or in a scenario where your organization receives
 messages from an SMTP message transfer agent.
3. Internal: Used for communication between servers running the Transport service, or between Mailbox
servers running the Transport service and third-party transfer agents.
4. Internet: Used to receive SMTP mail from the Internet.
5. Partner: Use this type when you want to configure secure communication with a partner.
Each type is appropriate for a specific connection scenario. Select the type that has the default settings most
applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and
Remove-ADPermission cmdlets. For more information, see the following topics:
Add-ADPermission
Remove-ADPermission

Receive connector permissions

Receive connector permissions are assigned to security principals when you specify the permission groups for the
connector. When a security principal establishes a session with a Receive connector, the Receive connector
permissions determine whether the session is accepted and how the received messages are processed. You can set
Receive connector permissions by using the EAC or by using the PermissionGroups parameter with the Set-
ReceiveConnector cmdlet in the Shell. To modify the default permissions for a Receive connector, you can also
use the Add-ADPermission cmdlet.
Receive connector permissions contains a table that lists security principals and permissions types in detail.

Receive connector authentication settings

In the EAC, you use the authentication settings for a Receive connector to specify the authentication mechanisms
that are supported by the Exchange 2013 transport server. In the Shell, you use the AuthMechanisms parameter
to specify the supported authentication mechanisms. You can configure more than one authentication mechanism
for a Receive connector. For more information, see Receive connector authentication mechanisms.

New Receive connector features in Exchange 2013

The following features were added in Exchange 2013:
With the TlsCertificateName parameter you can specify the local Certificate Authority (CA) issued
certificate to use for secure mail. It helps minimize the risk of fraudulent certificates.
The TransportRole parameter designates the server role associated with this connector. It is typically used
to specify the server role when you host multiple server roles on a single computer.
See New -ReceiveConnector for more information about these parameters and other parameters for Receive
connectors.
 Receive connector permissions
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following table lists permission types and a description for each.

RECEIVE CONNECTOR PERMISSION DESCRIPTION

ms-Exch-SMTP-Submit The session must be granted this permission or it will be

unable to submit messages to this Receive connector. If a
session doesn't have this permission, the MAIL FROM and
AUTH commands will fail.

ms-Exch-SMTP-Accept-Any-Recipient This permission allows the session to relay messages

through this connector. If this permission isn't granted,
only messages that are addressed to recipients in
accepted domains are accepted by this connector.

ms-Exch-SMTP-Accept-Any-Sender This permission allows the session to bypass the sender

address spoofing check.

ms-Exch-SMTP-Accept-Authoritative-Domain-Sender This permission allows senders that have e-mail addresses

in authoritative domains to establish a session to this
Receive connector.

ms-Exch-SMTP-Accept-Authentication-Flag This permission allows Exchange 2003 servers to submit

messages from internal senders. Exchange 2010 will
recognize the messages as being internal. The sender can
declare the message as trusted. Messages that enter your
Exchange system through anonymous submissions will be
relayed through your Exchange organization with this flag
in an untrusted state.

ms-Exch-Accept-Headers-Routing This permission allows the session to submit a message

that has all received headers intact. If this permission isn't
granted, the server will strip all received headers.

ms-Exch-Accept-Headers-Organization This permission allows the session to submit a message

that has all organization headers intact. Organization
headers all start with X-MS-Exchange-Organization-. If
this permission isn't granted, the receiving server will strip
all organization headers.

ms-Exch-Accept-Headers-Forest This permission allows the session to submit a message

that has all forest headers intact. Forest headers all start
with X-MS-Exchange-Forest-. If this permission isn't
granted, the receiving server will strip all forest headers.
RECEIVE CONNECTOR PERMISSION DESCRIPTION

ms-Exch-Accept-Exch50 This permission allows the session to submit a message

that contains the XEXCH50 command. This command is
needed for interoperability with Exchange 2003. The
XEXCH50 command provides data such as the spam
confidence level (SCL) for the message.

ms-Exch-Bypass-Message-Size-Limit This permission allows the session to submit a message

that exceeds the message size restriction configured for
the connector.

Ms-Exch-Bypass-Anti-Spam This permission allows the session to bypass anti-spam

filtering.
 Receive connector authentication mechanisms
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The Receive connector authentication mechanisms are the following:

AUTHENTICATION MECHANISM DESCRIPTION

None No authentication.

TLS Advertise STARTTLS. Requires availability of a server

certificate to offer TLS.

Integrated NTLM and Kerberos (Integrated Windows authentication).

BasicAuth Basic authentication. Requires an authenticated logon.

BasicAuthRequireTLS Basic authentication over TLS. Requires a server certificate.

ExchangeServer Exchange Server authentication (Generic Security Services

application programming interface (GSSAPI) and Mutual
GSSAPI).

ExternalAuthoritative The connection is considered externally secured by using a

security mechanism that's external to Exchange. The
connection may be an Internet Protocol security (IPsec)
association or a virtual private network (VPN).
Alternatively, the servers may reside in a trusted physically
controlled network. The ExternalAuthoritative
authentication method requires the ExchangeServers
permission group. This combination of authentication
method and security group permits the resolution of
anonymous sender email addresses for messages that are
received through this connector.

For more information about Receive Connector authentication mechanisms, see New -ReceiveConnector.
 Receive connector procedures
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Create a Receive connector to receive email from the Internet
Create a secure Receive connector to receive email from a partner
Create a Receive connector to receive email from a system not running Exchange
Create a Receive connector to receive messages from an internal Exchange server
 Create a Receive connector to receive email from the
Internet
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

This procedure shows you how to configure a Receive connector to receive email from the Internet.

NOTE
In most cases, you won't need to explicitly set up a Receive connector to receive mail from the Internet, because a Receive
connector to accept mail from the Internet is implicitly created upon installation of Exchange. See Receive connectors for
more information.

Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Receive connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your receive connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to Create a Receive Connector to Receive Messages from

the Internet
1. In the EAC, navigate to Mail flow > Receive connectors. Click Add to create a Receive connector.
2. On the New receive connector page, specify a name for the Receive connector and then select Frontend
transport for the Role. Since you are receiving mail from the Internet in this case, we recommend that you
initially route mail to your Front End server or servers, to simplify and consolidate your mail flow.
3. Choose Internet for the type. The Receive connector will receive mail from Internet senders.
4. For the Network adapter bindings, observe that All available IPV4 is listed in the IP addresses list and
the Port is 25. (Simple Mail Transer Protocol (SMTP ) uses port 25.) This indicates that the connector listens
for connections on all IP addresses assigned to network adapters on the local server.
 NOTE
If you have multiple network adapters, on this page you can add an IP address that is assigned to a specific network
adapter on the local server, but this isn't required.

5. Click the Finish button to create your connector.

Once you have created the Receive connector, it appears in the Receive connector list. If you would like to see an
example of how to create a Receive connector with a cmdlet, see New -ReceiveConnector.

How do you know this worked?

To verify that you have successfully created a Receive connector to receive messages from the Internet, test that
you can send mail from an outside source and one of your users can receive it. If you can receive mail, you know
that the configuration worked successfully.

For more information

Create a secure Receive connector to receive email from a partner
Create a Receive connector to receive email from a system not running Exchange
 Create a secure Receive connector to receive email
from a partner
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

This procedure shows you how to configure a Receive connector to receive secure email from a partner. Use this
procedure when you are required to encrypt communication between you and a trusted partner. The connector is
configured to accept connections only from servers that authenticate with Transport Layer Security (TLS ).
Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Receive connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your receive connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to Create a Receive Connector to Receive Secure

Messages from a Partner
1. In the EAC, navigate to Mail flow > Receive connectors. Click Add to create a new Receive connector.
2. On the New receive connector page, specify a name for the Receive connector and then select Frontend
Transport for the Role. Since you are receiving mail from a partner in this case, we recommend that you
initially route mail to your front end server to simplify and consolidate your mail flow.
3. Choose Partner for the type. The Receive connector will receive mail from a trusted third party.
4. For the Network adapter bindings, observe that All available IPV4 is listed in the IP addresses list
and the Port is 25. (Simple Mail Transfer Protocol uses port 25.) This indicates that the connector listens
for connections on all IP addresses assigned to network adapters on the local server. Click Next.
5. If the Remote network settings page lists 0.0.0.0-255.255.255.255, which means that the Receive connector
receives connections from all IP addresses, click Remove to remove it. Click Add , add the IP address
for your partner's server, and click Save.
 NOTE
You can also specify an IP address range with CIDR notation, such as 64.4.6.100/24.

6. Click Finish to create the connector.

Once you have created the Receive connector, it appears in the Receive connector list. If you would like to see an
example of how to create a Receive connector with a cmdlet, see New -ReceiveConnector.

How do you know this worked?

To verify that you have successfully created a Receive connector to receive messages from a partner, test that the
partner can send mail to one of your users and that the user successfully receives it. If you can receive encrypted
mail (you can verify that TLS is used by checking the message header), you know that the configuration worked
successfully.

For more information

Receive connectors
 Create a Receive connector to receive email from a
system not running Exchange
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You may have a situation where you want to receive messages from a system not running Exchange. For instance,
if you have a network appliance that performs policy checks and then routes messages to your Exchange server.
We assume in this case that the appliance uses SMTP. If not, you should use a Foreign connector or a Delivery
Agent connector.
Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Receive connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your receive connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to Create a Receive Connector to Receive Messages from

a Messaging Appliance
1. In the EAC, navigate to Mail flow > Receive connectors. Click Add to create a Receive connector.
2. On the New receive connector page, specify a name for the Receive connector and then select Hub
Transport for the Role. In this case, you want your Mailbox server running the Transport service to receive
messages from the appliance.
3. Choose Custom for the type, since the Receive connector will receive mail from an appliance not running
Microsoft Exchange Server 2013.
4. For the Network adapter bindings, observe that All available IPV4 is listed in the IP addresses list.
Click Next.
5. For Remote network settings, click Remove to remove 0.0.0.0-255.255.255.255 from the IP
addresses list, since you want to specify that the connector accepts mail from a specific appliance. Click
Add to add a new IP address, and in the Add IP address window, add the IP address of your appliance.
Click Save.
6. Click the Finish button to create your connector.
Once you have created the Receive connector, it appears in the Receive connector list. If you would like to see an
example of how to create a Receive connector with a cmdlet, see New -ReceiveConnector.

How do you know this worked?

To verify that you have successfully created a Receive connector to receive messages from a messaging appliance,
test that you can receive mail from the appliance. If you can receive mail, you know that the configuration worked
successfully.

For more information

Create a Receive connector to receive email from the Internet
 Create a Receive connector to receive messages from
an internal Exchange server
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You create a Receive connector of the Internal type when you want to receive mail from an Exchange server. Use
this type of connector to control mail routing within your organization: for example, when you want to route mail
from the Transport service on a Mailbox server to a specific Edge Transport server, or from one Mailbox server to
another.
Interested in scenarios where this procedure is used? See the following topics:
Configure mail flow and client access

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Receive connectors" entry in the Mail flow permissions topic.
See Deploy a new installation of Exchange 2013 if you are beginning your installation. After the installation
you can use the steps in this topic to create your receive connector.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Create a Receive Connector to Receive Messages from an Internal

Exchange Server
1. In the EAC, navigate to Mail flow > Receive connectors. Click Add to create a new Receive connector.
2. On the New receive connector page, specify a name for the Receive connector and then select Hub
transport for the Role. In this case we assume you want to route mail within your network, not into and out
of the organization.
3. Choose Internal for the type. The connector is configured with Exchange server authentication.
4. If the Remote network settings page lists 0.0.0.0-255.255.255.255, which means that the Receive connector
receives connections from all IP addresses, click Remove to remove it. Click Add , add the IP address
for the server you want to receive mail from, such as 192.168.1.1, and click Save.
5. Click Finish to create the connector.
Once you have created the Receive connector, it appears in the Receive connector list. If you would like to see an
example of how to create a Receive connector with a cmdlet, see New -ReceiveConnector.
How do you know this worked?
To verify that you have successfully created a Receive connector to receive messages from an internal server, test
that messages from the sending server travel successfully to the recipient server. One way to do this is to use the
Exchange Management Shell to set the ProtocolLoggingLevel for the Receive connector you created to Verbose ,
using the Set-ReceiveConnector cmdlet, and check the logs to ensure message delivery.

For more information

Create a Receive connector to receive email from the Internet
Create a secure Receive connector to receive email from a partner
 Modify the SMTP banner on a Receive connector
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The SMTP banner is the SMTP connection response that a remote SMTP messaging server receives after it
connects to a Receive connector that's configured on a computer running Microsoft Exchange Server 2013.
This is the default response received by a remote SMTP messaging server after it connects to the Receive
connector:

220 <Servername> Microsoft ESMTP MAIL service ready at <RegionalDay-Date-24HourTimeFormat>

<RegionalTimeZoneOffset>

When you specify a custom value for SMTP banner on a Receive connector, a remote SMTP messaging server that
connects to that SMTP Receive connector receives the following response.

220 <Banner Text>

You may want to modify the SMTP banner for Internet-facing SMTP Receive connectors so the server name and
messaging server software aren't disclosed by the SMTP banner.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Receive connectors" entry in the Mail flow permissions topic.
You can only use the Shell to perform this procedure.
The replacement SMTP banner text string must always start with 220 . As defined in RFC 2821, the default
service ready SMTP response code is 220.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to modify the SMTP banner on a Receive connector

Run the following command:

Set-ReceiveConnector <ConnectorIdentity> -Banner "220 <Banner Text>"

This example modifies the SMTP banner on the existing Receive connector named From the Internet so the SMTP
banner displays 220 Contoso Corporation .
 Set-ReceiveConnector "From the Internet" -Banner "220 Contoso Corporation"

This example removes the custom SMTP banner on the Receive connector named From the Internet, which returns
the SMTP banner to the default value.

Set-ReceiveConnector "From the Internet" -Banner $null

How do you know this worked?

To verify that you have successfully modified the SMTP banner on a Receive connector, do the following:
1. Open a telnet client on a computer that can access the Receive connector, and run the following command:

open <Connector FQDN or IP address> <Port>

2. Verify the response from the Receive connector contains the SMTP banner you configured.
Note that this procedure only works on Receive connectors that allow anonymous or Basic authentication. For
more information, see Use Telnet to test SMTP communication.
 Foreign connectors
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

A Foreign connector delivers messages to a server or foreign system that does not use SMTP as its primary
transport mechanism. An example of this can be a fax-gateway server. A Foreign connector uses a local or shared
Drop directory to send outbound messages, by means of a file transfer, to the foreign system. Foreign connectors
are created in the Transport service of a Microsoft Exchange Server 2013 Mailbox server.
Foreign gateway servers can send messages into the Exchange 2013 organization by using the Pickup or Replay
directories that exist in the Transport service of a Mailbox server. Correctly formatted email message files that you
copy to each directory are submitted for delivery to an Exchange mailbox.

TIP
In most cases where you must deliver outbound messages to a non-SMTP system, we recommend Delivery Agent
connectors, because they allow for queue management of messages, messages do not have to be written to the file system,
and other benefits. The Delivery agents and Delivery Agent connectors topic provides more details.

For more information

Create a Foreign connector to deliver messages to a non-SMTP fax gateway
Delivery agents and Delivery Agent connectors
New -ForeignConnector
Set-ForeignConnector
 Create a Foreign connector to deliver messages to a
non-SMTP fax gateway
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

You may have a scenario where you want to send messages to and receive messages from a fax-gateway server
that doesn't use SMTP as its primary transport mechanism. Follow the steps outlined in this procedure to create a
Foreign connector that delivers messages to and receives messages from the foreign system.

TIP
In most cases where you must deliver outbound messages to a non-SMTP system, we recommend Delivery Agent
connectors, because they allow for queue management of messages, messages do not have to be written to the file system,
and other benefits. The Delivery agents and Delivery Agent connectors topic provides more details.

Interested in scenarios where this procedure is used? See Planning and deployment.

What do you need to know before you begin?

Estimated time to complete this task: 30 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Foreign connectors" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Use the Shell to create a Foreign connector that sends

messages to a non-SMTP gateway server
1. Run the following command to create the Foreign connector:

New-ForeignConnector -Name "Contoso Foreign Connector" -AddressSpaces "X400:c=US;a=Fabrikam;P=Contoso;5"

-SourceTransportServers Hub01,Hub02

In this example, Hub01 and Hub02 are source servers in your organization that you designate to deliver
messages to the foreign system. Using more than one source server provides fault tolerance.
Once you have created the Foreign Connector, you can configure the Drop Pickup, and Replay directories,
depending on the requirements for your organization.
How do you know this step worked?
To verify that the Foreign connector was created successfully, run the following command:
 Get-ForeignConnector | Format-List Name

Verify that the name for the Foreign connector you created appears.

Step 2: Use the Shell to configure the Drop directory for a Mailbox
server running the Transport service
The Drop directory for a Mailbox server running the Transport service is used to deliver outbound messages from
your Foreign connector.
You create a directory to use as the Drop directory on your local file system. You can also use a directory on a
network file share.
1. Run the following script to specify the Drop directory for your Foreign connector (change the value for the
DropDirectory parameter to a path appropriate for your environment):

Set-ForeignConnector "Contoso Foreign Connector" -DropDirectory "C:\Drop Directory"

How do you know this step worked?

To verify that you have set the Drop Directory correctly, you can run the following cmdlet script and verify the
value for the DropDirectory parameter:

Get-ForeignConnector "Contoso Foreign Connector" | Format-List

Once you have created your Foreign connector and specified your Drop directory, you can send a message using
the Mailbox server where you created your Foreign connector and verify that a file is delivered to the Drop
directory.

Step 3: Use the Shell to configure the Pickup directory for the
Transport service on a Mailbox server
The Pickup directory for the Transport service on a Mailbox server is used to collect messages generated by non-
SMTP systems. Use this procedure in cases where you want to gather new messages generated by a non-SMTP
system, such as a fax gateway server, by means of file transfer.
For detailed instructions for configuring your Pickup directory, see Configure the Pickup directory and the Replay
directory.
How do you know this step worked?
To verify that you have set the Pickup directory correctly, you can run the following command and verify the value
for the PickupDirectoryPath parameter:

Get-TransportService | Format-List PickupDirectoryPath

Step 4: Use the Shell to configure the Replay directory for the
Transport service on a Mailbox server
The Replay directory for the Transport service on a Mailbox server is used to collect messages generated by non-
SMTP systems. Use this procedure to configure the Replay directory in cases where you want to resubmit email
messages, typically from a non-SMTP foreign gateway server, that were generated in your Exchange environment
and exported from Exchange transport.
For detailed instructions for configuring your Pickup directory, see Configure the Pickup directory and the Replay
directory.
How do you know this step worked?
To verify that you have set the Replay directory correctly, you can run the following command and verify the value
for the ReplayDirectoryPath parameter:

Get-TransportService | Format-List ReplayDirectoryPath

For more information

Foreign connectors
Delivery agents and Delivery Agent connectors
 Delivery agents and Delivery Agent connectors
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

A delivery agent can deliver messages from your SMTP Exchange Server environment to a system that doesn't
use the SMTP protocol. Each delivery agent is associated with a Delivery Agent connector, which queues
messages routed to the delivery agent for processing and delivery to the non-SMTP device or system.

TIP
While the Foreign connector architecture remains in Microsoft Exchange 2013, we recommend using delivery agents for
routing messages to non-SMTP systems whenever possible. The primary reasons for this are that you can use queue
management for messages, there is no need to manage file transfer to a Drop directory, and you can verify message
delivery.

Function and benefits of Delivery Agents

A delivery agent is a component installed in the Transport service of a Mailbox server that can perform the
following tasks:
Establish a connection to the foreign system for message delivery.
Retrieve messages from the delivery queues on Mailbox servers.
Deliver messages to the foreign system.
Provide acknowledgement for each successful message delivery.
While the Foreign connector architecture remains in Microsoft Exchange Server 2013, we recommend using
delivery agents for routing messages to non-SMTP systems whenever possible. Delivery agents provide the
following benefits:
They allow queue management of messages routed to foreign systems.
Because the messages no longer need to be written to and read from the file system, message delivery
performance is improved.
They provide access to message properties with rich events for agent developers.
Development time for a delivery agent is faster than implementing a Foreign connector because the
delivery agent can use the message representation and management features of Exchange.
You can verify that the messages are delivered to the foreign system, rather than simply written to the Drop
directory.
The use of Delivery Agent connectors allows service level agreement (SLA) analysis because it's possible to
track the latency of message delivery to the foreign system.

Adding Delivery Agents to your organization

To use a delivery agent in your organization, you have to complete the following:
1. Acquire the delivery agent. Typically, delivery agents are written by third parties. Exchange 2013 comes
 with only one Delivery Agent connector by default: the Text Messaging Delivery Agent connector.
2. Install the delivery agent in the Transport service of your Mailbox servers that will act as source servers for
the Delivery Agent connectors.
3. Create a Delivery Agent connector for the specific protocol.
When all of these steps are completed, messages to the foreign systems will be routed through the Delivery Agent
connectors and processed by the delivery agent.
Microsoft.Exchange.Data.Transport.Delivery Namespace provides more information about developing a delivery
agent.

Delivery Agent connectors

A Delivery Agent connector in Exchange 2013 is similar to the Delivery Agent connector introduced in Exchange
2010. They route messages addressed to foreign systems that do not use the SMTP protocol. When a message is
routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message
delivery. Typically, delivery agents are created by a third-party and configured to work with a Delivery Agent
connector in your organization.
A Delivery Agent connector cannot be created in the Exchange admin center. Rather, you create a Delivery Agent
connector in the Exchange Management Shell with the New -DeliveryAgentConnector cmdlet and edit the
Delivery Agent connector's properties with Set-DeliveryAgentConnector. You can specify one or more host
Mailbox servers for the connector, by using the optional SourceTransportServers parameter.

Default text messaging Delivery Agent connector

You can use the Text Messaging Delivery Agent connector to route messages to mobile devices. On your
Exchange server, run Get-DeliveryAgentConnector | fl to view the connector and all of its parameters. Note that
the DeliveryProtocol is set to MOBILE .
 Header firewall
6/14/2019 • 11 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, header firewall is a mechanism that removes specific header fields from
inbound and outbound messages. There are two different types of header fields that are affected by header firewall:
X-headers: An X-header is a user-defined, unofficial header field. X-headers aren't specifically mentioned in
RFC 2822, but the use of an undefined header field starting with X- has become an accepted way to add
unofficial header fields to a message. Messaging applications, such as anti-spam, antivirus, and messaging
servers may add their own X-headers to a message. In Exchange, the X-header fields contain details about
the actions that are performed on the message by the Transport service, such as the spam confidence level
(SCL ), content filtering results, and rules processing status. Revealing this information to unauthorized
sources could pose a potential security risk.
Routing headers: Routing headers are standard SMTP header fields that are defined in RFC 2821 and
RFC 2822. Routing headers stamp a message by using information about the different messaging servers
that were used to deliver the message to the recipient. Routing headers that are inserted into messages by
malicious users can misrepresent the routing path that a message traveled to reach a recipient.
Header firewall prevents the spoofing of these Exchange-related X-headers by removing them from inbound
messages that enter the Exchange organization from untrusted sources. Header firewall prevents the disclosure of
these Exchange-related X-headers by removing them from outbound messages sent to untrusted destinations
outside the Exchange organization. Header firewall also prevents the spoofing of standard routing headers that are
used to track the routing history of a message.

Message header fields affected by header firewall in Exchange

The following types of X-headers and routing headers are affected by header firewall:
Organization X-headers: These X-header fields start with X-MS -Exchange-Organization-.
Forest X-headers: These X-header fields start with X-MS -Exchange-Forest-.
For examples of organization X-headers and forest X-headers, see the Organization X-headers and forest X-
headers in Exchange section at the end of this topic.
Received: routing headers: A different instance of this header field is added to the message header by
every messaging server that accepted and forwarded the message to the recipient. The Received: header
typically includes the name of the messaging server and a date-timestamp.
Resent-*: routing headers: Resent header fields are informational header fields that can be used to
determine whether a message has been forwarded by a user. The following resent header fields are
available: Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc:, and
Resent-Message-ID:. The Resent- fields are used so that the message appears to the recipient as if it was
sent directly by the original sender. The recipient can view the message header to discover who forwarded
the message.
Exchange uses two different ways to apply header firewall to organization X-headers, forest X-headers, and routing
headers that exist in messages:
Permissions are assigned to Send connectors or Receive connectors that can be used to preserve or remove
 specific types of headers in messages when the message travels through the connector.
Header firewall is automatically implemented for specific types of headers in messages during other types of
message submission.

How header firewall is applied to Receive connectors and Send

connectors
Header firewall is applied to messages that travel through Send connectors and Receive connectors based on
specific permissions that are assigned to the connectors.
If the permission is assigned to the Receive connector or Send connector, header firewall isn't applied to the
messages that travel through the connector. The affected header fields are preserved in the messages.
If the permission isn't assigned to the Receive connector or Send connector, header firewall is applied to the
messages that travel through the connector. The affected header fields are removed from the messages.
The following table describes the permissions on Send connectors and Receive connectors that are used to apply
header firewall, and the affected header fields.

CONNECTOR TYPE PERMISSION DESCRIPTION

Receive connector Ms-Exch-Accept-Headers- This permission affects organization

Organization X-header fields that start with X-
MS-Exchange-Organization- in
inbound messages.

Receive connector Ms-Exch-Accept-Headers-Forest This permission affects forest X-

header fields that start with X-MS-
Exchange-Forest- in inbound
messages.

Receive connector Ms-Exch-Accept-Headers- This permission affects Received:

Routing and Resent-*: routing header fields
in inbound messages.

Send connector Ms-Exch-Send-Headers- This permission affects organization

Organization X-header fields that start with X-
MS-Exchange-Organization- in
outbound messages.

Send connector Ms-Exch-Send-Headers-Forest This permission affects forest X-

header fields that start with X-MS-
Exchange-Forest- in outbound
messages.

Send connector Ms-Exch-Send-Headers-Routing This permission affects Received:

and Resent-*: routing header fields
in outbound messages.

Header firewall for inbound messages on Receive connectors

The following table describes the default application of the header firewall permissions on Receive connectors.
 DEFAULT USAGE TYPE THAT
DEFAULT EXCHANGE SECURITY PERMISSION GROUP THAT ASSIGNS THE PERMISSION
PRINCIPALS THAT HAVE THE HAS THE SECURITY GROUPS TO THE RECEIVE
PERMISSION PERMISSION ASSIGNED PRINCIPALS AS MEMBERS CONNECTOR

Ms-Exch-Accept- Hub Transport ExchangeServers Internal

Headers-Organization servers
and Ms-Exch-Accept-
Headers-Forest Edge Transport
servers
Exchange Servers

NOTE
On Hub
Transport
servers only

Ms-Exch-Accept- Anonymous user Anonymous Internet

Headers-Routing account

Ms-Exch-Accept- Authenticated user ExchangeUsers Client (unavailable on

Headers-Routing accounts Edge Transport servers)

Ms-Exch-Accept- Hub Transport ExchangeServers Internal

Headers-Routing servers
Edge Transport
servers
Exchange Servers

NOTE
Hub
Transport
servers only

Externally
Secured servers

Ms-Exch-Accept- Partner Server account Partner Internet and

Headers-Routing Partner

Header firewall on custom Receive connectors

If you want to apply header firewall to messages in a custom Receive connector scenario, use any of the following
methods:
Create the Receive connector with a usage type that automatically applies header firewall to messages. Note
that you can set the usage type only when you create the Receive connector.
To remove the organization X-headers or forest X-headers from messages, create a Receive
connector and select a usage type other than Internal .
 To remove the routing headers from messages, do one of the following actions:
Create a Receive connector and select the usage type Custom . Don't assign any permission
groups to the Receive connector.
Modify an existing Receive connector, and set the PermissionGroups parameter to the value
None .

Note that if you have a Receive connector that has no permission groups assigned to it, you
need to add security principals to the Receive connector as described in the last step.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Headers-Organization
permission, the Ms-Exch-Accept-Headers-Forest permission, and the Ms-Exch-Accept-Headers-
Routing permission from a security principal that's configured on the Receive connector. This method
doesn't work if the permission has been assigned to the security principal using a permission group on the
Receive connector, because you can't modify the permissions assignments or the group membership of a
permission group.
Use the Add-ADPermission cmdlet to add the appropriate security principals that are required for mail
flow on the Receive connector. Make sure that no security principals have the Ms-Exch-Accept-Headers-
Organization permission, the Ms-Exch-Accept-Headers-Forest permission, and the Ms-Exch-Accept-
Headers-Routing permission assigned to them. If necessary, use the Add-ADPermission cmdlet to deny
the Ms-Exch-Accept-Headers-Organization permission, the Ms-Exch-Accept-Headers-Forest
permission, and the Ms-Exch-Accept-Headers-Routing permission to the security principals that are
configured on the Receive connector.
For more information, see the following topics:
Receive connectors
Add-ADPermission
Remove-ADPermission

Header firewall for outbound messages on Send connectors

The following table describes the default application of the header firewall permissions on Send connectors.

DEFAULT USAGE TYPE THAT ASSIGNS THE

DEFAULT EXCHANGE SECURITY PRINCIPALS SECURITY PRINCIPALS TO THE SEND
PERMISSION THAT HAVE THE PERMISSION ASSIGNED CONNECTOR

Ms-Exch-Send-Headers- Hub Transport servers Internal

Organization and Ms-Exch-Send-
Headers-Forest Edge Transport servers
Exchange Servers

NOTE
On Hub Transport
servers only

Externally Secured servers

ExchangeLegacyInterop
universal security group
 DEFAULT USAGE TYPE THAT ASSIGNS THE
DEFAULT EXCHANGE SECURITY PRINCIPALS SECURITY PRINCIPALS TO THE SEND
PERMISSION THAT HAVE THE PERMISSION ASSIGNED CONNECTOR

Ms-Exch-Send-Headers-Routing Hub Transport servers Internal

Edge Transport servers

Exchange Servers

NOTE
On Hub Transport
servers only

Externally Secured servers

ExchangeLegacyInterop
universal security group

Ms-Exch-Send-Headers-Routing Anonymous User Account Internet

Ms-Exch-Send-Headers-Routing Partner Servers Partner

Header firewall on custom Send connectors

If you want to apply header firewall to messages in a custom Send connector scenario, use the any of the following
methods:
Create the Send connector with a usage type that automatically applies header firewall to messages. Note
that you can set the usage type only when you create the Send connector.
To remove the organization X-headers or forest X-headers from messages, create a Send connector
and select a usage type other than Internal or Partner .
To remove the routing headers from messages, create a Send connector and select the usage type
Custom . The Ms-Exch -Send-Headers-Routing permission is assigned to all Send connector usage
types except Custom .
Remove a security principal that assigns the Ms-Exch-Send-Headers-Organization permission, the Ms-
Exch-Send-Headers-Forest, and the Ms-Exch-Send-Headers-Routing permission from the connector.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Organization
permission, the Ms-Exch-Send-Headers-Forest permission, and the Ms-Exch-Send-Headers-Routing
permission from one of the security principals that's configured on the Send connector.
Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Organization permission, the
Ms-Exch-Send-Headers-Forest permission, and the Ms-Exch-Send-Headers-Routing permission to
one of the security principals that are configured on the Send connector.
For more information, see the following topics:
Send connectors
Add-ADPermission
Remove-ADPermission
Header firewall for other message sources
Messages can enter the transport pipeline on a Mailbox server or an Edge Transport server without using Send
connectors or Receive connectors. Header firewall is applied to these other message sources as described in the
following list:
Pickup directory and Replay directory: The Pickup directory is used by administrators or applications to
submit message files. The Replay directory is used to resubmit messages that have been exported from
Exchange message queues. For more information about the Pickup and Replay directories, see Pickup
directory and Replay directory.
Organization X-headers, forest X-headers, and routing headers are removed from the message files in the
Pickup directory.
Routing headers are preserved in messages submitted by the Replay directory.
Whether or not organization X-headers and forest X-headers are preserved or removed from messages in
the Replay directory is controlled by the X-CreatedBy: header field in the message file:
If the value of X-CreatedBy: is MSExchange15 , organization X-headers and forest X-headers are
preserved in messages.
If the value of X-CreatedBy: isn't MSExchange15 , organization X-headers and forest X-headers are
removed from messages.
If the X-CreatedBy: header field doesn't exist in the message file, organization X-headers and forest
X-headers are removed from messages.
Drop directory: The Drop directory is used by Foreign connectors on Mailbox servers to send messages to
messaging servers that don't use SMTP to transfer messages. For more information about Foreign
connectors, see Foreign connectors.
Organization X-headers and forest X-headers are removed from message files before they're put in the
Drop directory.
Routing headers are preserved in messages submitted by the Drop directory.
Mailbox Transport: The Mailbox Transport service exists on Mailbox servers to transmit messages to and
from mailboxes on Mailbox servers. For more information about the Mailbox Transport service, see Mail
flow.
Organization X-headers, forest X-headers, and routing headers are removed from outgoing messages that
are sent from mailboxes by the Mailbox Transport Submission service.
Routing headers are preserved for inbound messages to mailbox recipients by the Mailbox Transport
Delivery service. The following organization X-headers are preserved for inbound messages to mailbox
recipients by the Mailbox Transport Delivery service:
X-MS -Exchange-Organization-SCL
X-MS -Exchange-Organization-AuthDomain
X-MS -Exchange-Organization-AuthMechanism
X-MS -Exchange-Organization-AuthSource
X-MS -Exchange-Organization-AuthAs
X-MS -Exchange-Organization-OriginalArrivalTime
X-MS -Exchange-Organization-OriginalSize
 DSN messages: Organization X-headers, forest X-headers, and routing headers are removed from the
original message or the original message header that's attached to the DSN message. For more information
about DSN messages, see DSNs and NDRs in Exchange 2013.
Transport agent submission: Organization X-headers, forest X-headers, and routing headers are
preserved in messages that are submitted by transport agents.

Organization X-headers and forest X-headers in Exchange

The Transport service on Mailbox servers or Edge Transport servers insert custom X-header fields into the
message header.
Organization X-headers start with X-MS -Exchange-Organization-. Forest X-headers start with X-MS -
Exchange-Forest-. The following table describes some of the organization X-headers and forest X-headers that
are used in messages in an Exchange organization.

X-HEADER DESCRIPTION

X-MS-Exchange-Forest-RulesExecuted Transport rules that acted on the message.

X-MS-Exchange-Organization-Antispam-Report A summary of the anti-spam filter results that have been

applied to the message by the Content Filter agent.

X-MS-Exchange-Organization-AuthAs Specifies the authentication source. This X-header is

always present when the security of a message has been
evaluated. The possible values are Anonymous ,
Internal , External , or Partner .

X-MS-Exchange-Organization-AuthDomain Populated during Domain Secure authentication. The

value is the FQDN of the remote authenticated domain.

X-MS-Exchange-Organization-AuthMechanism Specifies the authentication mechanism for the submission

of the message. The value is a 2-digit hexadecimal number.

X-MS-Exchange-Organization-AuthSource Specifies the FQDN of the server computer that evaluated

the authentication of the message on behalf of the
organization.

X-MS-Exchange-Organization-Journal-Report Identifies journal reports in transport. As soon as the

message leaves the transport service, the header becomes
X-MS-Journal-Report.

X-MS-Exchange-Organization-OriginalArrivalTime Identifies the time when the message first entered the
Exchange organization.

X-MS-Exchange-Organization-Original-Sender Identifies the original sender of a quarantined message

when it first entered the Exchange organization.
X-HEADER DESCRIPTION

X-MS-Exchange-Organization-OriginalSize Identifies the original size of a quarantined message when

it first entered the Exchange organization.

X-MS-Exchange-Organization-Original-Scl Identifies the original SCL of a quarantined message when

it first entered the Exchange organization.

X-MS-Exchange-Organization-PCL Identifies the phishing confidence level. The possible

phishing confidence level values are from 1 through 8. A
larger value indicates a suspicious message. For more
information, see Anti-spam stamps.

X-MS-Exchange-Organization-Quarantine Indicates the message has been quarantined in the spam

quarantine mailbox and a delivery status notification
(DSN) has been sent. Alternatively, it indicates that the
message was quarantined and released by the
administrator. This X-header field prevents the released
message from being submitted to the spam quarantine
mailbox again. For more information, see Release
quarantined messages from the spam quarantine mailbox.

X-MS-Exchange-Organization-SCL Identifies the SCL of the message. The possible SCL values
are from 0 through 9. A larger value indicates a suspicious
message. The special value -1 exempts the message from
processing by the Content Filter agent. For more
information, see Content filtering.

X-MS-Exchange-Organization-SenderIdResult Contains the results of the Sender ID agent. The Sender ID

agent uses the sender policy framework (SPF) to compare
the message's source IP address to the domain that's used
in the sender's email address. The Sender ID results are
used to calculate the SCL of a message. For more
information, see Sender ID.
 Domains
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Domains represent SMTP namespaces for which email directories and mailboxes are set up. By configuring the
domains that interact with your Microsoft Exchange Server 2013 organization, you can configure how email to and
from various domains is processed by Exchange.

Accepted domains
An accepted domain is any SMTP namespace for which your Exchange organization sends or receives email.
Accepted domains include those domains for which the Exchange organization is authoritative, as well as internal
relay domains and external relay domains. An Exchange organization is authoritative when it handles mail delivery
for recipients in the accepted domain. Accepted domains also include domains for which the Exchange
organization receives mail and then relays it to an email server that's outside the organization.
For more information about accepted domains, see Accepted domains.

Remote domains
In Exchange 2013, you create remote domain entries to define the settings for message transfer between your
Exchange organization and domains outside of your organization. When you create a remote domain entry, you
control the types of messages that are sent to that domain. You can also apply message format policies and
acceptable character sets for messages that are sent from users in your organization to the remote domain.
Settings for remote domains are global configuration settings for your Exchange organization. Remote domain
settings are applied to messages during categorization. When recipient resolution occurs, the recipient domain is
matched against the configured remote domains. If a remote domain configuration blocks a specific message type
from being sent to recipients in that domain, the message is deleted. If you specify a particular message format for
the remote domain, the message headers and content are modified. The settings apply to all messages that are
processed by the Exchange organization.
For more information about remote domains, see Remote domains.
 Accepted domains
6/11/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

An accepted domain is any SMTP namespace for which a Microsoft Exchange Server 2013 organization sends or
receives email. Accepted domains include those domains for which the Exchange organization is authoritative. An
Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain.
Accepted domains also include domains for which the Exchange organization receives mail and then relays it to
an email server that's outside the organization for delivery to the recipient.

Configuring accepted domains

Accepted domains are configured as global settings for the Exchange organization. You need to configure every
domain for which your Exchange organization relays or delivers messages as an accepted domain in your
organization.
There are three types of accepted domains: authoritative, internal relay, and external relay. These accepted domain
types are described in the following sections.

NOTE
If you have a subscribed Edge Transport server in your perimeter network, you configure accepted domains on a Mailbox
server in your Exchange organization. The accepted domains configuration is replicated to the Edge Transport server during
EdgeSync synchronization. For more information, see Edge Subscriptions

Authoritative domains
An organization may have more than one SMTP domain. The set of email domains for an organization are the
authoritative domains. In Exchange 2013, an accepted domain is considered authoritative when the Exchange
organization hosts mailboxes for recipients in this SMTP domain.
By default, when the first Exchange 2013 Mailbox server is installed, one accepted domain is configured as
authoritative for the Exchange organization. The default accepted domain is the fully qualified domain name
(FQDN ) for your forest root domain. Frequently, the internal domain name differs from the external domain
name. For example, your internal domain name may be contoso.local, although your external domain name is
contoso.com. The DNS mail exchanger (MX) record for your organization references contoso.com. Contoso.com
is the SMTP namespace that you assign to users when you create an email address policy. You need to create an
accepted domain to match your external domain name.
To learn more, see:
Configure an accepted domain within your Exchange organization as authoritative
Configure Exchange to accept mail for multiple authoritative domains

Relay domains
Typically, most Internet-facing messaging servers are configured to not allow for other domains to be relayed
through them. However, there are scenarios where you may want to let partners or subsidiaries relay email
through your Exchange servers. In Exchange 2013, you can configure accepted domains as relay domains. Your
organization receives the email messages and then relays the messages to another email server.
You can configure a relay domain as an internal relay domain or as an external relay domain. These two relay
domain types are described in the following sections.

Internal relay domain

When you configure an internal relay domain, some or all of the recipients in this domain don't have mailboxes in
this Exchange organization. Mail from the Internet is relayed for this domain through Transport servers in this
Exchange organization. This configuration is used in the scenarios that are described in this section.
An organization may have to share the same SMTP address space between two or more different messaging
systems. For example, you may have to share the SMTP address space between Exchange and a third-party
messaging system, or between Exchange environments that are configured in different Active Directory forests. In
these scenarios, users in each email system have the same domain suffix as part of their email addresses.
To support these scenarios, you need to create an accepted domain that's configured as an internal relay domain.
You also need to add a Send connector that's sourced on a Mailbox server and configured to send email to the
shared address space. If an accepted domain is configured as authoritative and a recipient isn't found in Active
Directory, a non-delivery report (NDR ) is returned to the sender. The accepted domain that's configured as an
internal relay domain first tries to deliver to a recipient in the Exchange organization. If the recipient isn't found,
the message is routed to the Send connector that has the closest address space match.
If an organization contains more than one forest and has configured global address list (GAL ) synchronization,
the SMTP domain for one forest may be configured as an internal relay domain in a second forest. Messages
from the Internet that are addressed to recipients in internal relay domains are relayed to the Mailbox servers in
the same organization. The receiving Mailbox servers then route the messages to the Mailbox servers in the
recipient forest. You configure the SMTP domain as an internal relay domain to make sure that email that's
addressed to that domain is accepted by the Exchange organization. The connector configuration of your
organization determines how messages are routed.
To learn more, see Configure an accepted domain for a business unit with mailboxes outside your Exchange
organization.

External relay domain

When you configure an external relay domain, messages are relayed to an email server that's outside your
Exchange organization and outside the organization's network perimeter.
For more information, see Configure an accepted domain for an independent business unit.

Accepted domains and email address policies

You need to configure an accepted domain before that SMTP address space can be used in an email address
policy. When you create an accepted domain, you can use a wildcard character (*) in the address space to indicate
that all subdomains of the SMTP address space are also accepted by the Exchange organization. For example, to
configure contoso.com and all its subdomains as accepted domains, enter *.contoso.com as the SMTP address
space. The accepted domain entries are automatically available for use in an email address policy.
If you delete an accepted domain that's used in an email address policy, the policy is no longer valid, and
recipients with email addresses in that SMTP domain will be unable to send or receive email.
 Configure an accepted domain within your Exchange
organization as authoritative
6/7/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

If a domain belonging to your organization hosts mailboxes for all the recipients within an SMTP namespace, that
domain is considered to be authoritative. By default, one accepted domain is configured as authoritative for the
Exchange organization. If your organization has more than one SMTP namespace, you can configure more than
one accepted domain as authoritative.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Accepted domains" entry in the Mail flow permissions topic.
If you have a subscribed Edge Transport server in your perimeter network, you configure accepted domains
on a Mailbox server in your Exchange organization. The accepted domains configuration is replicated to the
Edge Transport server during EdgeSync synchronization. For more information, see Edge Subscriptions.
You can't create an accepted domain that has the same name as an already configured remote domain. For
example, if you have fabrikam.com configured as a remote domain, you can't create an accepted domain for
fabrikam.com.
Before you configure an accepted domain, you must verify that a public Domain Name System (DNS ) MX
resource record for that SMTP namespace exists and that the MX resource record references a server name
and an IP address associated with your Exchange organization.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure an accepted domain as authoritative

If an accepted domain for your Exchange organization hosts all the mailboxes for recipients within that domain's
SMTP namespace, you may want to configure it as an authoritative domain.
1. In the EAC, navigate to Mail flow > Accepted domains, and click Add .
2. In the Name field, enter the display name for the accepted domain. Each accepted domain for your
organization must have a unique display name This may be different than the accepted domain. For
example, the domain contoso.com could have a display name of Contoso Local Accepted Domain.
3. In the Accepted domain field, enter the accepted domain. Specify an SMTP namespace for which your
organization accepts email messages. (for example, Contoso.com).
4. Select Authoritative domain. This option is for email relayed to servers within your Exchange
 organization for an accepted domain that hosts mailboxes for all the recipients within an SMTP namespace.
5. Click Save.

TIP
To configure an accepted domain that has already been created, select the domain from the accepted domains list and click
Edit . You can configure more than one domain as authoritative.

How do you know this worked?

Your new accepted domain will appear in the accepted domains list in the EAC. To verify that you have successfully
configured the accepted domain as authoritative, send mail to the domain and verify that it is received.
 Configure an accepted domain for an independent
business unit
6/7/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

In some situations you may want to configure an accepted domain for an independent business unit with email
servers outside your Exchange organization. In such scenarios, you can configure the accepted domain as an
external relay domain.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Accepted domains" entry in the Mail flow permissions topic.
If you have a subscribed Edge Transport server in your perimeter network, you configure accepted domains
on a Mailbox server in your Exchange organization. The accepted domains configuration is replicated to the
Edge Transport server during EdgeSync synchronization. For more information, see Edge Subscriptions.
You can't create an accepted domain that has the same name as an already configured remote domain. For
example, if you have fabrikam.com configured as a remote domain, you can't create an accepted domain for
fabrikam.com.
Before you configure an accepted domain, you must verify that a public Domain Name System (DNS ) MX
resource record for that SMTP namespace exists and that the MX resource record references a server name
and an IP address associated with your Exchange organization.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure the an accepted domain as an external relay

domain
You may want to configure an accepted domain for a business unit with email servers outside your Exchange
organization.
1. In the EAC, navigate to Mail flow > Accepted domains, select the domain you wish to configure, and click
Edit .
2. In the Name field, enter the display name for the accepted domain. Each accepted domain for your
organization must have a unique display name. This may be different than the accepted domain. For
example, the domain Contoso.com could have a display name of Contoso Local Accepted Domain.
3. Select External Relay Domain. This option is for email is relayed to a server outside your Exchange
organization.
4. Click Save.

How do you know this worked?

To verify that you have successfully configured an accepted domain as an external relay domain, send a message
from the accepted domain you've configured as an external relay domain, and verify that it is received.
2 minutes to read
 Configure Exchange to accept mail for multiple
authoritative domains
6/14/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, it's easy to add multiple authoritative domains to your organization. However,
after you add the authoritative domain, you need to decide how to use the authoritative domain in your
organization. For example:
If you want to add an email address in the new authoritative domain for recipients in your organization, do
you want to replace the existing primary (reply to) address for the recipients, or add the new email address
as a proxy (secondary) address?
Do you want the email address in the new authoritative domain to apply to all recipients, and all recipient
types? Or do you want the new email address to apply to specific types of recipients, or specific recipients
based on their user properties, for example, only users in the Finance department?
The following examples are scenarios in which your Exchange organization may have to receive and process email
for more than one authoritative SMTP domain:
You are changing your SMTP domain name, but have to continue to accept email for the old domain name
for a time, in case customers send email messages to the previous email addresses. You can set the new
email address as the primary (reply to) address. This means that the new address will be the default email
address displayed on all email messages sent by the recipient. You can set the old email address as a
secondary address. This will enable the recipient to continue to receive email sent to the old email address.
You want to provision different email addresses for business units within your organization. For example, if
the contoso.com Active Directory forest contains subdomains for the subsidiaries Tailspin Toys and Fourth
Coffee, you may want to assign the SMTP domain names contoso.com, tailspintoys.com, and
fourthcoffee.com to the recipients in those respective business units.
You provide email hosting services and have to accept email for more than one SMTP domain name.

What do you need to know before you begin?

Estimated time to complete this task: 30 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Accepted domains" entry in the Mail flow permissions topic and the "Email
address policies" entry in the Recipients Permissions topic.
If you have a subscribed Edge Transport server in your perimeter network, you configure accepted domains
on a Mailbox server in your Exchange organization. The accepted domains configuration is replicated to the
Edge Transport server during EdgeSync synchronization. For more information, see Edge Subscriptions.
When you create an accepted domain, you can use a wildcard character (*) in the address space to indicate
that all subdomains of the SMTP address space are also accepted by the Exchange organization. For
example, to configure contoso.com and all its subdomains as accepted domains, enter *.contoso.com as
the SMTP address space. However, if the subdomain names will be used in an email address policy, each
subdomain must have an explicit accepted domain entry.
An MX record in public DNS is required for each SMTP domain for which you accept email from the
 Internet. Each MX record should resolve to the Internet-facing server that receives email for your
organization.
You need to configure Send connectors and Receive connectors so your Exchange organization can send
email to and receive email from the Internet. The configuration of the Internet Send connectors and Receive
connectors is determined by your Exchange topology. For more information about configuring connectors,
see Connectors.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Step 1: Create an authoritative domain

Use the Exchange admin center to create an authoritative domain
1. In the EAC, navigate to Mail flow > Accepted domains, and click Add .
2. In the Name field, enter the display name for the accepted domain. Each accepted domain for your
organization must have a unique display name. This may be different than the accepted domain. For
example, the domain contoso.com could have a display name of Contoso Local Accepted Domain.
3. In the Accepted domain field, specify an SMTP namespace for which your organization accepts email
messages. For example, contoso.com.
4. Select Authoritative domain.
5. Click Save.
Use the Shell to create an authoritative domain
To create a new authoritative domain, use the following syntax.

New-AcceptedDomain -Name "<Unique Name>" -DomainName <SMTP domain> -DomainType Authoritative

For example, to create a new authoritative domain named "Fourth Coffee subsidiary" for the domain
fourthcoffee.com, run the following command:

New-AcceptedDomain -Name "Fourth Coffee subsidiary" -DomainName fourthcoffee.com -DomainType Authoritative

How do you know this step worked?

To verify that you have successfully created an authoritative domain, do one of the following:
In the EAC, navigate to Mail flow > Accepted domains. Verify the accepted domain you created is
displayed, and the Domain Type value is Authoritative.
In the Shell, run the command Get-AcceptedDomain. Verify the domain you created is displayed, and the
DomainType value is Authoritative .

Step 2: Configure an email address policy for the authoritative domain

To use the authoritative accepted domain you created, you need to configure an email address policy for the
authoritative domain that meets the objectives of your scenario. For example, you may need to create a new email
address policy, or modify an existing policy. You may elect to replace the primary email address for some or all of
your recipients, and you can elect to keep or remove the old primary email address. Two example scenarios are
presented in this section.
Change the existing primary email address
To change the primary (reply to) email address assigned to recipients and keep the old primary email address as a
proxy (secondary) email address, follow these steps:
Use the EAC to change the existing primary email address
1. In the EAC, navigate to Mail flow > Email address policies. Select the email address policy you want to
modify, and click Edit .
2. On the Email Address Policy page, click the Email address format tab. In the Email address format
section, click Add .
3. On the Email Address Format page that appears, make the following selections:
Select an accepted domain: Click the drop-down list, and select the new authoritative domain.
Select Make this format the reply email address.
When you are finished, click Save.
4. On the Email Address Policy page, click Save to save your changes to the policy.
5. You'll get a warning that the email address policy won't be applied until you update it. After it's created,
select it, and then, in the details pane, click Apply.
Use the Shell to change the existing primary email address
In the Shell, you use two separate commands: one command to modify the existing email address policy, and
another command to apply the updated email address policy to the recipients in your organization.
To change the existing primary email address, and keep the old primary email address as a proxy address, run the
following command:

Set-EmailAddressPolicy <EmailAddressPolicyIdentity> -EnabledEmailAddressTemplates SMTP:

<NewPrimaryEmailAddress>,smtp:<OldPrimaryEmailAddress>

For example, suppose the email address policy in your organization uses the email addresses format useralias
@contoso.com . This example changes the domain of primary (reply to) address in the email address policy named
"Default Policy" to @fourthcoffee.com , and keeps the old primary reply address in the @contoso.com domain as a
proxy (secondary) address.

Set-EmailAddressPolicy "Default Policy" -EnabledEmailAddressTemplates SMTP:@fourthcoffee.com,smtp:@contoso.com

NOTE
The SMTP qualifier in uppercase letters specifies the primary (reply to) address. The smtp qualifier in lowercase letters
specifies a proxy (secondary) address.

To apply the updated email address policy to recipients, use the following syntax.

Update-EmailAddressPolicy <EamilAddressPolicyIdentity>

For example, to apply the updated email address policy named "Default Policy", run the following command:
 Update-EmailAddressPolicy "Default Policy"

Replace the existing primary email address for a filtered set of recipients
You can't modify the default email address policy to apply to a filtered set of recipients. You need to create a new
email address policy, or modify an existing custom email address policy. The examples in this section create a new
email address policy. In these examples, the primary (reply to) address in the new accepted domain replaces the
old primary address for the specified recipients without keeping the old primary address as a proxy (secondary)
email address. Therefore, the affected recipients can no longer receive email at their old primary email address.
Also, email address policies that apply to specific users should have a higher priority (indicated by a lower integer
value) than other email address policies, including the default policy, so the specific policy is applied first. Because
two policies can't have the same priority value, you may first need lower the priority of your organization's default
email address policy.
Use the EAC to replace the existing primary email address for a filtered set of recipients
To create additional email addresses that will be used as the primary email address for a filtered set of recipients,
follow these steps.
1. In the EAC, navigate to Mail flow > Email address policies, and then click Add .
2. On the Email Address Policy page, complete the following fields:
a. Policy name: Enter a unique, descriptive name.
b. Email address format: Click Add . On the Email Address Format page that appears, make the
following selections:
Select an accepted domain: Click the drop-down list, and select the new authoritative
domain.
Email address format: Select the appropriate email address format for your organization.
Select Make this format the reply email address.
When you are finished, click Save.
3. Run this policy in this sequence with other policies: Typically, policies that apply to specific users
should have a higher priority (indicated by a lower integer value) than other email address policies,
including the default policy.
4. Specify the types of recipients this email address will apply to: Select the recipient types to which you
want the email address policy applied.
5. Create rules to further define the recipients that this email address policy applies to: Click Add a
rule to restrict the recipients that this policy will apply to. This creates a Boolean And statement. Repeat this
step as many times as necessary.

WARNING
If you apply too many rules, it's possible to restrict the email address policy to the point that it doesn't contain any
users.

6. Click Preview recipients the policy applies to to view the recipients that policy will apply to.
7. Click Save to save your changes and create the policy.
8. You'll get a warning that the email address policy won't be applied until you update it. After it's created,
 select it, and then, in the details pane, click Apply.
Use the Shell to replace the existing primary email address for a filtered set of recipients
To replace the primary email address for a filtered set of recipients, use the following command:

New-EmailAddressPolicy -Name <Policy Name> -Priority <Integer> -IncludedRecipients <RecipientTypes>

<Conditional Recipient Properties> -EnabledEmailAddressTemplates SMTP:@<NewPrimaryEmailAddress>

This example creates an email address policy named "Fourth Coffee Recipients", assigns that policy to mailbox
users in the Fourth Coffee department, and sets the highest priority for that email address policy so the policy is
applied first. Note that the old primary email address isn't preserved for these recipients, so they can't receive
email at their old primary email address.

New-EmailAddressPolicy -Name "Fourth Coffee Recipients" -Priority 1 -IncludedRecipients MailboxUsers -

ConditionalDepartment "Fourth Coffee" -EnabledEmailAddressTemplates SMTP:@fourthcoffee.com

To apply the new email address policy to the affected recipients, run the following command:.

Update-EmailAddressPolicy "Fourth Coffee Recipients"

How do you know this step worked?

To verify that you have successfully configured an email address policy for the authoritative domain, do one of the
following:
In the EAC, navigate to Mail flow > Email address policies. Verify the policies are applied in the correct
order. Also, select any new or updated policies, and in the details pane, verify the email address format,
included recipients, and if the policy has been applied,
In the Shell, run the commands Get-EmailAddressPolicy and
Get-EmailAddressPolicy "<Policy Name>"| Format-List to verify the details of the policies.

How do you know this task worked?

To verify that you have configured Exchange to accept mail for multiple authoritative domains, do the following:
1. Send test messages to an affected recipient from a mailbox outside your Exchange organization. Verify the
email addresses that successfully accept mail.
2. Send test messages from an affected recipient mailbox to an external recipient, and verify the From address
of the message.
 Remote domains
6/14/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can create remote domain entries to define the settings for message transfer between the Microsoft Exchange
Server 2013 organization and domains outside your Exchange organization. When you create a remote domain
entry, you control the types of messages that are sent to that domain. You can also apply message format policies
and acceptable character sets for messages that are sent from users in your organization to the remote domain.
The settings for remote domains are global configuration settings for the Exchange organization.
The remote domain settings are applied to messages during categorization in the Transport service on Mailbox
servers. When recipient resolution occurs, the recipient domain is matched against the configured remote
domains. If a remote domain configuration blocks a specific message type from being sent to recipients in that
domain, the message is deleted. If you specify a particular message format for the remote domain, the message
headers and content are modified. The settings apply to all messages that are processed by the Exchange
organization.

NOTE
If you configure message settings per user, the per-user settings override the organizational configuration.

By default, there's a single remote domain entry. The domain address space is configured as an asterisk (*). This
represents all remote domains. If you don't create additional remote domain entries, all messages that are sent to
all recipients in all remote domains have the same settings applied to them.
When you configure remote domains, you can prevent certain types of messages from being sent to that domain.
These message types include out-of-office messages, auto-reply messages, non-delivery reports (NDRs), and
meeting forward notifications. If you have a multiple forest environment, you may want to allow the sending of
those types of messages to those domains. However, if you have identified a domain from which spam originates,
you may want to block sending of those types of messages to those remote domains.

Message format
You can specify the message format and the character set to use for email messages that are sent to remote
domains. These settings can be useful to make sure that email sent by senders in your domain to the remote
domain is compatible with the receiving email system. For example, if you know that the remote domain's
messaging system is Exchange, you can specify to always use Exchange rich text format (RTF ). For more
information, see Content conversion.

Automatic replies settings

In Exchange 2013, users can specify different automatic replies for internal and external recipients. Furthermore,
the types of automatic replies available in your organization also depend on the Microsoft Outlook version in use.
In Exchange 2013, there are two types of automatic replies:
External: Supported by Exchange 2013 and Exchange 2010. Can only be set by Outlook 2010 or Office
Outlook 2007, or using Outlook Web App.
Internal: Supported by Exchange 2013 and Exchange 2010. Can only be set by Outlook 2010 or Outlook
 2007, or using Outlook Web App.
The following table describes various client and server combinations and the types of automatic replies that can
be used in each scenario.
Client and server support for automatic replies

CLIENT VERSION EXCHANGE VERSION AUTOMATIC REPLIES SUPPORTED

Outlook 2010 or Outlook 2007 Exchange 2013 Exchange Internal, External

2010 Exchange 2007

Outlook Web App Exchange 2013 Exchange Internal, External

2010 Exchange 2007

Controlling NDR information

As mentioned at the beginning of this topic, you can prevent NDRs from being sent to a remote domain. By
blocking NDRs from being sent to a remote domain, you can prevent the information contained within the NDR
message from leaving your organization, thereby limiting the knowledge that a malicious user can obtain about
your organization. However, this also prevents legitimate senders from receiving NDRs, resulting in confusion
and lost productivity.
Exchange 2013 provides you with granular control over the contents of an NDR destined for a remote domain.
With Exchange 2013, you can allow NDRs to a remote domain, while stripping any diagnostic information. This
way, you can still prevent information about your Exchange deployment from leaving your organization while at
the same time providing NDR notifications to external senders.
This feature is controlled with the NDRDiagnosticInfoEnabled parameter on the Set-RemoteDomain cmdlet.
Because this setting is configurable for each remote domain, you can have different settings based on your needs.
For example, you can choose to remove the NDR diagnostic information for the default remote domain, but allow
full NDR diagnostic information for the remote domains that represent your partners.
For more information about this new setting, see Set-RemoteDomain.
 Manage remote domains
6/10/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Remote domains are SMTP domains that are external to your Microsoft Exchange organization. You can create
remote domain entries to define the settings for message transferred between your Exchange organization and
specific external domains. The settings in the remote domain entry for a specific external domain override the
settings in the default remote domain that normally apply to all external recipients. The remote domain settings are
global for the Exchange organization.
If you remove a remote domain entry, the settings for message transfer no longer apply to messages sent to the
remote domain. Removing a remote domain entry doesn't disable mail flow to the remote domain. After a remote
domain entry is removed, the configuration settings of the default remote domain apply to new messages sent to
that domain. You can't remove the default remote domain.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Remote domains" entry in the Mail flow permissions topic.
You can only use the Shell to perform this procedure.
You can't create a remote domain for an address space that's configured as an accepted domain in your
organization. For example, if your organization accepts mail for fabrikam.com, you can't create a remote
domain for fabrikam.com.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

What Do You Want to Do?

Use the Shell to create a remote domain
To create a new remote domain entry, use the following syntax.

New-RemoteDomain -Name <Descriptive Name> -DomainName <SMTP address space>

This example creates a remote domain entry for messages sent to the contoso.com domain.

New-RemoteDomain -Name Contoso -DomainName contoso.com

This example creates a remote domain entry for messages sent to the fabrikam.com domain and all subdomains.
 New-RemoteDomain -Name Fabrikam -DomainName *.fabrikam.com

How do you know this worked?

To verify that you have successfully created a remote domain, do the following:
1. Run the command Get-RemoteDomain and verify that the remote domain is listed.
2. Run the command Get-RemoteDomain <Remote Domain Name> | Format-List to verify the settings on the new
remote domain. Send a test message to a recipient in the address space that's specified in the new remote
domain entry, and verify that the message settings match those specified by the new remote domain entry.

Use the Shell to configure a remote domain

You configure the settings in the remote domain entry using the Set-RemoteDomain cmdlet. There are many
different settings that relate to automatic replies, message format and encoding, and other message settings. For
more information, see Set-RemoteDomain.
To configure remote domains for specific scenarios, see the following topics:
Configure remote domain out of office replies
Configure remote domain automatic replies
Configure remote domain message reporting

Use the Shell to remove a remote domain

To remove a remote domain entry, use the following syntax.

Remove-RemoteDomain <RemoteDomainName>

This example removes the remote domain entry named Contoso

Remove-RemoteDomain Contoso

How do you know this worked?

To verify that you have successfully removed the remote domain, do the following:
1. Run the command Get-RemoteDomain and verify that the remote domain is isn't listed.
2. Run the command Get-RemoteDomain Default | Format-List to verify the settings on the default remote
domain. Send a test message to a recipient in the address space that was specified in the removed remote
domain, and verify that the message settings match those specified by the default remote domain.
 Configure remote domain out of office replies
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use the Exchange Management Shell to configure the way emails are sent and received through remote
domains. The following demonstrates how to use the Exchange Management Shell to configure the way Exchange
handles out of office replies.

What do you need to know before you begin?

Estimated time to complete: 10 minutes
You can only use the Shell to perform this procedure.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Remote domains" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure out-of-office replies

You can use the Set-RemoteDomain cmdlet to configure the properties of a remote domain.
This example disables out-of-office messages for the remote domain named Contoso.

Set-RemoteDomain Contoso -AllowedOOFType None

This example allows only external out-of-office messages.

Set-RemoteDomain Contoso -AllowedOOFType External

 Configure remote domain automatic replies
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use the Exchange Management Shell to configure the way emails are sent and received through remote
domains. The following demonstrates how to use the Exchange Management Shell to configure the way Exchange
handles automatic replies.

What do you need to know before you begin?

Estimated time to complete: 10 minutes
You can only use the Shell to perform this procedure.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Remote domain" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure automatic replies

You can use the Set-RemoteDomain cmdlet to configure the properties of a remote domain.
This example allows automatic replies to the remote domain named Contoso. This setting is disabled by default.

Set-RemoteDomain Contoso -AutoReplyEnabled $true

This example allows automatic forwards to the remote domain. This setting is disabled by default.

Set-RemoteDomain Contoso -AutoForwardEnabled $true

 Configure remote domain message reporting
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use the Exchange Management Shell to configure the way emails are sent and received through remote
domains. The following demonstrates how to use the Exchange Management Shell configure the way Exchange
handles delivery and non-delivery reports.

What do you need to know before you begin?

Estimated time to complete: 10 minutes
You can only use the Shell to perform this procedure.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Remote domains" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure message reporting

You can use the Set-RemoteDomain cmdlet to configure the properties of a remote domain.
This example disables delivery reports to the remote domain named Contoso. This setting is enabled by default.

Set-RemoteDomain Contoso -DeliveryReportEnabled $false

This example disables non-delivery reports to the remote domain. This setting is enabled by default.

Set-RemoteDomain Contoso -NDREnabled $false

 Supported character sets for remote domains in
Exchange 2013
5/30/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following character sets can be specified for messages sent to remote domains.
In the Exchange admin center (EAC ), on the Remote domain settings page, select the name from the
MIME character set and Non-MIME character set drop-down lists.
In the Shell, use the value in the Name column in the following table for the CharacterSet parameter or
NonMimeCharacterSet parameter in the Set-RemoteDomain cmdlet.
Supported character sets for remote domain configuration

NAME DESCRIPTION

big5 Chinese Traditional (Big5)

DIN_66003 German (IA5)

euc-jp Japanese (EUC)

euc-kr Korean (EUC)

GB18030 Chinese Simplified (GB18030)

gb2312 Chinese Simplified (GB2312)

hz-gb-2312 Chinese Simplified (HZ)

iso-2022-jp Japanese (JIS)

iso-2022-kr Korean (ISO)

iso-8859-1 Western European (ISO)

iso-8859-2 Central European (ISO)

iso-8859-3 Latin 3 (ISO)

iso-8859-4 Baltic (ISO)

iso-8859-5 Cyrillic (ISO)

iso-8859-6 Arabic (ISO)

iso-8859-7 Greek (ISO)

NAME DESCRIPTION

iso-8859-8 Hebrew (ISO)

iso-8859-9 Turkish (ISO)

iso-8859-13 Estonian (ISO)

iso-8859-15 Latin 9 (ISO)

koi8-r Cyrillic (KOI8-R)

koi8-u Cyrillic (KOI8-U)

ks_c_5601-1987 Korean (Windows)

NS_4551-1 Norwegian (IA5)

SEN_850200_B Swedish (IA5)

shift_jis Japanese (Shift-JIS)

utf-8 Unicode (UTF-8)

windows-1250 Central European (Windows)

windows-1251 Cyrillic (Windows)

windows-1252 Western European (Windows)

windows-1253 Greek (Windows)

windows-1254 Turkish (Windows)

windows-1255 Hebrew (Windows)

windows-1256 Arabic (Windows)

windows-1257 Baltic (Windows)

windows-1258 Vietnamese (Windows)

windows-874 Thai (Windows)

 Transport agents
6/14/2019 • 8 minutes to read • Edit Online

Applies to: Exchange Server 2013

Transport agents let you install custom software that is created by Microsoft, by third-party vendors, or by your
organization, on an Exchange server. This software can then process email messages that pass through the
transport pipeline. In Microsoft Exchange Server 2013, the transport pipeline is made of the following processes:
The Front End Transport service on Client Access servers
The Transport service on Mailbox servers
The Mailbox Transport service on Mailbox servers
The Transport service on Edge Transport servers
For more information about the transport pipeline, see Mail flow
Like the previous version of Exchange, Exchange 2013 transport provides extensibility through the Microsoft
Exchange Server 2013 Transport Agents SDK. The Exchange 2013 version of the SDK is based on the
Microsoft .NET Framework version 4.0 and allows third parties to implement the following predefined classes:
SmtpReceiveAgent
RoutingAgent
DeliveryAgent
When complied against libraries in the SDK, the resulting assemblies are registered with Exchange 2013, which
loads the agents and invokes their event handlers during specific stages of the SMTP sessions or message
processing. These stages, or events, are part of the agent definitions. The agent registration information is stored
in an XML configuration file.
The following list explains the requirements for using transport agents in Exchange 2013.
The Transport service on Mailbox servers and Edge Transport servers fully supports all the predefined
classes in the SDK, and therefore any third party transport agents written for the Hub Transport or Edge
Transport server roles in Microsoft Exchange Server 2010 should work in the Transport service in
Exchange 2013.
The Front End Transport service only supports the SmtpReceiveAgent class in the SDK, and third party
agents can't operate on the OnEndOfData SMTP event.
The Mailbox Transport service doesn't support the SDK at all, so you can't use any third party agents in
the Mailbox Transport service.
Support for legacy transport agents based on versions of the .NET Framework prior to version 4.0 isn't enabled
by default, but you can enable it. For instructions, see Enable support for legacy transport agents .

Updates to transport agent management

Due to the updates to the Exchange 2013 transport pipeline, the transport agent cmdlets need to distinguish
between the Transport service and the Front End Transport service, especially if the Client Access server and the
Mailbox server are installed on the same computer. For more information, see Manage transport agents.
Transport Agent management cmdlets manipulate a configuration file located at
%ExchangeInstallPath%TransportRoles\Shared . For the Transport service on Mailbox servers and Edge Transport
servers, the file is agents.config . For the Front End Transport service on Client Access servers, the file is
fetagents.config . Both files use the same format as in Exchange 2010. For more information about managing
transport agents, see Manage transport agents.

Transport agents and SMTP events

Transport agents use SMTP events. These events are triggered as messages move through the transport
pipeline. SMTP events give transport agents access to messages at specific points during the SMTP
conversation and during routing of messages through the organization.
Note that there are new SMTP Receive events in Exchange 2013. SMTP Receive exists in the Front End
Transport service on Client Access servers, the Transport service on Mailbox servers and Edge Transport servers
and the Mailbox Transport Delivery service on Mailbox servers. The categorizer exists only in the Transport
service on Mailbox servers and Edge Transport servers. For more information about transport services and the
categorizer, see Mail routing.
The following tables list the SMTP events that provide access to messages in the transport pipeline.
SMTP Receive events
SEQUENCE SMTP EVENT DESCRIPTION

1 OnConnectEvent This event is triggered by the initial

connection from a remote SMTP
host.

2 OnHeloCommand This event is triggered when the

HELO command is issued by the
remote SMTP host.

3 OnEhloCommand This event is triggered when the

EHLO command is issued by the
remote SMTP host.

4 OnStartTlsCommand This event is triggered when the

STARTTLS command is issued by
the remote SMTP host.

5 OnAuthCommand This event is triggered when the

AUTH command is issued by the
remote SMTP host.

6 OnProcessAuthentication This event is triggered when

authentication with the remote
SMTP host is being processed.

7 OnEndOfAuthentication This event is triggered when the

remote SMTP host has completed
authentication.
SEQUENCE SMTP EVENT DESCRIPTION

8 OnXSessionParamsCommand This event is triggered when the

XSESSIONPARAMS command is
issued by the remote SMTP host.

9 OnMailCommand This event is triggered when the

MAIL FROM command is issued by
the remote SMTP host.

10 OnRcptToCommand This event is triggered when the

RCPT TO command is issued by
the remote SMTP host.

11 OnDataCommand This event is triggered when the

DATA (text) or BDAT (binary
data) command is issued by the
remote SMTP host.

12 OnEndOfHeaders This event is triggered when the

remote SMTP host has completed
submitting the email message
headers. This is indicated by a
blank line ( <CRLF> ) that separates
the message headers and the
message body.

13 OnProxyInboundMessage This event is triggered when an

inbound SMTP session is relayed
or proxied by the Front End
Transport service on a Client
Access server to the Transport
service on a Mailbox server.

14 OnEndOfData This event is triggered when the

remote SMTP host issues an end
of data command. For text
sessions started by the DATA
command, the end of data
indicator is <CRLF>.<CRLF> . For
binary sessions started by the
BDAT command, the end of data
indicator is BDAT LAST .

** OnHelpCommand This event is triggered if the HELP

command is issued by the remote
SMTP host.

** OnNoopCommand This event is triggered if the NOOP

command is issued by the remote
SMTP host.
 SEQUENCE SMTP EVENT DESCRIPTION

** OnReject This event is triggered if the

receiving SMTP host issues a
temporary or permanent delivery
status notification (DSN) code to
the sending SMTP host.

** OnRsetCommand This event is triggered if the RSET

command is issued by the sending
SMTP host.

15 OnDisconnectEvent This event is triggered by the

disconnection of the SMTP
conversation by either the
receiving or sending SMTP host.
Typically, this happens when the
QUIT command is issued by the
remote SMTP host.

** These events can occur at any time after OnConnectEvent but before OnDisconnectEvent.
Categorizer events
SEQUENCE CATEGORIZER EVENT DESCRIPTION

1 OnSubmittedMessage This event is triggered when a

message arrives in the Submission
queue in the Transport service on
the receiving Mailbox server or
Edge Transport server.

2 OnResolvedMessage This event is triggered after all the

recipients have been resolved, but
before the next hop has been
determined for each recipient. The
OnResolvedMessage routing
event enables subsequent events
to override the default routing
behavior by using the per-recipient
SetRoutingOverride method.

3 OnRoutedMessage This event is triggered after

messages have been categorized,
distribution lists have been
expanded, and recipients have
been resolved.

4 OnCategorizedMessage This event is triggered when the

categorizer completes processing
the message.

Priority of transport agents

There are two factors that determine the order that transport agents act on messages in the transport pipeline:
1. The SMTP event where the transport agent is registered, and when that SMTP event encounters
messages.
2. The priority value that's assigned to the transport agent if there are multiple agents registered to the same
SMTP event. The highest priority is 1. A higher integer value indicates a lower agent priority.
For example, suppose you configured the following transport agents:
Transport Agent A with a priority of 1 and Transport Agent C with a priority of 2 are registered to the
OnEndOfHeaders SMTP event.
Transport Agent B with a priority of 4 is registered to the OnMailCommand SMTP event.
Transport Agent B is applied to messages first because the OnMailCommand event encounters messages
before the OnEndOfHeaders event. When messages reach the OnEndOfHeaders event, Transport Agent A is
applied before Transport Agent C because Transport Agent A has a higher priority (lower integer value) than
Transport Agent C.

Built-in transport agents

Exchange 2013 includes many built-in transport agents that provide features such as anti-spam, transport rules
and journaling. Most of the built-in transport agents on Exchange 2013 Mailbox servers and Client Access
servers are invisible and unmanageable by the transport agent management cmdlets. Virtually all of the built-in
transport agents that are visible and manageable are in the Transport service on Mailbox servers and on Edge
Transport servers.
The more interesting built-in transport agents on Mailbox servers are described in the following table. Note that
this table doesn't include many of the invisible and unmanageable transport agents.
Interesting built-in transport agents on Mailbox servers
SMTP OR CATEGORIZER
AGENT NAME MANAGEABLE? PRIORITY EVENTS

Transport Rule Agent Yes 1 OnResolvedMessage

Malware Agent Yes 2 OnSubmittedMessage

Text Messaging Routing Yes 3 OnSubmittedMessage

Agent

Text Messaging Delivery Yes 4 n/a

Agent

Journal Agent No Not configurable OnRoutedMessage

Journal Report No Not configurable OnCategorizedMessa

Decryption Agent ge

RMS Decryption Agent No Not configurable OnSubmittedMessage

 SMTP OR CATEGORIZER
AGENT NAME MANAGEABLE? PRIORITY EVENTS

RMS Encryption Agent No Not configurable OnSubmittedMessage

, OnRoutedMessage

RMS Protocol No Not configurable OnEndOfData

Decryption Agent

On Edge Transport servers, most of the built-in transport agents are visible and manageable by the transport
agent management cmdlets or by other feature-specific cmdlets.
The more interesting built-in transport agents on Edge Transport servers are described in the following table.
Note that this table doesn't include invisible or unmanageable transport agents.
Interesting built-in transport agents on Edge Transport servers
SMTP OR CATEGORIZER
AGENT NAME MANAGEABLE? PRIORITY EVENTS

Connection Filtering Yes 1 OnConnectEvent,

Agent OnMailCommand,
OnRcptComand,
OnEndOfHeaders

Address Rewriting Yes 2 OnRcptCommand,

Inbound Agent OnEndOfHeaders

Edge Rule Agent Yes 3 OnEndOfData

Content Filter Agent* Yes 4 OnEndOfData

Sender ID Agent* Yes 5 OnEndOfHeaders

Sender Filter Agent* Yes 6 OnMailCommand,

OnEndOfHeaders

Recipient Filter Agent Yes 7 OnRcptCommand

Protocol Analysis Yes 8 OnConnectEvent,

Agent* OnEndOfHeaders,
OnEndOfData,
OnReject,
OnRsetCommand,
OnDisconnectEvent

Attachment Filtering Yes 9 OnEndOfData

Agent
 SMTP OR CATEGORIZER
AGENT NAME MANAGEABLE? PRIORITY EVENTS

Address Rewriting Yes 10 OnSubmittedMessage

Outbound Agent , OnRoutedMessage

* You can also install and configure these anti-spam agents on Mailbox servers. For more information, see
Enable anti-spam functionality on Mailbox servers.

Troubleshoot transport agents

To help you troubleshoot issues with transport agents, you can use the following features:
Get-TransportPipeline: This cmdlet shows the SMTP events and the corresponding transport agents
that encounter messages on the Exchange server. For more information, see View transport agents in the
transport pipeline.
Pipeline Tracing: Pipeline tracing creates an exact snapshot of a message before and after it encounters
each transport agent. This allows you to find a transport agent that's causing unexpected results. For
more information, see Pipeline tracing.
 Enable support for legacy transport agents
6/6/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, transport agents that were created using the Microsoft .NET Framework
version 4.0 are supported by default. Exchange 2013 supports transport agents that were created using previous
versions of the .NET Framework, but support for these legacy transport agents isn't enabled by default. To enable
support for legacy transport agents, you need to modify the appropriate XML application configuration file. The
files you need to modify depend on where the transport agent is installed:

SERVER APPLICATION CONFIGURATION FILES MICROSOFT WINDOWS SERVICE

Client Access server %ExchangeInstallPath%Bin\MSExch Microsoft Exchange Front End

angeFrontendTransport.exe.config Transport
(MSExchangeFrontendTransport)

Mailbox server %ExchangeInstallPath%Bin\E Microsoft Exchange Transport

dgeTransport.exe.config (MSExchangeTransport)
%ExchangeInstallPath%Bin\
MSExchangeTransport.exe.co
nfig

Support for legacy transport agents is controlled by keys in the application configuration files. By default, none of
the required keys are present in the application configuration files. You must add the keys manually. The following
table explains each key in more detail.

KEY DESCRIPTION

useLegacyV2RuntimeActivationPolicy This key enables or disables support for legacy transport

agents. Valid values for this key are true or false . If
this key isn't specified, the default value is false .

supportedRuntime version This key specifies the version of the Microsoft .NET
Framework that's required by the agent. Valid values for
this key are:
v4.0 or v4.0.30319

v3.5 or v3.5.21022

v3.0 or v3.0.4506

v2.0 or v2.0.50727

You specify multiple values using multiple separate

instances of the supportedRuntime version key.
When you enable legacy transport agent support using
the useLegacyV2RuntimeActivationPolicy key, you should
always specify the value v4.0 in addition to the values
required by the legacy transport agent.
What do you need to know before you begin?
Estimated time to complete: 15 minutes
Exchange permissions don't apply to the procedures in this topic. These procedures are performed in the
operating system of the Exchange Server.
Changes you save to an application configuration file are applied after you restart the corresponding
service.
When you restart any of the services that are associated with the application configuration files, mail flow
on the server is temporarily interrupted.
Any customized per-server settings you make in Exchange XML application configuration files, for example,
web.config files on Client Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be
overwritten when you install an Exchange Cumulative Update (CU ). Make sure that you save this
information so you can easily re-configure your server after the install. You must re-configure these settings
after you install an Exchange CU.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Command Prompt to configure support for legacy transport

agents
Use the following procedure to enable support for legacy transport agents:
1. In a Command prompt window, on the Exchange 2013 server where you want to configure the legacy
transport agent support, open the appropriate application configuration file in Notepad by running the
following command:

Notepad %ExchangeInstallPath%Bin\<AppConfigFile>

For example, to open the EdgeTransport.exe.config file on a Mailbox server, run the following command:

Notepad %ExchangeInstallPath%Bin\EdgeTransport.exe.config

2. Locate the </configuration> key at the end of the file, and paste the following keys before the
</configuration> key:

<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
<supportedRuntime version="v3.5" />
<supportedRuntime version="v3.0" />
<supportedRuntime version="v2.0" />
</startup>

3. When you are finished, save and close the application configuration file.
4. Repeat Steps 1 through 3 to modify the other application configuration files.
5. Restart the associated Windows service by running the following command:

net stop <service> && net start <service>

For example, if you modified the EdgeTransport.exe.config file, you need to restart the Microsoft Exchange
Transport service by running the following command:

net stop MSExchangeTransport && net start MSExchangeTransport

6. Repeat Step 5 to restart services associated with the other modified application configuration files.

How do you know this worked?

You'll know this procedure works if the legacy transport agent installs successfully. If you try to install a legacy
transport agent without performing the procedures in this topic, you'll receive an error that's similar to the
following:
Mixed mode assembly is built against version '<version>' of the runtime and cannot be loaded in the 4.0 runtime
without additional configuration information.
 Manage transport agents
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Transport agents use SMTP events to operate on messages as the messages move through the transport pipeline.
Most of the built-in transport agents that are included with Microsoft Exchange Server 2013 are invisible and
unmanageable. However, you can install and configure third-party transport agents on Exchange servers in your
organization. For more information about transport agents, see Transport agents.

What do you need to know before you begin?

Estimated time to complete each procedure: 10 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport agents" entry in the Mail flow permissions topic.
You can only use the Shell to perform this procedure.
Support for legacy transport agents isn't enabled by default, but you can enable it. For instructions, see
Enable support for legacy transport agents .
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

About transport agent procedures in the Front End Transport service

on Client Access servers
You can't use the Exchange Management Shell to manage transport agent in the Front End Transport service on a
Client Access server. Instead, you need to open Windows PowerShell on the Client Access server, and then import
the Exchange cmdlets into the Windows PowerShell session.

WARNING
Running Exchange cmdlets in Windows PowerShell for tasks other than managing transport agents in the Front End
Transport service is not supported. There are serious consequences that can result if you bypass the Exchange Management
Shell and role-based access control (RBAC) by running Exchange cmdlets in Windows PowerShell. You should always run
Exchange cmdlets in the Exchange Management Shell. For more information, see Release notes for Exchange 2013.

To perform any of the Transport Agent procedures described in this topic in the Front End Transport service, you
need to perform the following additional steps:
1. On the Client Access server, open Windows PowerShell and run the following command:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
2. Run the command as described, but add the following value to the command: -TransportService FrontEnd .
For example, to view the transport agents in the Front End Transport service on a Client Access server, run
the following command:

Get-TransportAgent -TransportService FrontEnd

Use the Shell to install a transport agent

When you install a transport agent, Exchange only registers the DLLs associated with the transport agent. You
need to make sure all files, registry keys, and other objects that the transport agent depends on are installed
correctly and configured. After Exchange loads the DLLs, it continues to reference the DLLs after the command
has completed.
Transport agents have full access to all e-mail messages that they encounter. Exchange puts no restrictions on a
transport agent's behavior. Transport agents that are unstable or contain security flaws may affect the stability and
security of Exchange. Therefore, you should only install transport agents that you fully trust and that have been
fully tested in a test environment.
Transport agents are installed in a disabled state to make sure mail flow isn't affected by transport agents that
haven't been configured. Therefore, after a transport agent has been configured correctly, you need to enable the
transport agent.
Use the following syntax to install a transport agent.

Install-TransportAgent -Name <TransportAgentIdentity> -TransportAgentFactory <"TransportAgentFactory"> -

AssemblyPath <"FilePath">

This example installs a fictitious transport agent named Contoso Transport Agent in the Transport service on a
Mailbox server.

Install-TransportAgent -Name "Contoso Transport Agent" -TransportAgentFactory

"vendor.exchange.ContosoTransportAgentfactory" -AssemblyPath "C:\Program
Files\Vendor\TransportAgent\ContosoTransportAgentFactory.dll"

How do you know this worked?

To verify that you have successfully installed the transport agent, run the command Get-TransportAgent and verify
the transport agent is listed.

Use the Shell to enable a transport agent

Use the following syntax to enable a transport agent.

Enable-TransportAgent <TransportAgentIdentity>

This example enables the transport agent named Contoso Transport Agent in the Transport service on a Mailbox
server.

Enable-TransportAgent "Contoso Transport Agent"

How do you know this worked?
To verify that you have successfully enabled a transport agent, run the command
Get-TransportAgent | Format-List Name,Enabled and verify the transport agent is enabled.

Use the Shell to disable a transport agent

Use the following syntax to disable a transport agent:

Disable-TransportAgent <TransportAgentIdentity>

This example disables the transport agent named Fabirkam Transport Agent in the Transport service on a Mailbox
server.

Disable-TransportAgent "Fabrikam Transport Agent"

How do you know this worked?

To verify that you have successfully disabled a transport agent, run the command
Get-TransportAgent | Format-List Name,Enabled and verify the transport agent is disabled.

Use the Shell to view transport agents

To view a summary list of transport agents, run the following command:

Get-TransportAgent

To view the detailed configuration of a specific transport agent, run the following command:

Get-TransportAgent <TransportAgentIdentity> | Format-List

This example provides detailed configuration of the transport agent named Transport Rule Agent.

Get-TransportAgent "Transport Rule Agent" | Format-List

Use the Shell to configure the priority of a transport agent

Transport agents with a priority closest to 0 process email messages first. However, the SMTP event in the
transport pipeline where the transport agent is registered may cause a lower priority agent to act on the message
before a higher priority agent.
To modify the priority of an existing transport agent, run the following command:

Set-TransportAgent <TransportAgentIdentity> -Priority <Integer>

This example sets the priority agent value of 3 for the existing transport agent named Contoso Transport Agent in
the Transport service on a Mailbox server.

Set-TransportAgent "Contoso Transport Agent" -Priority 3

How do you know this worked?
To verify that you have successfully configured the priority of a transport agent, run the command
Get-TransportAgent | Format-List Name,Priority and verify the priority value of the transport agent.

Use the Shell to uninstall a transport agent

When the transport agent is uninstalled, Exchange unregisters the DLL files used with the agent. Exchange doesn't
remove any files, registry keys, or other objects added by the installation of the transport agent.
To uninstall a transport agent, run the following command:

Uninstall-TransportAgent <TransportAgentIdentity>

This example uninstalls the transport agent named Fabrikam Transport Agent from the Transport service on a
Mailbox server.

Uninstall-TransportAgent "Fabrikam Transport Agent"

How do you know this worked?

To verify that you have successfully uninstalled the transport agent, run the command Get-TransportAgent and
verify the transport agent isn't listed.
 View transport agents in the transport pipeline
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can use the Exchange Management Shell to view a list of transport agents in the transport pipeline on
Microsoft Exchange Server 2013 Mailbox servers and Client Access servers. Specifically, the Get-
TransportPipeline cmdlet shows information about the following types of transport agents in the transport
pipeline:
Agents based on the SmtpReceiveAgent, RoutingAgent, DeliveryAgent, and StorageAgent classes in
the Transport service on Mailbox servers.
Agents based on the SmtpReceiveAgentClass in the Mailbox Transport Delivery service on Mailbox
servers.
Agents based on the SmtpReceiveAgentClass in the Front End Transport service on Client Access servers.
You can view a list of all the enabled transport agents that have encountered messages in the transport pipeline
and the SMTP events they are registered on. For more information about transport agents, see Transport agents.

What do you need to know before you begin?

Estimated time to complete: 5 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport agents" entry in the Mail flow permissions topic.
You can only use the Shell to perform this procedure.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to view a list of transport agents in the transport pipeline
To use the Shell to view a list of transport agents in the transport pipeline on an Exchange server, run the following
command:

Get-TransportPipeline | Format-List

To export the results to a text file named C:\My Documents\Transport Agents.txt, run the following command:

Get-TransportPipeline | Format-List > "C:\My Documents\Transport Agents.txt"

How do you know this worked?

Only transport agents that have encountered messages in the transport pipeline between the time when the
transport service was started and the time when the Get-TransportPipeline cmdlet was run are displayed by the
cmdlet. A transport agent that hasn't encountered a message in the transport pipeline won't appear in the results
displayed by the Get-TransportPipeline cmdlet, even if that transport agent is enabled.
 Transport high availability
5/28/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, transport high availability is responsible for keeping redundant copies of
messages before and after the messages are successfully delivered. Exchange 2013 improves upon the transport
high availability features introduced in Exchange Server 2010, for example, shadow redundancy and the transport
dumpster, to help ensure messages aren't lost in transit.
Here's a summary of the major transport high availability improvements in Exchange 2013:
Shadow redundancy creates a redundant copy of the message on another server before the message is
accepted or acknowledged. The sending server's support or lack of support for shadow redundancy is
irrelevant.
Shadow redundancy recognizes both database availability groups (DAGs) and Active Directory sites as
transport high availability boundaries. This reduces the number of servers that can hold redundant copies of
messages, and eliminates unnecessary redundant message maintenance traffic across DAGs or Active
Directory sites.
For more information, see Shadow redundancy.
The transport dumpster has been improved and is now named Safety Net. Safety Net stores messages that
were successfully processed by the Transport service on Mailbox servers. Safety Net works best for Mailbox
servers in a DAG, but Safety Net also works for multiple Mailbox servers in the same Active Directory site
that don't belong to a DAG.
Safety Net itself is now made redundant on another server. This is important to avoid a single point of
failure in Exchange 2013, because the Transport service and the mailbox databases are both located on the
Mailbox server.
For more information, see Safety Net.
The following diagram provides a high-level overview of how transport high availability works in Exchange 2013.

1. An Exchange 2013 Mailbox server named Mailbox01 receives a message from an SMTP server that's
 outside the transport high availability boundary. The transport high availability boundary is a DAG or an
Active Directory site in non-DAG environments. The message could come from a third-party SMTP server,
from an Internet SMTP server proxied through a Client Access server, or from another Exchange 2013
server.
2. Before acknowledging receipt of the message, Mailbox01 initiates a new SMTP session to another Exchange
2013 Mailbox server named Mailbox03 that's within the Transport high availability boundary, and
Mailbox03 makes a shadow copy of the message. In DAG environments, a shadow server in a remote Active
Directory site is preferred. Mailbox01 is the primary server holding the primary message, and Mailbox03 is
the shadow server holding the shadow message.
3. The Transport service on Mailbox01 processes the primary message.
a. In this example, the recipient's mailbox is located on Mailbox01, so the Transport service transmits
the message to the local Mailbox Transport service.
b. The Mailbox Transport service delivers the message to the local mailbox database.
c. Mailbox01 queues a discard status for Mailbox03 that indicates the primary message was
successfully processed, and Mailbox01 moves a copy of the primary message into the local Primary
Safety Net. Note that the message moves between queues within the same queue database.
4. Mailbox03 periodically polls Mailbox01 for the discard status of the primary message.
5. When Mailbox03 determines Mailbox01 successfully processed the primary message, Mailbox03 moves the
shadow message into the local Shadow Safety Net. Note that the message moves between queues within
the same queue database.
The message is retained in Primary Safety Net and Shadow Safety Net until the message expires based on a
configurable timeout value. If a mailbox database failover occurs before the message expires, the Primary Safety
Net on Mailbox01 resubmits the message. If the Mailbox01 isn't available, the Shadow Safety Net on Mailbox03
takes over and resubmits the message.

Message redundancy in the Front End Transport service on Client

Access servers
A Client Access server has no message queues. It's a stateless proxy server that uses the Front End Transport
service to accept incoming SMTP connections and proxy them to the Transport service on a Mailbox server. The
Front End Transport service keeps the SMTP session with the sending server open while the primary message is
transmitted to the Transport service on a Mailbox server, and a shadow copy of the message is made by the
Transport service on a different Mailbox server within the transport high availability boundary. Only after both the
primary message and shadow message are successfully created, the end of data SMTP command is sent back to
the sending SMTP server through the Client Access server.
 Shadow redundancy
6/14/2019 • 20 minutes to read • Edit Online

Applies to: Exchange Server 2013

Shadow redundancy was introduced in Microsoft Exchange Server 2010 to provide redundant copies of
messages before they're delivered to mailboxes. In Exchange 2010, shadow redundancy delayed deleting a
message from the transport database on a transport server until the server verified the next hop in the message
delivery path completed delivery. If the next hop failed before reporting successful delivery back to the transport
server, the transport server resubmitted the message to that next hop. Exchange 2010 servers used the
XSHADOW verb to advertise their shadow redundancy support. If an SMTP server didn't support shadow
redundancy, Exchange 2010 used delayed acknowledgement based on a configured time interval on the Receive
connector to make a redundant copy of the message.
The major improvement to shadow redundancy in Microsoft Exchange Server 2013 is that the transport server
now makes a redundant copy of any messages it receives before it acknowledges successfully receiving the
message back to the sending server. The sending server's support or lack of support for shadow redundancy
doesn't matter. This helps to ensure that all messages in the Exchange 2013 transport pipeline are made
redundant while they're in transit. If Exchange 2013 determines the original message was lost in transit, the
redundant copy of the message is redelivered.

Shadow redundancy components

The following table describes the components of shadow redundancy. These terms are used throughout the topic.

TERM DESCRIPTION

Transport server An Exchange server that has message queues and is

responsible for routing messages. In Exchange 2013, a
transport server is a Mailbox server (the Transport
service on the Mailbox server).

Transport database The message queue database on an Exchange 2013

transport server. Shadow queues and Safety Net are also
stored in the transport database.

Transport high availability boundary A database availability group (DAG) in DAG

environments, or an Active Directory site in non-DAG
environments. When a message arrives on a transport
server in the transport high availability boundary,
Exchange tries to maintain 2 redundant copies of the
message on transport servers within the boundary.
When a message leaves the transport high availability
boundary, Exchange stops maintaining redundant copies
of the message.

Primary message The message submitted into the transport pipeline for
delivery.
 TERM DESCRIPTION

Shadow message The redundant copy of the message that the shadow
server retains until it confirms the primary message was
successfully processed by the primary server.

Primary server The transport server that's currently processing the

primary message.

Shadow server The transport server that holds the shadow message for
the primary server. A transport server may be the
primary server for some messages and the shadow
server for other messages simultaneously.

Shadow queue The delivery queue where the shadow server stores
shadow messages. For messages with multiple recipients,
each next hop for the primary message requires separate
shadow queues.

Discard status The information a transport server maintains for shadow

messages that indicate the primary message has been
successfully processed.

Discard notification The response a shadow server receives from a primary

server indicating a shadow message is ready to be
discarded.

Safety Net The Exchange 2013 improved version of the transport

dumpster. Messages that are successfully processed or
delivered to a mailbox recipient by the Transport service
on a Mailbox server are moved into Safety Net. For more
information, see Safety Net.

Shadow Redundancy Manager The transport component that manages shadow

redundancy.

Heartbeat The process that allows primary servers and shadow

servers to verify the availability of each other.

Requirements for shadow redundancy

Although it may seem obvious, shadow redundancy requires multiple Exchange 2013 Mailbox servers. The
Mailbox server can be standalone servers, or Mailbox servers and Client Access servers installed on the same
computer.
If the Mailbox server isn't a member of a DAG, the other Mailbox servers must be in the local Active
Directory site.
If the Mailbox server is a member of a DAG, the other Mailbox servers must belong to the same DAG. The
other Mailbox servers that belong to the DAG can be in the local Active Directory site or in a remote Active
Directory site. If the DAG spans multiple Active Directory sites, shadow redundancy prefers creating a
 redundant copy of the message in a remote Active Directory site for site resiliency.
These are the situations where shadow redundancy can't protect messages in transit:
In single Exchange server environments.
In under-provisioned DAGs.
During the simultaneous failure of two or more transport servers involved in the shadow redundancy of a
message.

Shadow redundancy is enabled by default

By default, shadow redundancy is enabled globally in the Transport service on all Mailbox servers by using the
ShadowRedundancyEnabled parameter on the Set-TransportConfig cmdlet. By default, if the Transport service
on a Mailbox server can't create a redundant copy of a message, the message is not rejected. However, you can
configure Exchange 2013 to reject a message if a redundant copy of the message isn't created by using the
RejectMessageOnShadowFailure parameter on the Set-TransportConfig cmdlet. The message is rejected with a
transient failure, but the sending server can transmit the message again. The SMTP response code is
451 4.4.0 Message failed to be made redundant. You should configure Exchange 2013 to reject messages that
can't be made redundant only when your organization has multiple Exchange 2013 Mailbox servers available.
The following table describes the parameters that enable shadow redundancy.
Parameters that enable shadow redundancy
PARAMETER DEFAULT VALUE DESCRIPTION

ShadowRedundancyEnabled on $true $true enables shadow

Set-TransportConfig redundancy on all transport
servers in the organization.
$false disables shadow
redundancy on all transport
servers in the organization.
 PARAMETER DEFAULT VALUE DESCRIPTION

RejectMessageOnShadowFailure $false $false When a shadow

on Set-TransportConfig copy of the message can't
be created, the primary
message is accepted
anyway by transport
servers in the organization.
Those messages aren't
redundantly persisted while
they're in transit.
$true No message is
accepted or acknowledged
by any transport server in
the organization until a
shadow copy of the
message is successfully
created. If a shadow copy of
the message can't be
created, the primary
message is rejected with a
transient error. All messages
in the organization are
redundantly persisted while
they're in transit.
You should set this value to
$true only if you have
multiple Exchange 2013
Mailbox servers in a DAG or
Active Directory site where
a shadow copy of the
message can be created.
This parameter is only meaningful
when ShadowRedundancyEnabled
is $true .

How shadow messages are created

The main goal of shadow redundancy is to always have two copies of a message within a transport high
availability boundary while the message is in transit. Where and when the redundant copy of the message is
created depends on where the message came from and where the message is going. There are three major
determining factors:
Messages received from outside a transport high availability boundary.
Messages sent outside a transport high availability boundary.
Messages received from the Mailbox Transport Submission service from a Mailbox server within the
transport high availability boundary.
A transport high availability boundary is one of the following:
A DAG, for Mailbox servers that are members of a DAG. This includes a DAG that spans multiple Active
Directory sites.
An Active Directory site, for Mailbox servers that don't belong to a DAG.
Shadow redundancy never tracks shadow messages across a transport high availability boundary. When a
message crosses the transport high availability boundary, shadow redundancy begins or restarts. This reduces
shadow message maintenance traffic and prevents shadow message resubmissions from occurring across the
transport high availability boundary. Exchange 2010 Hub Transport servers are a special case, and are discussed
later in this topic.

Messages received from outside a transport high availability boundary

When the Transport service on an Exchange 2013 Mailbox server receives a message from outside the transport
high availability boundary, the Mailbox server isn't concerned about the support or lack of support for shadow
redundancy by the sending server. As long as shadow redundancy is enabled, the Mailbox server that receives the
message makes a redundant copy of the message on another Mailbox server within the transport high
availability boundary before acknowledging receipt of the message back to the sending server. Here's an example
of how the process works:

1. An SMTP server transmits a message to the Transport service on a Mailbox server. The Mailbox server is
the primary server, and the message is the primary message.
2. While the original SMTP session with the SMTP server is still active, the Transport service on primary
server opens a new, simultaneous SMTP session with the Transport service on a different Mailbox server
in the organization to create a redundant copy of the message.
If the primary server is a member of a DAG, the primary server connects to a different Mailbox
server in the same DAG. If the DAG spans multiple Active Directory sites, a Mailbox server in a
different Active Directory site is preferred by default. This setting is controlled by the
ShadowMessagePreference parameter on the Set-TransportService cmdlet. The default value is
PreferRemote , but you can change it to RemoteOnly or LocalOnly .

If the primary server isn't a member of a DAG, the primary server connects to a different Mailbox
server in the same Active Directory Site, regardless of the value of the ShadowMessagePreference
parameter.
3. The primary server transmits a copy of the message to the Transport service on other Mailbox server, and
Transport service on the other Mailbox server acknowledges that the copy of the message was created
successfully. The copy of the message is the shadow message, and the Mailbox server that holds it is the
shadow server for the primary server. The message exists in a shadow queue on the shadow server.
4. After the primary server receives acknowledgement from the shadow server, the primary server
acknowledges the receipt of the primary message to the original SMTP server in the original SMTP
session, and the SMTP session is closed.
Messages sent outside a transport high availability boundary
When an Exchange 2013 transport server transmits a message outside the transport high availability boundary,
and the SMTP server on the other side acknowledges successful receipt of the message, the transport server
moves the message into Safety Net. No resubmission of the message from Safety Net can occur after the
primary message has been successfully transmitted across the transport high availability boundary. For more
information about Safety Net, see Safety Net.

Messages transmitted within a transport high availability boundary

Message routing is optimized in Exchange 2013 so that when the ultimate destination is in a DAG or Active
Directory site, multiple hops between the Transport service on Mailbox servers in that DAG or Active Directory
site aren't typically required. Once the message is accepted by the Transport service on a Mailbox server in the
DAG or Active Directory site that holds the ultimate destination for the message, the next hop for the message is
typically the ultimate destination itself. Shadow redundancy's goal of keeping two copies of a message in transit is
fulfilled when one shadow copy of the message exists anywhere within the DAG or Active Directory site. Typically,
only failover scenarios in a DAG that require the Redirect-Message cmdlet to drain the active queues on a
Mailbox server would require multiple hops within the same transport high availability boundary.

Shadow redundancy with Exchange 2010 Hub Transport servers in the

same Active Directory site
When an Exchange 2010 Hub Transport server transmits a message to an Exchange 2013 Mailbox server in the
same Active Directory site, the Exchange 2010 Hub Transport server advertises support for shadow redundancy
using the XSHADOW command, but the Mailbox server doesn't advertise support for shadow redundancy. This
prevents the Exchange 2010 Hub Transport server from creating a shadow copy of the message on an Exchange
2013 Mailbox server.
When the Transport service on an Exchange 2013 Mailbox server transmits a message to an Exchange 2010 Hub
Transport in the same Active Directory site, the Exchange 2013 Mailbox server shadows the message for the
Exchange 2010 Hub Transport server. After the Exchange 2013 Mailbox server receives acknowledgement from
the Exchange 2010 Hub Transport server that the message was successfully received, the Exchange 2013 Mailbox
server moves the successfully processed message into Safety Net. However, the successfully processed messages
stored in Safety Net by Exchange 2013 Mailbox are never resubmitted to the Exchange 2010 Hub Transport
servers.

SMTP timeouts
During the attempt to make a redundant copy of the message, the SMTP connection between the sending SMTP
server and the primary server, or the SMTP session between the primary server and the shadow server could
timeout. Receive connectors and Send connectors both have a ConnectionInactivityTimeOut parameter for when
data is actually being transmitted on the connector. Receive connectors also have an absolute
ConnectionTimeOut parameter.
If any of the SMTP sessions time out before the shadow copy of the message is successfully created and
acknowledged, the result is controlled by the RejectMessageOnShadowFailure parameter on the Set-
TransportConfig cmdlet. By default, the value of this parameter is $false , which means the primary message is
accepted without a shadow copy being created. If the value of this parameter is $true the primary message is
rejected with the transient error 451 4.4.0 .
If the shadow copy of a message is successfully created, but the SMTP session between the sending SMTP server
and the primary server times out, the primary server accepts and processes the primary message. The sending
SMTP server will re-deliver the unacknowledged message, but duplicate message detection will prevent
Exchange mailbox users from seeing the duplicate messages. When the sending SMTP server resubmits the
message, the primary server will create another shadow copy of the message. There's no relationship between
the shadow messages created during message resubmissions by the sending SMTP server.
The following table describes the parameters that control the creation of shadow messages
Shadow message creation parameters
SOURCE DEFAULT VALUE DESCRIPTION

ShadowMessagePreferenceSetting PreferRemote PreferRemote Try to

on Set-TransportConfig make a shadow copy of the
message on a Mailbox
server in a different Active
Directory site. If the
operation fails, try make a
shadow copy of the
message on a server in the
local Active Directory site.
LocalOnly A shadow
copy of the message should
only be made on a
transport server in the local
Active Directory site.
RemoteOnly : A shadow
copy of the message should
only be made on a
transport server in a
different Active Directory
site.
This parameter is only meaningful
when the primary server that's
trying to make a shadow copy of
the message is a Mailbox server
that's a member of a DAG that
spans multiple Active Directory
sites.
SOURCE DEFAULT VALUE DESCRIPTION

MaxRetriesForRemoteSiteShadow 4 This parameter is used when the

on Set-TransportConfig Mailbox server is a member of a
DAG that spans multiple Active
Directory sites.
If
ShadowMessagePreference
Setting is set to
PreferRemote , first the
Mailbox server tries to
create a shadow copy of the
message on another
Mailbox server in a remote
Active directory site up to
the number of times
specified by
MaxRetriesForRemoteSiteSh
adow. If this fails, the
Mailbox server tries to
create a shadow copy of the
message on a different
Mailbox server in the local
Active Directory site up to
the number of times
specified by
MaxRetriesForLocalSiteSha
dow.
If
ShadowMessagePreference
Setting is set to
RemoteOnly , the Mailbox
server only tries to create a
shadow copy of the
message on a Mailbox
server in a remote Active
Directory site up to the
number of times specified
by
MaxRetriesForRemoteSiteSh
adow.
The
When a shadow copy of the
message can't be successfully
created:
If
RejectMessageOnShadowFa
ilure is $true , the primary
message is rejected with a
transient error.
If
RejectMessageOnShadowFa
ilure is $false , the
primary message is
accepted anyway, but isn't
redundantly persisted.

MaxRetriesForLocalSiteShadow on 2 This parameter is used in the

Set-TransportConfig following circumstances:
SOURCE DEFAULT VALUE DESCRIPTION
If the Mailbox server is a
member of a DAG that
spans multiple Active
Directory sites.
1. If
ShadowMessagePref
erenceSetting is set
to PreferRemote ,
first the Mailbox
server tries to create
a shadow copy of
the message on
another Mailbox
server in a remote
Active directory site
up to the number of
times specified by
MaxRetriesForRemot
eSiteShadow. If this
fails, the Mailbox
server tries to create
a shadow copy of
the message on a
different Mailbox
server in the local
Active Directory site
up to the number of
times specified by
MaxRetriesForLocalS
iteShadow.
2. If
ShadowMessagePref
erenceSetting is set
to LocalOnly , the
Mailbox server only
tries to create a
shadow copy of the
message on a
different Mailbox
server in the local
Active Directory site
up to the number of
times specified by
the
MaxRetriesForLocalS
iteShadow.
If the Mailbox server isn't a
member of a DAG, or if the
Mailbox server is a member
of a DAG that's in one
Active Directory site, the
Mailbox server only tries to
create a shadow copy of the
message on a different
Mailbox server in the local
Active Directory site up to
the number of times
specified by
MaxRetriesForLocalSiteSha
dow.
When a shadow copy of the
 message can't be successfully
SOURCE DEFAULT VALUE DESCRIPTION
created:
If
RejectMessageOnShadowFa
ilure is $true , the primary
message is rejected with a
transient error.
If
RejectMessageOnShadowFa
ilure is $false , the
primary message is
accepted anyway, but isn't
redundantly persisted.

ConnectionInactivityTimeout on 5 minutes in the Transport service This parameter specifies the

Set-ReceiveConnector on Mailbox servers maximum time that an open SMTP
connection with a source
5 minutes in the Front End messaging server can remain idle
Transport service on Client Access before the connection is closed.
servers. The value of this parameter must
1 minute on Edge Transport be smaller than the value specified
servers. by the ConnectionTimeout
parameter.

ConnectionTimeout on Set- 10 minutes in the Transport service This parameter specifies the
ReceiveConnector on Mailbox servers maximum time that an SMTP
connection with a source
10 minutes in the Front End messaging server can remain open,
Transport service on Client Access even if the source messaging
servers. server is transmitting data. The
5 minutes on Edge Transport value of this parameter must be
servers. larger than the value specified by
the ConnectionInactivityTimeout
parameter.

ConnectionInactivityTimeOut on 10 minutes This parameter specifies the

Set-SendConnector maximum time that an open SMTP
connection with a destination
messaging server can remain idle
before the connection is closed.

How shadow messages are maintained

After a shadow message is successfully created, the work of shadow redundancy has only just begun. The
primary server and the shadow server need to stay in contact with each other to track the progress of the
message.
When the primary server successfully transmits the message to the next hop, and the next hop acknowledges
receipt of the message, the primary server updates the discard status of the message as delivery complete. The
discard status is basically a message that contains of list of messages that are being monitored. A successfully
delivered message doesn't need to be kept in a shadow queue, so once the shadow server knows the primary
server has successfully transmitted the message to the next hop, the shadow server moves the shadow message
from the shadow queue into Safety Net.
The shadow server determines the discard status of the shadow messages in its shadow queues by querying the
primary server. If the shadow server opens an SMTP session with the primary server for any reason, including
the transmission of other unrelated messages, the shadow server issues the XQDISCARD command to
determine the discard status of the primary messages. If the shadow server hasn't opened an SMTP session with
the primary server after a preconfigured time interval, the shadow server will open an SMTP session with the
primary server and issue the XQDISCARD command. The time interval is controlled by the
ShadowHeartbeatFrequentcy parameter on the Set-TransportConfig cmdlet. The default value is 2 minutes.
After the shadow server opens an SMTP session with the primary server, the primary server responds with the
discard notifications for messages that apply to the querying shadow server. In Exchange 2013, discard
notifications are stored on disk, not in memory. Therefore, if the Microsoft Exchange Transport service restarts,
the discard notifications are persisted. After the service starts, the primary server still knows about the messages
it successfully processed, and that information is available to the shadow server.
The SMTP communication between the shadow server and the primary server is used as the heartbeat that
determines the availability of the servers. If the shadow server can't open an SMTP session with the primary
server after a preconfigured time interval, or if the transport database of the primary server has a different
database ID, the shadow server promotes itself as the primary server, promotes the shadow messages as primary
messages, and transmits the messages to the next hop. The time interval is controlled by the
ShadowResubmitTimeSpan parameter on the Set-TransportConfig cmdlet. The default value is 3 hours.
Shadow Redundancy Manager is the core component of an Exchange 2013 transport server that's responsible
for managing shadow redundancy. Shadow Redundancy Manager is responsible for maintaining the following
information for all the primary messages that a server is currently processing:
The shadow server for each primary message being processed.
The discard status to be sent to shadow servers.
Shadow Redundancy Manager is responsible for the following for all the shadow messages that a shadow server
has in its shadow queues:
Maintaining the list of primary servers for each shadow message.
Comparing the original database ID and the current database ID of the queue database where the primary
copy of the message is stored.
Checking the availability of each primary server for which a shadow message is queued.
Processing discard notifications from primary servers.
Removing the shadow messages from the shadow queues after all expected discard notifications are
received.
Deciding when the shadow server should take ownership of shadow messages, becoming a primary
server.
Tracking message bifurcations and other side-effect messages like delivery status notifications (DSNs) and
journal reports to verify the redundant copy of the message isn't released until all forks of the message are
fully processed.
The following table describes the parameters that control how shadow messages are maintained.

PARAMETER DEFAULT VALUE DESCRIPTION

ShadowHeartbeatFrequency on 2 minutes The maximum amount of time a

Set-TransportConfig shadow server waits before
opening an SMTP connection to
the primary server to check the
discard status of messages.
 PARAMETER DEFAULT VALUE DESCRIPTION

ShadowResubmitTimeSpan on Set- 3 hours How long a server waits before

TransportConfig deciding that a primary server has
failed and assumes ownership of
shadow messages in the shadow
queue for the primary server that's
unreachable.

ShadowMessageAutoDiscardInterv 2 days How long a server retains discard

al on Set-TransportConfig events for successfully delivered
messages. A primary server queues
discard events until queried by the
shadow server. However, if the
shadow server doesn't query the
primary server for the duration
specified in this parameter, the
primary server deletes the queued
discard events.

SafetyNetHoldTime on Set- 2 days How long successfully processed

TransportConfig messages are retained in Safety
Net. Unacknowledged shadow
messages eventually expire from
Safety Net after the sum of
SafetyNetHoldTime and
MessageExpirationTimeout on Set-
TransportService.

MessageExpirationTimeout on Set- 2 days How long a message can remain in

TransportService a queue before it expires.

Message processing after an outage

Shadow redundancy minimizes message loss due to server outages. When a transport server comes back online
after an outage, there are two scenarios:
The server comes back online with a new transport database: In this scenario, the transport database
is unrecoverable due to data corruption or hardware failure. In this case, because the transport server will
have a new database ID, it will be recognized as a new route by the other transport servers in the
organization. This also applies to the situation where a server couldn't be recovered, and a new server was
provisioned as a replacement.
The server comes back online with the same transport database: In this scenario, the particular
transport server didn't fail, but was offline long enough for the shadow server to assume ownership of the
messages and resubmit them. For example, a network card failure, or a long maintenance on the server
would cause this scenario.
The following table summarizes how shadow redundancy reacts to these two scenarios. For clarity, assume that
the server that had an outage is named Mailbox01.
Message processing in recovery scenarios
RECOVERY SCENARIO ACTIONS TAKEN

Mailbox01 comes back online with a new database. When Mailbox01 becomes unavailable, each server that
has shadow messages queued for Mailbox01 will assume
ownership of those messages and resubmit them. The
messages then get delivered to their destinations.
The maximum delay for messages is the value of the
ShadowHeartbeatFrequency parameter on the Set-
TransportConfig cmdlet. The default value is 2 minutes.

Mailbox01 comes back online with the same database. After Mailbox01 comes back online, it will deliver the
messages in its queues, which have already been
delivered by the servers that hold shadow copies of
messages for Mailbox01. This will result in duplicate
delivery of these messages. Exchange mailbox users won't
see duplicate messages due to duplicate message
detection. However, recipients on non-Exchange
messaging systems may receive duplicate copies of
messages.
The maximum delay for messages is the value of the
ShadowResubmitTimeSpan parameter on the Set-
TransportConfig cmdlet. The default value is 3 hours.
 Safety Net
6/14/2019 • 11 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, the primary mechanism of mailbox high availability is the database
availability group (DAG ). For more information about DAGs, see Managing database availability groups. The
transport dumpster was first introduced in Exchange 2007, and was further improved in Exchange 2010 to
provide redundant copies of messages after they're successfully delivered to mailboxes in DAGs. In Exchange
2010, the transport dumpster helped protect against data loss by maintaining a queue of successfully delivered
messages that hadn't replicated to the passive mailbox database copies in the DAG. When a mailbox database or
server failure required the promotion of an out-of-date copy of the mailbox database, the messages in the
transport dumpster were automatically resubmitted to the new active copy of the mailbox database.
The transport dumpster has been improved in Exchange 2013 and is now called Safety Net.
Here's how Safety Net is similar to the transport dumpster in Exchange 2010:
Safety Net is a queue that's associated with the Transport service on a Mailbox server. This queue stores
copies of messages that were successfully processed by the server.
You can specify how long Safety Net stores copies of the successfully processed messages before they
expire and are automatically deleted. The default is 2 days.
Here's how Safety Net is different in Exchange 2013:
Safety Net doesn't require DAGs. For Mailbox servers that don't belong to a DAGs, Safety Net stores
copies of the delivered messages on other Mailbox servers in the local Active Directory site.
Safety Net itself is now redundant, and is no longer a single point of failure. This introduces the concept of
the Primary Safety Net and the Shadow Safety Net. If the Primary Safety Net is unavailable for more than
12 hours, resubmit requests become shadow resubmit requests, and messages are re-delivered from the
Shadow Safety Net.
Safety Net takes over some responsibility from shadow redundancy in DAG environments. Shadow
redundancy doesn't need to keep another copy of the delivered message in a shadow queue while it waits
for the delivered message to replicate to the passive copies of mailbox database on the other Mailbox
servers in the DAG. The copy of the delivered message is already stored in Safety Net, so the message can
be resubmitted from Safety Net if necessary.
In Exchange 2013, transport high availability is more than just a best effort for message redundancy.
Exchange 2013 attempts to guarantee message redundancy. Because of this, you can't specify a maximum
size limit for Safety Net. You can only specify how long Safety Net stores messages before they're
automatically deleted.

How Safety Net works

Shadow redundancy keeps a redundant copy of the message while the message is in transit. Safety Net keeps a
redundant copy of a message after the message is successfully processed. So, Safety Net begins where shadow
redundancy ends. The same concepts about shadow redundancy, including the transport high availability
boundary, primary messages, primary servers, shadow messages and shadow servers also apply to Safety Net.
For more information, see Shadow redundancy.
The Primary Safety Net exists on the Mailbox server that held the primary message before the message was
successfully processed by the Transport service. This could mean the message was delivered to the Mailbox
Transport service on the destination Mailbox server. Or, the message could have been relayed through the
Mailbox server in an Active Directory site that's designated as a hub site on the way to the destination DAG or
Active Directory site. After the primary server processes the primary message, the message is moved from the
active queue into the Primary Safety Net on the same server.
The Shadow Safety Net exists on the Mailbox server that held the shadow message. After the shadow server
determines the primary server has successfully processed the primary message, the shadow server moves the
shadow message from the shadow queue into the Shadow Safety Net on the same server. Although it may seem
obvious, the existence of the Shadow Safety Net requires shadow redundancy to be enabled, and shadow
redundancy is enabled by default in Exchange 2013.
The parameters used by Safety Net are described in the following table.

PARAMETER DEFAULT VALUE DESCRIPTION

SafetyNetHoldTime on Set- 2 days The length of time successfully

TransportConfig processed primary messages are
stored in Primary Safety Net, and
acknowledged shadow messages
are stored in Shadow Safety Net.
You can also specify this value in
the Exchange admin center (EAC) at
Mail flow > Receive connectors
> More options >
Organization transport settings
> Safety Net > Safety Net hold
time.
Unacknowledged shadow
messages eventually expire from
Shadow Safety Net after the sum of
SafetyNetHoldTime and
MessageExpirationTimeout on Set-
TransportService.
To avoid data loss during Safety
Net resubmits, the value of
SafetyNetHoldTime must be
greater than or equal to the value
of ReplayLagTime on Set-
MailboxDatabaseCopy for the
lagged copy of the mailbox
database.
 PARAMETER DEFAULT VALUE DESCRIPTION

ReplayLagTime on Set- Not configured The amount of time that the

MailboxDatabaseCopy Microsoft Exchange Replication
service should wait before
replaying log files that have been
copied to the passive database
copy. Setting this parameter to a
value greater than 0 creates a
lagged copy of the mailbox
database. The maximum value is 14
days.
To avoid data loss during Safety
Net resubmits, the value of
ReplayLagTime must be less than
or equal to the value of
SafetyNetHoldTime on Set-
TransportConfig for the lagged
copy of the mailbox database.

MessageExpirationTimeout on Set- 2 days How long a message can remain in

TransportService a queue before it expires.

ShadowRedundancyEnabled on $true $true enables shadow

Set-TransportConfig redundancy on all transport
servers in the organization.
$false disables shadow
redundancy on all transport
servers in the organization.
A redundant Safety Net requires
shadow redundancy to be enabled.

Message resubmission from Safety Net

Message resubmissions from Safety Net are initiated by the Active Manager component of the Microsoft
Exchange Replication service that manages DAGs and mailbox database copies. No manual actions are required
to resubmit messages from Safety Net. For more information about Active Manager, see Active Manager.
There are two basic Safety Net message resubmission scenarios:
After the automatic or manual failover of a mailbox database in a DAG.
After you active a lagged copy of a mailbox database.
A lagged mailbox database copy or lagged copy is a passive copy of a mailbox database where updates to the
database are intentionally delayed to protect against logical corruption of the mailbox database. For more
information, see Managing mailbox database copies.
The only significant difference between the two scenarios is how far back in time to go to resubmit messages
from Safety Net. Typically, for failover in a DAG, the new active copy of the mailbox database is typically several
minutes to several hours behind the old active copy. A lagged copy of a mailbox database is typically several days
behind the old active copy.
The main requirement for successful resubmission from Safety Net for a lagged copy is the amount of time
messages are stored in Safety Net must be greater than or equal to the lag time of lagged copy of the mailbox
database. In other words, the value of SafetyNetHoldTime on Set-TransportConfig must be greater than or
equal to the value of the ReplayLagTime on Set-MailboxDatabaseCopy for the lagged copy.

Message resubmission from Shadow Safety Net

Like message resubmission from Primary Safety Net, message resubmissions from Shadow Safety Net are fully
automated, and require no manual intervention.
When the Active Manager requests message resubmission from Safety Net over a specific time period, the
request goes to the Transport service on the Mailbox servers where Primary Safety Net is holding the message
copies for the required time period. In large Exchange organizations, it's likely that the required messages exist in
Safety Net on multiple Mailbox servers, particularly if the required time period is large.
Without optimization, resubmitting messages from Safety Net would result in potentially large numbers of
duplicate deliveries. Duplicate deliveries within the Exchange organization aren't a problem, because duplicate
message detection prevents mailbox users from seeing duplicate copies of a message. But duplicate message
delivery to recipients outside the Exchange organization will result in duplicate copies of messages. Fortunately,
the resubmission of messages from Safety Net has been optimized in Exchange 2013 to reduce duplicate
message delivery.
If the Primary Safety Net is initially unresponsive, or becomes unresponsive during message resubmission, Active
Manager continues to attempt to contact it for 12 hours before giving up. After 12 hours, a broadcast is sent to
the Transport service on all the Mailbox servers in the transport high availability bound requesting resubmission
of message from Safety Net for the required time interval for the required mailbox database. When a Shadow
Safety Net responds, it resubmits the messages for the required mailbox database during the required time
interval only.
There are some important considerations for the shadow messages stored in Shadow Safety Net:
Shadow Safety Net doesn't know where the primary server transmitted the primary message.
The shadow messages in Shadow Safety Net only contain original message envelope recipients, not the
actual recipients where the primary message was delivered. For example, the message envelope recipient
may be a distribution group that requires expansion.
The messages in Shadow Safety net don't have any of the message updates that occurred after the primary
server processed the message. For example, message encoding or content conversion.
Shadow message resubmitted from Shadow Safety Net require full categorization and processing through the
Transport service on the Mailbox server. Resubmission of large numbers of shadow messages from Shadow
Safety Net can be expensive in terms of Mailbox server resources. Fortunately, resubmission of shadow messages
from Shadow Safety Net is also optimized so only messages in the Shadow Safety Net for the requested time
interval and the requested mailbox database are resubmitted.
The interaction of Primary Safety Net and Shadow Safety Net during message resubmission is described in the
following scenario.
1. Active Manager requests a resubmission of messages from Safety Net for a mailbox database for the time
interval 5:00 to 9:00. However, the Mailbox server that holds the Primary Safety Net has crashed due to a
hardware failure. Active Manager repeatedly tries to contact the Primary Safety Net for 12 hours.
2. After 12 hours, Active Manager sends a broadcast message to the Transport service on all Mailbox servers
in the transport high availability boundary looking for other Safety Nets that contain messages for the
target mailbox database for the time interval 5:00 to 9:00. The Shadow Safety Net responds are resubmits
messages for the mailbox database for the time interval 5:00 to 9:00.
An interesting interaction occurs if the Primary Safety Net was offline during part of the requested resubmit
interval as described in the following scenario.
1. The queue database on Mailbox server that holds the Primary Safety Net is corrupt, and a new queue
database is created at 7:00. All of the primary messages stored in the Primary Safety Net from 1:00 to 7:00
are lost, but the server is able to store copies of successfully delivered messages in Safety Net starting at
7:00.
2. Active Manager requests a resubmission of messages from Safety Net for a mailbox database for the time
interval 1:00 to 9:00.
3. The Primary Safety Net resubmits messages for the time interval 7:00 to 9:00.
4. The Primary Safety Net sends a broadcast message to the Transport service on all Mailbox servers in the
transport high availability boundary looking for other Safety Nets that contain messages for the target
mailbox database for the time interval 1:00 to 7:00 for which the Primary Safety Net has no message. The
Shadow Safety Net generates a second resubmit request on behalf of the Primary Safety Net for
resubmitting the shadow messages for the target mailbox database for the time interval 1:00 to 7:00.
There are some other issues to consider when messages are resubmitted from Safety Net.
1. All delivery status notifications (DSNs) and non-delivery reports (NDRs) are suppressed for Safety Net
resubmits. For example, if the primary message resulted in an NDR, the NDR for the resubmitted message
won't be delivered.
2. Users removed from a distribution group may not receive a resubmitted message when the Shadow Safety
Net resubmits the message. For example, a message is sent to a group containing User A and User B, and
both recipients receive the message. User B is subsequently removed from the group. Later, a resubmit
request from Primary Safety Net is made for the mailbox database that holds User B's mailbox. However,
the Primary Safety Net is unavailable for more than 12 hours, so the Shadow Safety Net server responds
and resubmits the affected message. During resubmission when the distribution group is expanded, User B
isn't a member of the group, and won't receive a copy of the resubmitted message.
3. New Users added to a distribution group may receive an old resubmitted message when the Shadow
Safety Net resubmits the message. For example, a message is sent to a group containing User A and User
B, and both recipients receive the message. User C is subsequently added to the group. Later, a resubmit
request from Primary Safety Net is made for the mailbox database that holds User C's mailbox. However,
the Primary Safety Net server is unavailable for more than 12 hours, so the Shadow Safety Net server
responds and resubmits the affected messages. During resubmission when the distribution group is
expanded, User C is a member of the group, and will receive a copy of the resubmitted message.
 Transport logs
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Transport logs provide information about what's happening in the transport pipeline. The following transport logs
are available in Microsoft Exchange Server 2013:
Agent logs: Agent logging records the actions performed on a message by specific anti-spam agents. Agent
logging is available in the Transport service on a Mailbox server. For more information, see Anti-spam agent
logging.
Connectivity logs: Connectivity logging records the outbound connection activity transport services. Connectivity
logging is available in the Front End Transport service on Client Access servers, the Transport service on Mailbox
servers, and the Mailbox Transport service on Mailbox servers. For more information, see Connectivity logging.
Message tracking and delivery reports: Message tracking logs the details of all message activity as messages
are transferred to and from an Exchange 2013 Mailbox server. Message tracking is available in the Transport
service on Mailbox servers, and in the Mailbox Transport service on Mailbox servers. For more information, see
Message tracking.
Delivery reports uses the information stored in the message tracking log to search for information about messages
sent to or sent from a specific mailbox. For more information, see Delivery reports for administrators.
Pipeline tracing: Pipeline tracing records snapshots of messages before and after the message is affected by
transport agents in the Transport service on Mailbox servers, and in the Mailbox Transport Delivery service on
Mailbox servers. For more information, see Pipeline tracing.
Protocol logs: Protocol logging records the SMTP conversations that occur on Send connectors and Receive
connectors as part of message delivery. Protocol logging is available in the Front End Transport service on Client
Access servers, the Transport service on Mailbox servers, and the Mailbox Transport service on Mailbox servers.
For more information, see Protocol logging.
Routing table logs: Routing table logging periodically records a snapshot of the routing table that's used by
Exchange 2013 to route messages to their destinations. Routing table logging is available in the Transport service
on Mailbox servers.
 Anti-spam agent logging
6/11/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

Agent logs record the actions performed on a message by specific anti-spam agents in Microsoft Exchange Server
2013. Only the following agents can write information to the agent log:
Connection Filtering agent
Content Filter agent
Edge Rules agent
Recipient Filter agent
Sender Filter agent
Sender ID agent

NOTE
The Connection Filtering agent and the Edge Rules agent aren't available on Mailbox servers.

The information written to the agent log depends on the agent, the SMTP event, and the action performed on the
message.
You use the Set-TransportService cmdlet in the Exchange Management Shell to perform all agent log
configuration tasks. The following options are available for the agent logs:
Enable or disable agent logging. The default is enabled.
Specify the location of the agent log files. The default value is
%ExchangeInstallPath%TransportRoles\Logs\Hub\AgentLog.
Specify a maximum size for the individual agent log files. The default size is 10 megabytes (MB ).
Specify a maximum size for the directory that contains agent log files. The default size is 250 MB.
Specify a maximum age for the agent log files. The default age is 7 days.
Exchange uses circular logging to limit the agent logs based on file size and file age to help control the hard disk
space used by the log files.

Overview of transport agents

Agents can only act upon messages at specific points in the SMTP command sequence used to transport the
messages through the Transport service on a Mailbox server or an Edge Transport server. These access points in
the SMTP command sequence are called SMTP events. Each agent has a priority value that can be assigned.
However, the SMTP events must always occur in a specific order. Therefore, the agent priority depends on the
SMTP event. If two agents can act on a message during the same SMTP event, the agent that has the highest
priority will act on the message first.
The following table lists the SMTP events in order of occurrence and the agents that write information to the agent
log in order of priority from highest to lowest for each SMTP event.
SMTP events in order of occurrence and the agents that write information to the agent log in order of priority
for each SMTP event
SMTP EVENT AGENT

OnConnect Connection Filtering agent

OnMailCommand Connection Filtering agent

Sender Filter agent

OnRcptCommand Connection Filtering agent

Recipient Filter agent

OnEndOfHeaders Connection Filtering agent

Sender ID agent
Sender Filter agent

OnEndOfData Edge Rules agent

Content Filtering agent

NOTE
The Connection Filtering agent and the Edge Rules agent aren't available on Mailbox servers.

For more information about agents, SMTP events, and agent priority, see Transport agents.

Structure of the agent log files

The agent logs exist in %ExchangeInstallPath%TransportRoles\Logs\Hub\AgentLog.
The naming convention for the agent log files is AGENTLOGyyyymmdd -nnnn.log. The placeholders represent the
following information:
The placeholder yyyymmdd is the Coordinated Universal Time (UTC ) date that the log file was created. The
placeholder yyyy = year, mm = month, and dd = day.
The placeholder nnnn is an instance number that starts at the value of 1 for each day.
Information is written to the log file until the file size reaches its maximum specified value, and a new log file that
has an incremented instance number is opened. This process is repeated throughout the day. Circular logging
deletes the oldest log files when the agent log directory reaches its maximum specified size, or when a log file
reaches its maximum specified age.
The agent log files are text files that contain data in the comma-separated value file (CSV ) format. Each agent log
file has a header that contains the following information:
#Software: Name of the software that created the agent log file. Typically, the value is Microsoft Exchange
Server.
#Version: Version number of the software that created the agent log file. Currently, the value is 15.0.0.0.
 #Log-Type: Log type value, which is Agent Log.
#Date: UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601
date-time format: yyyy-mm -ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates the
beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z
signifies Zulu, which is another way to denote UTC.
#Fields: Comma delimited field names used in the agent log files.

Information written to the agent log

The agent log stores each agent transaction on a single line in the log. The information stored on each line is
organized by fields. These fields are separated by commas. The field name is generally descriptive enough to
determine the type of information it contains. However, some of the fields may be blank. Or the type of
information stored in the field may change based on the agent or the action performed on the message by the
agent. The following table describes the fields used to classify each agent transaction.
Fields used to classify each agent transaction
FIELD NAME DESCRIPTION

Timestamp UTC date-time of the agent event. The UTC date-time is

represented in the ISO 8601 date-time format: yyyy-mm-
ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd =
day, T indicates the beginning of the time component, hh
= hour, mm = minute, ss = second, fff = fractions of a
second, and Z signifies Zulu, which is another way to
denote UTC.

SessionId Unique SMTP session identifier. This identifier is

represented as a 16-digit hexadecimal number.

LocalEndpoint Local IP address and port number that accepted the

message. SMTP sessions typically use port 25.

RemoteEndpoint IP address and port number of the previous SMTP server

that connected to this server to deliver the message.
When Internet mail flows through an Edge Transport
server in the perimeter network, the value of
RemoteEndpoint in the agent log on the Mailbox server
will be the IP address of the Edge Transport server. Even
though the message is transmitted by SMTP, the port
number used by the sending server will be a random
number larger than 1,024.

EnteredOrgFromIP IP address of the remote SMTP server that first connected

to the Exchange organization to deliver the message. On
an Edge Transport server, the value of RemoteEndpoint
and EnteredOrgFromIP are the same. Anti-spam agents
use the IP address in EnteredOrgFromIP to examine a
message.
FIELD NAME DESCRIPTION

MessageId Value of the MessageID header field. If this value is

blank, the Exchange transport server assigns an arbitrary
value, but only if the message is accepted. After a value is
assigned, the value of MessageID is constant for the
lifetime of the message.

P1FromAddress Sender email address specified in MAIL FROM in the

message envelope. This value is used to transport the
message between SMTP messaging servers. This value
serves as a comparison to the value of
P2FromAddresses to determine whether the sender
address in the message header is forged.

P2FromAddresses Sender email address specified in the From header field

or in the Sender header field in the message header.

Recipient Email address of the recipients. Although the original

message may contain multiple recipients, only one
recipient is displayed per line in the agent log.

NumRecipients Total number of recipients in the original message.

Agent Name of the agent that took the action. The possible
values are as follows:
Content Filter agent
Recipient Filter agent
Sender Filter agent
Sender ID agent

Event SMTP event where the action was taken by the agent. The
value of Event depends on the agent. The SMTP events
available to each agent are described in the first table
earlier in this topic. The possible values for Event are as
follows:
OnConnect
OnEndOfHeaders
OnEndOfData
OnMailCommand
OnRcptCommand
 FIELD NAME DESCRIPTION

Action Action performed on the message by the agent. The

possible values for Action are as follows:
AcceptMessage
DeleteMessage
DeleteRecipients
Disconnect
QuarantineMessage
QuarantineRecipients
RejectAuthentication
RejectCommand
RejectConnection
RejectMessage
RejectRecipients

SmtpResponse Enhanced SMTP response as defined in RFC 2034.

Reason Reason for the action supplied by the agent.

ReasonData Descriptive details for the action supplied by the agent.

Search the agent logs

You can use the Get-AgentLog cmdlet and the Get-AntiSpamFilteringReport.ps1 script to search the agent
logs.
The Get-AntiSpamFilteringReport.ps1 script is located in %ExchangeInstallPath%Scripts . You need to run the
script in the Shell from the Scripts folder. To change your location in the Shell to the Scripts folder, run the
following command:

Cd $env:ExchangeInstallPath\Scripts

To run the script in the Scripts folder, use the following syntax:

.\Get-AntiSpamFilteringReport.ps1 -report <ReportValue> [<OptionalParameters>]

For details about using the script, run the following command:

Get-Help -Detailed .\Get-AntiSpamFilteringReport.ps1

 Configure anti-spam agent logging
6/11/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Agent logging records the actions performed by specific Exchange anti-spam agents. The information written to
the agent log depends on the agent, the SMTP event, and the action performed on the message.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport Service" and "Edge Transport server" entries in the Mail flow
permissions topic.
By default, anti-spam features aren't enabled in the Transport service on a Mailbox server. Typically, you only
enable the anti-spam features on a Mailbox server if your Exchange organization doesn't do any prior anti-
spam filtering before accepting incoming messages. For more information, see Enable anti-spam
functionality on Mailbox servers.
You can only use the Shell to perform this procedure.
For information about keyboard shortcuts that may apply to the procedures in this topic, see
Keyboard shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure anti-spam agent logging

Run the following command:

Set-TransportService <ServerIdentity> -AgentLogEnabled <$true | $false> -AgentLogMaxAge <dd.hh:mm:ss> -

AgentLogMaxDirectorySize <Size> -AgentLogMaxFileSize <Size> -AgentLogPath <LocalFilePath>

This example sets the following agent log settings on the Mailbox server named Mailbox01:
Sets the location of the agent log files to D:\Anti-Spam Agent Log. Note that if the folder doesn't exist, it will
be created for you.
Sets the maximum size of an agent log file to 20 MB.
Sets the maximum size of the agent log directory to 400 MB.
Sets the maximum age of an agent log file to 14 days.

Set-TransportService Mailbox01 -AgentLogPath "D:\Anti-Spam Agent Log" -AgentLogMaxFileSize 20MB -

AgentLogMaxDirectorySize 400MB -AgentLogMaxAge 14.00:00:00
 NOTE
If you set the AgentLogPath parameter to the value $null , you effectively disable agent logging. However, if you set
AgentLogPath to $null when the value of the AgentLogEnabled parameter is $true , event log errors are
generated. The preferred method to disable agent logging is to set AgentLogEnabled to $false .
Setting the AgentLogMaxAge parameter to the value 00:00:00 prevents the automatic removal of agent log files
because of their age.

For detailed syntax and parameter information, see the AgentLog parameters in Set-TransportService.

How do you know this worked?

To verify that you have successfully configured anti-spam agent logging, do the following:
1. In the Shell, run the following command:

Get-TransportService <ServerIdentity> | Format-List AgentLog*

2. Verify the values displayed are the values you configured.

 Connectivity logging
6/11/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Connectivity logging records the outbound connection activity that's used to transmit messages from a transport
service on the Exchange server. The purpose of the connectivity log isn't to track the transmission of individual
email messages. Rather, the connectivity log tracks the connection activity from source to the destination,
regardless of how many messages are transmitted. Connectivity logging is available in the Front End Transport
service on Client Access servers, the Transport service on Mailbox servers, and the Mailbox Transport service on
Mailbox servers. The following list describes the type of information recorded in the connectivity log:
Source
Destination
DNS resolution information
Detailed information about connection failures
Number of messages and bytes transmitted
You use the Set-TransportService, Set-FrontEndTransportService and Set-MailboxTransportService cmdlets
in the Exchange Management Shell to perform all connectivity log configuration tasks. The following options are
available for the connectivity logs:
Enable or disable connectivity logging. The default is enabled.
Specify the location of the connectivity log files.
Specify a maximum size for the individual connectivity log files. The default size is 10 megabytes (MB ).
Specify a maximum size for the directory that contains connectivity log files. The default size is 1000 MB.
Specify a maximum age for the connectivity log files. The default age is 30 days.
By default, Exchange uses circular logging to limit the connectivity logs based on file size and file age to help
control the hard disk space used by the connectivity log files.

Structure of the connectivity log files

By default, the connectivity log files exist in the following locations:
Transport service: %ExchangeInstallPath%TransportRoles\Logs\Hub\Connectivity
Front End Transport service: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\Connectivity
Mailbox Transport service: %ExchangeInstallPath%TransportRoles\Logs\Mailbox\Connectivity
The naming convention for the connectivity log files is CONNECTLOGyyymmdd -nnnn.log. The placeholders
represent the following information:
The placeholder yyyymmdd is the Coordinated Universal Time (UTC ) date that the log file was created. The
placeholder yyyy = year, mm = month, and dd = day.
The placeholder nnnn is an instance number that starts at the value of 1 for each day.
Information is written to the log file until the file size reaches its maximum specified value, and a new log file that
has an incremented instance number is opened. This process is repeated throughout the day. Circular logging
deletes the oldest log files when the connectivity log directory reaches its maximum specified size, or when a log
file reaches its maximum specified age.
The connectivity log files are text files that contain data in the comma-separated value file (CSV ) format. Each
connectivity log file has a header that contains the following information:
#Software: Name of the software that created the connectivity log file. Typically, the value is Microsoft
Exchange Server.
#Version: Version number of the software that created the connectivity log file. Currently, the value is
15.0.0.0.
#Log-Type: Log type value, which is Transport Connectivity Log.
#Date: UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601
date-time format: yyyy-mm -ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates the
beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z
signifies Zulu, which is another way to denote UTC.
#Fields: Comma delimited field names used in the connectivity log files.

Information written to the connectivity log

The connectivity log stores each outbound transport service connection event on a single line in the connectivity
log. The information stored on each line is organized by fields. These fields are separated by commas. The
following table describes the fields used to classify each outgoing connection event.
Fields used to classify each connection event
FIELD NAME DESCRIPTION

date-time UTC date-time of the connection event. The UTC date-

time is represented in the ISO 8601 date-time format:
yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm =
month, dd = day, T indicates the beginning of the time
component, hh = hour, mm = minute, ss = second, fff =
fractions of a second, and Z signifies Zulu, which is
another way to denote UTC.

session GUID that's unique for each SMTP session but is the same
for each event associated with that SMTP session. For
MAPI sessions in the Mailbox Transport service, the
session field is blank.

source SMTP for SMTP connections, MAPI for Mailbox Transport

service connections to the local mailbox database.

destination Name of the destination.

 FIELD NAME DESCRIPTION

direction Single character that represents the start, middle, or end

of the connection. The possible values for the direction
field are as follows:
+ Connect
- Disconnect
> Send

description Text information associated with the connection event.

The following values are examples of values for the
description field:
Number and size of messages that were
transmitted
DNS MX resource record resolution information for
destination domains
DNS resolution information for destination Mailbox
servers
Connection establishment messages
Connection failure messages

When transport service establishes a connection to a destination, the transport service may be prepared to send
one message or several messages. The connection and message transmission processes generate multiple events
written on multiple lines in the connectivity log. Simultaneous connections to different destinations create
connectivity log entries related to different destinations that are interlaced. However, you can use the date-time,
session, source, and direction fields to arrange the connectivity log entries for each separate connection from start
to finish.
 Configure connectivity logging
6/11/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Connectivity logging records the outbound connection activity that's used to transmit messages from a transport
service on an Exchange server. Connectivity logging records the connection source, destination, number of
messages and bytes transmitted, and connection failure information.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport service", "Front End Transport service", and "Mailbox Transport
service" entries in the Mail flow permissions topic.
You can use the Exchange admin center (EAC ) to enabled or disabled connectivity logging, or set the
connectivity log path for the Transport service only. For all other connectivity logging options in other
transport services, you need to use the Shell.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure connectivity logging in the Transport service

1. In the EAC, navigate to Servers > Servers.
2. Select the Mailbox server you want to configure, and then click Edit .
3. On the server properties page, click Transport Logs.
4. In the Connectivity log section, change any of the following:
Enable connectivity log: To disable connectivity logging on the server, clear the check box. To
enable connectivity logging on the server, select the check box.
Connectivity log path: The value you specify must be on the local Exchange server. If the folder
doesn't exist, it will be created for you when you click Save.
When you are finished, click Save.

Use the Shell to configure connectivity logging

To configure connectivity logging, run the following command:
 <Set-TransportService | Set-MailboxTransportService | Set-FrontEndTransportService> <ServerIdentity> -
ConnectivityLogEnabled <$true | $false> -ConnectivityLogMaxAge <dd.hh:mm:ss> -ConnectivityLogMaxDirectorySize
<Size> -ConnectivityLogMaxFileSize <Size> -ConnectivityLogPath <LocalFilePath>

This example sets the following connectivity log settings in the Transport service on the Mailbox server named
Mailbox01:
Sets the location of the connectivity log files to D:\Hub Connectivity Log. Note that if the folder doesn't exist,
it will be created for you.
Sets the maximum size of a connectivity log file to 20 MB.
Sets the maximum size of the connectivity log directory to 1.5 GB.
Sets the maximum age of a connectivity log file to 45 days.

Set-TransportService Mailbox01 -ConnectivityLogPath "D:\Hub Connectivity Log" -ConnectivityLogMaxFileSize 20MB

-ConnectivityLogMaxDirectorySize 1.5GB -ConnectivityLogMaxAge 45.00:00:00

NOTE
To configure the connectivity log settings in the Mailbox Transport service on a Mailbox server, use the Set-
MailboxTransportService cmdlet. To configure the connectivity log settings in the Front End Transport service on a
Client Access server, use the Set-FrontEndTransportService cmdlet.
Setting the ConnectivityLogPath parameter to the value $null , effectively disables connectivity logging. However, if
the value of the ConnectivityLogEnabled parameter is $true , event log errors are generated.
Setting the ConnectivityLogMaxAge parameter to the value 00:00:00 prevents the automatic removal of
connectivity log files because of their age.

How do you know this worked?

To verify that you have successfully configured connectivity logging, do the following:
1. In the Shell, run the following command:

<Get-TransportService | Get-FrontEndTransportService | Get-MailboxTransportService> <ServerIdentity> |

Format-List ConnectivityLog*

2. Verify the values displayed are the values you configured.

 Pipeline tracing
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Pipeline tracing captures copies of email messages from a specific sender as they move through the Transport service
on Mailbox servers, the Mailbox Transport Delivery service on Mailbox servers, and through Edge Transport servers..
Pipeline tracing captures verbose information about the changes that each transport agent applies to messages in the
transport pipeline in message snapshot files. By examining the contents of the message snapshot files, you can
determine whether the transport agents have applied the changes to the messages in the transport pipeline that you
expected. If you are troubleshooting a problem, you should determine which transport agent is at fault. Then you can
focus your troubleshooting efforts on that agent to resolve the problem. You can then view the message snapshot files
again to verify that your solution is successful.

WARNING
Pipeline tracing copies the complete contents of email messages that are sent from the sender's email address. To avoid
unwanted exposure of confidential information, you need to set appropriate security permissions on the pipeline tracing
folder.
Don't enable pipeline tracing for long periods of time. Pipeline tracing creates files that can accumulate quickly. Always
monitor available disk space when pipeline tracing is enabled.

Configure pipeline tracing

Before you enable pipeline tracing, you need to specify the sender's email address you want to monitor. Pipeline
tracing is designed to log messages sent from a specific email address. The sender's email address can be internal or
external to your Exchange organization. Alternatively, you can enable pipeline tracing for system messages generated
by the transport service on the specified Mailbox or Edge Transport server, such as automatic replies, delivery status
notification (DSN ) messages, journal reports, and other system-generated messages You can also modify the location
of the pipeline tracing folder.
The parameters that you use to configure pipeline tracing are summarized in the following table

CMDLET PARAMETER DEFAULT VALUE DESCRIPTION

Set-TransportService PipelineTracingSenderAd Blank ( $null ) Specify the email address

dress of the sender you want
Set- to monitor.
MailboxTransportServi
ce Specify the value "<>" to
monitor system-
generated messages sent
by the specified transport
service on the server.
 CMDLET PARAMETER DEFAULT VALUE DESCRIPTION

Set-TransportService PipelineTracingPath Transport service The path must be on the

local server. UNC paths
%ExchangeInstallPath%TransportRoles\Logs\Hub\PipelineTracing
Set- aren't supported.
MailboxTransportServi Mailbox Transport
ce service The specified path
contains the
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\PipelineTracing
MessageSnapshots
folder where pipeline
tracing files are stored.

Set-TransportService PipelineTracingEnabled $false You can only enable

pipeline tracing for the
Set- specified transport
MailboxTransportServi service on the server
ce after you configure the
sender address you want
to monitor.

For more information about how to enable pipeline tracing and configure the sender address for pipeline tracing, see
Configure pipeline tracing.

Message snapshot files

Message snapshots are files that capture any changes made to a message by transport agents in the Transport service
or the Mailbox Transport Delivery service. These files are stored in the MessageSnapshots folder in the corresponding
pipeline tracing path for the transport service.
In the MessageSnapshots folder, Exchange creates one folder for each message sent by the monitored sender that flows
through the specified transport service. Each folder is named after a GUID that's assigned to the message. If you
enable pipeline tracing for the Transport service and the Mailbox Transport service on the same Mailbox server, a
different GUID is assigned to the same message by each transport service, so the folder name for a message in the
MessageSnapshots folder for the Transport service is different than the folder name for the same message in the
MessageSnapshots folder for the Mailbox Transport service. If you enable pipeline tracing on more than one Exchange
server, a different GUID is assigned to the same message as it travels through the specified transport service on each
Exchange server.
In each message folder, Exchange creates several message snapshot files that have .eml file extensions. These message
snapshot files contain the contents of the message as it encounters each SMTP event and transport agent.
If a transport agent is registered on an SMTP event, Exchange creates a message snapshot of the message before the
message encounters any transport agents. This gives you a copy of the message before the message encounters
transport agents that are registered on that event. Then, a new message snapshot is created for each transport agent
that the message encounters, regardless of whether a transport agent modifies the contents of the message. However,
if no agents are registered on an event, Exchange doesn't create any messages snapshots for that event.
For example, if three agents are registered on the OnEndofData event but only two of the transport agents modify a
message, four message snapshots are created. The first message snapshot captures the message as it encounters the
OnEndofData event before any modifications that are made by the transport agents that registered on that event.
Then, one message snapshot is created for each transport agent regardless of whether a transport agent modifies the
message.
The message snapshot files that are created are described in the following list:
Original.eml: This file contains the original unmodified contents of the email message before it encounters any
SMTP events or transport agents.
 Routingnnnn.eml: These files contain the contents of the email message as it encounters transport the SMTP
events and transport agents registered on those events in the categorization part of the Transport service. The
placeholder nnnn represents an integer value that starts with 0001 . The value is incremented for every SMTP
event and transport agent registered on those events in the order in which the events and agents act on the
message. The Mailbox Transport Delivery service doesn't generate these Routing snapshot files.
SmtpReceivennnn.eml: These files contain the contents of the email message as it encounters the
OnEndofData and OnEndOfHeaders SMTP events and transport agents registered on those events during
the SMTP receive part of the Transport service or the Mailbox Transport Delivery service. The placeholder nnnn
represents an integer value that starts with 0001 . The value is incremented for every SMTP event and
transport agent registered on those events in the order in which the events and agents act on the message.
You can open the message snapshot files by using Notepad or any text editor.
Each message snapshot file starts with headers that are added to the message contents and list the SMTP event and
transport agent that the message snapshot file relates to. These headers start with
X-CreatedBy: MessageSnapshot-Begin injected headers and end with
X-EndOfInjectedXHeaders: MessageSnapshot-End injected headers . These headers are replaced in each message snapshot
file by each subsequent transport agent and SMTP event. The following is an example of the headers that are added to
an email message file:

X-CreatedBy: MessageSnapshot-Begin injected headers

X-MessageSnapshot-UTC-Time: 2013-01-23T23:20:18.138Z
X-MessageSnapshot-Record-Id: 21474836486
X-MessageSnapshot-Source: OnSubmittedMessageX-Sender: [email protected]
X-Receiver: [email protected]
X-EndOfInjectedXHeaders: MessageSnapshot-End injected headers

After the message snapshot headers, the file contains the contents of the message including all the original message
headers. If a transport agent modifies the contents of the message, the changes appear integrated with the message.
As the message is processed by each transport agent, the changes that are made by each agent are applied to the
message contents. If a transport agent makes no changes to the message contents, the message snapshot that is
created by that agent will be identical to the message snapshot created by the previous transport agent.
 Configure pipeline tracing
6/7/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Pipeline tracing captures copies of email messages as they move through the transport pipeline in the Transport
service or the Mailbox Transport service on Mailbox server and on Edge Transport servers.

What do you need to know before you begin?

Estimated time to complete this procedure: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the"Transport Service" and "Mailbox Transport Service" entries in the Mail flow
permissions topic.
You can only use the Shell to perform this procedure.
Pipeline tracing copies the complete contents of email messages that are sent from the sender's email
address. To avoid unwanted exposure of confidential information, you need to set appropriate security
permissions on the location of the pipeline tracing folder.
Don't enable pipeline tracing for long periods of time. Pipeline tracing creates multiple message snapshot
files that accumulate quickly. Always monitor available disk space when pipeline tracing is enabled.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Enable and configure pipeline tracing

Step 1: Use the Shell to configure the pipeline tracing sender address
Use the following syntax to configure the pipeline tracing sender address.

<Set-TransportService | Set-MailboxTransportService> <ServerIdentity> -PipelineTracingSenderAddress

<SMTPAddress | "<>">

This example configures pipeline tracing to capture snapshots of all messages sent by the sender
[email protected] in the Transport service on the Mailbox server named Mailbox01.

Set-TransportService Mailbox01 -PipelineTracingSenderAddress [email protected]

This example configures pipeline tracing to capture snapshots of all the system-generated messages received by
the Transport service on the Mailbox server named Mailbox02.
 Set-TransportService Mailbox02 -PipelineTracingSenderAddress "<>"

WARNING
Configuring pipeline tracing to capture all server-generated messages in a transport service may place a significant load on
the server and may quickly consume available disk space. Always monitor available disk space when pipeline tracing is
enabled.

Step 2: (Optional) Use the Shell to specify a custom pipeline tracing

folder
The default pipeline tracing folder doesn't exist until after you enable pipeline tracing, and messages that meet the
criteria you specify using the PipelineTracingSenderAddress parameter flow through the transport service on the
server. For the Transport service on a Mailbox server, the default location is
%ExchangeInstallPath%TransportRoles\Logs\Hub\PipelineTracing . For the Mailbox Transport service on a Mailbox
server, the default location is %ExchangeInstallPath%TransportRoles\Logs\Mailbox\PipelineTracing . If you specify a
custom path, the path must be on the local Exchange server.
Use the following syntax to configure the pipeline tracing folder.

<Set-TransportService | Set-MailboxTransportService> <ServerIdentity> -PipelineTracingPath <LocalFilePath>

This example sets the pipeline tracing folder for the Transport service on the Mailbox server named Mailbox01 to
D:\Hub\Pipeline Tracing.

Set-TransportService Mailbox01 -PipelineTracingPath "D:\Hub\Pipeline Tracing"

Step 3: Use the Shell to enable pipeline tracing

By default, pipeline tracing is disabled on all Exchange servers. When you enable pipeline tracing, you are enabling
pipeline tracing in the specified transport service on the specified Exchange server only. Before you enable pipeline
tracing, you need to specify the sender address as described in Step 1.
Use the following syntax to enable pipeline tracing.

<Set-TransportService | Set-MailboxTransportService> <ServerIdentity> -PipelineTracingEnabled $true

This example enables pipeline tracing in the Transport service on the Mailbox server named Mailbox01.

Set-TransportService Mailbox01 -PipelineTracingEnabled $true

How do you know this worked?

To verify that you have successfully configured pipeline tracing, do the following:
1. Run the following command:

<Get-TransportService | Get-MailboxTransportService> <ServerIdentity> | Format-List PipelineTracing*

2. Verify the values displayed are the values you configured.
3. Check the pipeline tracing folder for the Transport service or the Mailbox Transport service, and verify
message snapshot files are being created in the folder.

Disable pipeline tracing

Because of the disk space and security concerns associated with pipeline tracing, pipeline tracing is a temporary
action for diagnostic or troubleshooting purposes. Whenever you enable pipeline tracing, always remember to
disable it when you are finished.
Use the following syntax to disable pipeline tracing.

<Set-TransportService | Set-MailboxTransportService> <ServerIdentity> -PipelineTracingEnabled $false

This example disables pipeline tracing in the Transport service on the Mailbox server named Mailbox01.

Set-TransportService Mailbox01 -PipelineTracingEnabled $false

How do you know this worked?

To verify that you have successfully disabled pipeline tracing, do the following:
1. Run the following command:

<Get-TransportService | Get-MailboxTransportService> <ServerIdentity> | Format-List

PipelineTracingEnabled

2. Verify the value of the PipelineTracingEnabled parameter is $false.

3. Check the pipeline tracing folder, and verify message snapshot files are no longer being created in the folder.
 Protocol logging
6/14/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Protocol logging records the SMTP conversations that occur between messaging servers as part of message
delivery. These SMTP conversations occur on Send connectors and Receive connectors that exist in the Front End
Transport service on Client Access servers, the Transport service on Mailbox servers, and the Mailbox Transport
service on Mailbox servers. You can use protocol logging to diagnose mail flow problems.
By default, protocol logging is disabled on all Send connectors and Receive connectors. Protocol logging is enabled
or disabled on each individual connector. Other protocol logging options are set for all the Receive connectors or
all the Send connectors that exist in each individual transport service on the server. All the Receive connectors in a
transport service share the same protocol log files and protocol log options. These protocol log files and protocol
log options are separate from the Send connector protocol log files and protocol log options in the transport
service on the same server.
The following options are available for the protocol logs of all Send connectors or all Receive connectors in each
transport service on the Exchange server:
Specify the location of the Send connector or the Receive connector protocol log files.
Specify a maximum size for the Send connector or the Receive connector protocol log files. The default size
is 10 megabytes (MB ).
Specify a maximum size for the directory that contains the Send connector or Receive connector protocol
log files. The default size is 250 MB.
Specify a maximum age for the Send connector or Receive connector protocol log files. The default age is
30 days.
By default, Exchange uses circular logging to limit the protocol logs based on file size and file age to help control
the hard disk space used by the log files.
A special Send connector named the intra-organization Send connector exists in the Transport service on every
Mailbox server, and in the Front End Transport service on every Client Access server. This connector is implicitly
created, invisible, and requires no management. The intra-organization Send connector is used by the following
transport services:
Transport service on Mailbox servers
Relays messages to the Transport service and the Mailbox Transport service on other Exchange 2013
Mailbox servers in the organization.
Relays messages to other Exchange 2007 or Exchange 2010 Hub Transport servers in the
organization.
Relays messages to Edge Transport servers in the perimeter network.
Front End Transport service on Client Access servers: Relays messages to the Transport service on
Exchange 2013 Mailbox servers in the organization.
An equivalent Send connector named the mailbox delivery Send connector exists in the Mailbox Transport service
on every Mailbox server. This connector is also implicitly created, invisible, and requires no management. The
mailbox delivery Send connector is used to relay messages to the Transport service and the Mailbox Transport
service on other Mailbox servers in the organization.
By default, protocol logging for the mailbox delivery Send connector is also disabled. You can enable or disable
protocol logging for the mailbox delivery Send connector by using the
MailboxDeliveryConnectorProtocolLoggingLevel parameter on the Set-MailboxTransportService cmdlet. If you
enable protocol logging for the mailbox delivery Send connector, logging occurs in the Send connector protocol
logs for the Mailbox Transport service on the Mailbox server.

Structure of the protocol log files

By default, the protocol log files exist in the following locations:
Receive connector protocol log files for the Transport service on Mailbox servers:
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
Receive connector protocol log files for the Mailbox Transport service on Mailbox servers:
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive
Receive connector protocol log files for the Front End Transport service on Client Access servers:
%ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
Send connector protocol log files for the Transport service on Mailbox servers:
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend
Send connector protocol log files for the Mailbox Transport service on Mailbox servers:
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend
Send connector protocol log files for the Front End Transport service on Client Access servers:
%ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
The naming convention for log files in each protocol log directory is prefixyyyymmdd -nnnn.log. The placeholders
represent the following information:
The placeholder prefix is SEND for Send connectors or RECV for Receive connectors.
The placeholder yyyymmdd is the Coordinated Universal Time (UTC ) date on which the log file was created.
The placeholder yyyy = year, mm = month, and dd = day.
The placeholder nnnn is an instance number that starts at the value of 1 for each day.
Information is written to the log file until the file size reaches its maximum specified value, and a new log file that
has an incremented instance number is opened. This process is repeated throughout the day. Circular logging
deletes the oldest log files when the protocol log directory reaches its maximum specified size, or when a log file
reaches its maximum specified age.
The protocol log files are text files that contain data in the comma-separated value file (CSV ) format. Each protocol
log file has a header that contains the following information:
#Software: Name of the software that created the protocol log file. Typically, the value is Microsoft
Exchange Server.
#Version: Version number of the software that created the protocol log file. Currently, the value is 15.0.0.0.
#Log-Type: Log type value of this field, which is either SMTP Receive Protocol Log or SMTP Send Protocol
Log.
#Date: UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601
date-time format: yyyy-mm -ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates the
beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z
signifies Zulu, which is another way to denote UTC.
 #Fields: Comma-delimited field names used in the protocol log files.

Information written to the protocol log

The protocol log stores each SMTP protocol event on a single line in the protocol log. The information stored on
each line is organized by fields. These fields are separated by commas. The following table describes the fields used
to classify each protocol.
Fields used to classify each protocol event
FIELD NAME DESCRIPTION

date-time UTC date-time of the protocol event. The UTC date-time

is represented in the ISO 8601 date-time format: yyyy-
mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month,
dd = day, T indicates the beginning of the time
component, hh = hour, mm = minute, ss = second, fff =
fractions of a second, and Z signifies Zulu, which is
another way to denote UTC.

connector-id Distinguished name (DN) of the connector associated with

the SMTP event.

session-id GUID that's unique for each SMTP session but is the same
for each event associated with that SMTP session.

sequence-number Counter that starts at 0 and is incremented for each event

in the same SMTP session.

local-endpoint Local endpoint of an SMTP session. This consists of an IP

address and TCP port number formatted as
<IP address>:<port>.

remote-endpoint Remote endpoint of an SMTP session. This consists of an

IP address and TCP port number formatted as
<IP address>:<port>.

event Single character that represents the protocol event. The

possible values for the event are as follows:
+ Connect
- Disconnect
> Send
< Receive
* Information

data Text information associated with the SMTP event.

 FIELD NAME DESCRIPTION

context Additional contextual information that may be associated

with the SMTP event.

A single SMTP conversation that represents the sending or receiving of a single email message generates multiple
SMTP events. These SMTP events cause multiple lines to be written to the protocol log. Multiple SMTP
conversations that represent the sending or receiving of multiple email messages can occur at the same time. This
creates protocol log entries from different SMTP conversations that are interspersed. You can use the session-id
and sequence-number fields to sort the protocol log entries by SMTP conversation.
 Configure protocol logging
6/11/2019 • 6 minutes to read • Edit Online

Applies to: Exchange Server 2013

Protocol logging records the SMTP conversations that occur on Send Connectors and Receive connectors as part
of message delivery.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport Service", "Front End Transport service", "Mailbox Transport
service", "Receive connectors" and "Send connectors" entries in the Mail flow permissions topic.
You can use the Exchange admin center (EAC ) to enable or disable protocol logging for Send connectors and
Receive connectors in the Transport service on Mailbox servers, and for Receive connectors in the Front End
Transport service on Client Access servers. You can also use the EAC to configure the protocol log paths for
the Transport service only. For all other protocol logging options, you need to use the Shell.
Protocol logging is enabled or disabled on each individual connector. All the Receive connectors on the
Exchange server share the same protocol log files and protocol log options. These protocol log settings are
separate from the Send connector protocol log files and protocol log options that are on the same server.
Don't perform this procedure on an Edge Transport server that has been subscribed to the Exchange
organization by using EdgeSync. Instead, make the changes in the Transport service on the Mailbox server.
The changes are then replicated to the Edge Transport server next time EdgeSync synchronization occurs.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure protocol logging

To use the EAC to enable or disable protocol logging on a Send connector or a Receive connector in the Transport
service on a Mailbox server, or on a Receive connector in the Front End Transport service on a Client Access server,
do the following:
1. In the EAC, navigate to Mail flow > Send connectors or Mail flow > Receive connectors.
2. Select the connector you want to configure, and then click Edit .
3. On the General tab in the Protocol logging level section, select one of the following options:
None: Protocol logging disabled on the connector.
Verbose: Protocol logging is enabled on the connector.
When you are finished, click Save.
To use the EAC to configure the protocol log paths for the Send connectors and Receive connectors in the
Transport service on a Mailbox server, do the following:
1. In the EAC, navigate to Servers > Servers.
2. Select the Mailbox server you want to configure, and then click Edit .
3. On the server properties page, click Transport logs.
4. In the Protocol log section, change any of the following settings:
Send protocol log path: The value you specify must be on the local Exchange server. If the folder
doesn't exist, it will be created for you when you click Save.
Receive protocol log path: The value you specify must be on the local Exchange server. If the folder
doesn't exist, it will be created for you when you click Save.
When you are finished, click Save.

How do you know this worked?

To verify that you have successfully used the EAC to configure the protocol log settings, do the following:
1. Browse to the location you specified for the Send connector or the Receive connector protocol logs.
2. If you enabled protocol logging, verify a log file is created. If you disabled protocol logging, verify the latest
log file is no longer being updated.

Use the Shell to enable or disable protocol logging on a Send

connector or a Receive connector
To enable or disable protocol logging on a Send connector or a Receive connector, run the following command:

<Set-SendConnector |Set-ReceiveConnector> <ConnectorIdentity> -ProtocolLoggingLevel <Verbose | None>

This example enables protocol logging for the Receive connector named Connection from Contoso.com.

Set-ReceiveConnector "Connection from Contoso.com" -ProtocolLoggingLevel Verbose

How do you know this worked?

To verify that you have successfully enabled or disabled protocol logging, do the following:
1. In the Shell, run the following command:

<Get-SendConnector |Get-ReceiveConnector> | Format-List Name,ProtocolLoggingLevel

2. Verify the values displayed are the values you configured.

Use the Shell to enable or disable protocol logging on the intra-

organization Send connector
To enable or disable protocol logging on the implicit and invisible intra-organization Send connector that exists in
the Transport service on a Mailbox server and in the Front End Transport service on a Client Access server, run the
following command:
 <Set-TransportService | Set-FrontEndTransportService> -IntraOrgConnectorProtocolLoggingLevel <Verbose | None>

This example enables protocol logging on the intra-organization Send connector in the Transport service on a
Mailbox server named Mailbox01.

Set-TransportService Mailbox01 -IntraOrgConnectorProtocolLoggingLevel Verbose

How do you know this worked?

To verify that you have successfully enabled or disabled protocol logging on the intra-org Send connector, do the
following:
1. In the Shell, run the following command:

<Get-TransportService | Get-FrontEndTransportService> <ServerIdentity> | Format-List

IntraOrgConnectorProtocolLoggingLevel

2. Verify the value displayed is the value you configured.

Use the Shell to enable or disable protocol logging on the mailbox

delivery Send connector
To enable or disable protocol logging on the implicit and invisible mailbox delivery Send connector that exists in
the Mailbox Transport service on a Mailbox server, run the following command:

Set-MailboxTransportService -MailboxDeliveryConnectorProtocolLoggingLevel <Verbose | None>

This example enables protocol logging on the mailbox delivery Receive connector in the Mailbox Transport service
on a Mailbox server named Mailbox01.

Set-MailboxTransportService Mailbox01 -MailboxDeliveryConnectorProtocolLoggingLevel Verbose

How do you know this worked?

To verify that you have successfully enabled or disabled protocol logging on the mailbox delivery connector, do the
following:
1. In the Shell, run the following command:

Get-MailboxTransportService <ServerIdentity> | Format-List MailboxDeliveryConnectorProtocolLoggingLevel

2. Verify the value displayed is the value you configured.

Use the Shell to configure protocol logging settings

To configure the protocol log settings, run the following command:
 <Set-TransportService | Set-MailboxTransportService | Set-FrontEndTransportService> <ServerIdentity> -
ReceiveProtocolLogPath <LocalFilePath> -SendProtocolLogPath <LocalFilePath> -ReceiveProtocolLogMaxFileSize
<Size> -SendProtocolLogMaxFileSize <Size> -ReceiveProtocolLogMaxDirectorySize <Size> -
SendProtocolLogMaxDirectorySize <Size> -ReceiveProtocolLogMaxAge <dd.hh:mm:ss> -SendProtocolLogMaxAge
<dd.hh:mm:ss>

This example sets the following protocol log settings in the Transport service on the Mailbox server named
Mailbox01:
Sets the location of all Receive connector protocol logs to D:\Hub Receive SMTP Log and all Send connector
protocol logs to D:\Hub Send SMTP Log. Note that if the folder doesn't exist, it will be created for you.
Sets the maximum size of a Receive connector protocol log file and a Send connector protocol log file to
20 MB.
Sets the maximum size of the Receive connector protocol log folder and the Send connector protocol log
folder to 400 MB.
Sets the maximum age of a Receive connector protocol log file and a Send Connector protocol log file to
45 days.

Set-TransportService Mailbox01 -ReceiveProtocolLogPath "D:\Hub Receive SMTP Log" -SendProtocolLogPath "D:\Hub

Send SMTP Log" -ReceiveProtocolLogMaxFileSize 20MB -SendProtocolLogMaxFileSize 20MB -
ReceiveProtocolLogMaxDirectorySize 400MB -SendProtocolLogMaxDirectorySize 400MB -ReceiveProtocolLogMaxAge
45.00:00:00 -SendProtocolLogMaxAge 45.00:00:00

NOTE
To configure the protocol log settings in the Mailbox Transport service on a Mailbox server, use the Set-
MailboxTransportService cmdlet. To configure the protocol log settings in the Front End Transport service on a
Client Access server, use the Set-FrontEndTransportService cmdlet.
Setting the SendProtocolLogPath or ReceiveProtocolLogPath parameters to the value $null effectively disables
protocol logging for all Send connectors or all Receive connectors on the server. However, setting either of these
parameters to $null when protocol logging is enabled for any other connectors on the server, including the intra-
organization Send connector or the mailbox delivery Send connector, event log errors are generated.
Setting the ReceiveProtocolLogMaxAge or SendProtocolLogMaxAge parameters to the value 00:00:00 prevents the
automatic removal of protocol log files because of their age.

How do you know this worked?

To verify that you have successfully configured the protocol log settings, do the following:
1. In the Shell, run the following command:

<Get-TransportService | Get-MailboxTransportService | Get-FrontEndTransportService> <ServerIdentity> |

Format-List SendConnectorProtocolLog*,ReceiveConnectorProtocolLog*

2. Verify the values displayed are the values you configured.

 Configure routing table logging
6/14/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

Routing table logging periodically records a snapshot of the routing table used by Microsoft Exchange Server 2013
to route messages to their destinations.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport service" and "Edge Transport server" entries in the Mail flow
permissions topic.
You can only use the Shell to perform this procedure.
To configure the time interval for automatic recalculation of the routing table, you modify the
EdgeTransport.exe.config XML application configuration file. Changes you save to this file are applied after
you restart the Microsoft Exchange Transport service. When you restart this service, mail flow on the server
is temporarily interrupted.
Any customized per-server settings you make in Exchange XML application configuration files, for example,
web.config files on Client Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be
overwritten when you install an Exchange Cumulative Update (CU ). Make sure that you save this
information so you can easily re-configure your server after the install. You must re-configure these settings
after you install an Exchange CU.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure routing table logging

Run the following command:

Set-TransportService <ServerIdentity> -RoutingTableLogMaxAge <dd.hh:mm:ss> -RoutingTableLogMaxDirectorySize

<Size> -RoutingTableLogPath <LocalFilePath>

This example sets the following routing table log settings on the Mailbox server named Mailbox01:
Sets the location of the routing table log files to D:\Routing Table Log. Note that if the folder doesn't exist, it
will be created for you.
Sets the maximum size of the routing table log folder to 70 MB.
Sets the maximum age of a routing table log file to 45 days.
 Set-TransportService Mailbox01 -RoutingTableLogPath "D:\Routing Table Log" -RoutingTableLogMaxDirectorySize
70MB -RoutingTableLogMaxAge 45.00:00:00

NOTE
Setting the RoutingTableLogMaxAge parameter to the value 00:00:00 prevents the automatic removal of routing table log
files because of their age.

How do you know this worked?

To verify that you have successfully configured routing table logging, do the following:
1. In the Shell, run the following command:

Get-TransportService <ServerIdentity> | Format-List RoutingTableLog*

2. Verify the values displayed are the values you configured.

Use the Command Prompt to configure the interval for automatic

recalculation of the routing table in the EdgeTransport.exe.config file
1. In a Command prompt window, open the EdgeTransport.exe.config application configuration file in Notepad
by running the following command:

Notepad %ExchangeInstallPath%Bin\EdgeTransport.exe.config

2. Modify the following key in the <appSettings> section.

<add key="RoutingConfigReloadInterval" value="<hh:mm:ss>" />

For example, to change the interval for automatic recalculation of the routing table to 10 hours, use the
following value:

<add key="RoutingConfigReloadInterval" value="10:00:00" />

3. When you are finished, save and close the EdgeTransport.exe.config file.
4. Restart the Microsoft Exchange Transport service by running the following command:

net stop MSExchangeTransport && net start MSExchangeTransport

How do you know this worked?

To verify that you have successfully configured the interval for the automatic recalculation of the routing table,
verify the routing table log is updated during the time interval you specified.
Note that the routing table will be recalculated and logged earlier than the value specified by the
RoutingConfigReloadInterval key if any of the following conditions occur:
A routing configuration change is detected. For example, a Send connector or a Receive connector is added,
removed, or modified, or the 6 hour Kerberos token renewal occurs.
The Microsoft Exchange Transport service is started.
 Message tracking
6/14/2019 • 16 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, the message tracking log is a detailed record of all message activity as
messages are transferred to and from the Transport service on Mailbox servers, mailboxes on Mailbox servers,
and Edge Transport servers. You can use message tracking logs for message forensics, mail flow analysis,
reporting, and troubleshooting.
In Exchange 2013, you can use the Set-TransportService cmdlet or the Set-MailboxServer cmdlet for all
message tracking configuration tasks, because the Exchange 2013 Mailbox server holds the Transport service and
the mailboxes. You can use either of these cmdlets to make the following message tracking configuration changes:
Enable or disable message tracking. The default is enabled.
Specify the location of the message tracking log files.
Specify a maximum size for the individual message tracking log files. The default is 10 MB.
Specify a maximum size for the directory that contains the message tracking log files: The default is
1000 MB.
Specify maximum age for the message tracking log files: The default is 30 days.
Enable or disable message subject logging in the message tracking logs. The default is enabled.

NOTE
You can also use the Exchange admin center (EAC) to enable or disable message tracking, and to specify the location of the
message tracking log files.

By default, Exchange uses circular logging to limit the message tracking logs based on file size and file age to help
control the hard disk space used by the message tracking log files.

Search the message tracking log

Message tracking logs contain vast amounts of data as messages move through an Exchange 2013 Mailbox
server. When it comes to searching the message tracking logs, you have different options.
Get-MessageTrackingLog: Administrators can use this cmdlet to search the message tracking log for
information about messages using a wide range of filter criteria. For more information, see Search message
tracking logs.
Delivery reports for administrators: Administrators can use the Delivery reports tab in the Exchange
admin center (EAC ) or the underlying Search-MessageTrackingReport and Get-
MesageTrackingReport cmdlets to search the message tracking logs for information about messages sent
by or received by a specific mailbox in the organization. For more information see Delivery reports for
administrators.
Delivery reports for users: Users can use the Delivery reports tab in Outlook Web App to search the
message tracking logs for information about messages sent to or sent by their own mailbox. For more
information, see Delivery Reports for Users.
Structure of the message tracking log files
By default, the message tracking log files exist in %ExchangeInstallPath%TransportRoles\Logs\MessageTracking.
The naming convention for log files in the message tracking log directory is MSGTRK yyyymmdd -nnnn .log ,
MSGTRKMA yyyymmdd -nnnn .log , MSGTRKMD yyyymmdd -nnnn .log , and MSGTRKMS yyyymmdd -nnnn .log . The
different logs are used by the following services:
MSGTRK: These logs are associated with the Transport service.
MSGTRKMA: These logs are associated with the approvals and rejections used by moderated transport.
For more information, see Manage message approval.
MSGTRKMD: These logs are associated with messages delivered to mailboxes by the Mailbox Transport
Delivery service.
MSGTRKMS: These logs are associated with messages sent from mailboxes by the Mailbox Transport
Submission service.
The placeholders in the log file names represent the following information:
The placeholder yyyymmdd is the coordinated universal time (UTC ) date on which the log file was created.
yyyy = year, mm = month, and dd = day.
The placeholder nnnn is an instance number that starts at the value of 1 daily for each message tracking log
file name prefix.
Information is written to each log file until the file size reaches its maximum specified value for each log file. Then,
a new log file that has an incremented instance number is opened. This process is repeated throughout the day.
The log file rotation functionality deletes the oldest log files when either of the following conditions is true:
A log file reaches its maximum specified age.
The message tracking log directory reaches its maximum specified size.

IMPORTANT
The maximum size of the message tracking log directory is calculated as the total size of all log files that have the
same name prefix. Other files that do not follow the name prefix convention are not counted in the total directory
size calculation. Renaming old log files or copying other files into the message tracking log directory could cause the
directory to exceed its specified maximum size.
On Exchange 2013 Mailbox servers, the maximum size of the message tracking log directory is three times the
specified value. Although the message tracking log files that are generated by the four different services have four
different name prefixes, the amount and frequency of data written to the MSGTRKMA log files is negligible
compared to the three other log file prefixes.

The message tracking log files are text files that contain data in the comma-separated value (CSV ) format. Each
message tracking log file has a header that contains the following information:
#Software:: Name of the software that created the message tracking log file. Typically, the value is
Microsoft Exchange Server.
#Version:: Version number of the software that created the message tracking log file. Currently, the value is
15.0.0.0.
#Log-Type:: Log type value, which is Message Tracking Log.
#Date:: The UTC date-time when the log file was created. The UTC date-time is represented in the ISO
8601 date-time format: yyyy-mm -ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates
 the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and
Z signifies Zulu, which is another way to denote UTC.
#Fields:: Comma-delimited field names used in the message tracking log files.

Fields in the message tracking log files

The message tracking log stores each message event on a single line in the log. The message event information is
organized by fields, and these fields are separated by commas. The field name is generally descriptive enough to
determine the type of information that it contains. However, some fields may be blank, or the type of information
that is stored in the field may change based on the message event type and the type of message tracking log file
where the event was recorded. General descriptions of the fields that are used to classify each message tracking
event are explained in the following table.

FIELD NAME DESCRIPTION

date-time The UTC date-time of the message tracking event. The

UTC date-time is represented in the ISO 8601 date-time
format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year,
mm = month, dd = day, T indicates the beginning of the
time component, hh = hour, mm = minute, ss = second,
fff = fractions of a second, and Z signifies Zulu, which is
another way to denote UTC.

client-ip The IPv4 or IPv6 address of the messaging server or

messaging client that submitted the message.

client-hostname The host name or FQDN of the messaging server or

messaging client that submitted the message.

server-ip The IPv4 or IPv6 address of the source or destination

Exchange server.

server-hostname The host name or FQDN of the destination server.

source-context Extra information associated with the source field. For

example, transport agent information.

connector-id The name of the source or destination Send connector or

Receive connector. For example,
ServerName\ConnectorName or ConnectorName.

source The Exchange transport component responsible for the

message tracking event. The values found in this field are
described in the Source values in the message tracking
log section later in this topic.

event-id The message event type. The event types are described in
the Event types in the message tracking log section later
in this topic.
FIELD NAME DESCRIPTION

internal-message-id A message identifier assigned by the Exchange server

currently processing the message.
A specific message's value of internal-message-id is
different in the message tracking log of every Exchange
server that's involved in the transmission of the message.
An example value is 73014444033 .

message-id The value of the Message-Id: header field found in the

message header. If the Message-Id: header field does not
exist or is blank, an arbitrary value is assigned. This value
is constant for the lifetime of the message. For messages
created in Exchange, the value is in the format
<GUID@ServerFQDN> , including the angle brackets ( < >
). For example,
<[email protected]>
. Other messaging systems may use different syntax or
values.

network-message-id A unique message ID value that persists across copies of

the message that may be created due to bifurcation or
distribution group expansion. An example value is
1341ac7b13fb42ab4d4408cf7f55890f .

recipient-address The email addresses of the message's recipients. Multiple

email addresses are separated by the semicolon character
(;).

recipient-status This field contains the recipient status for each recipient
separated by the semicolon character (;). The status values
are presented for the recipients in the same order as the
values in the recipient-address field. Example status
values include 250 2.1.5 Recipient OK or
550 4.4.7 QUEUE.Expired;<ErrorText> .

total-bytes The size of the message that includes attachments, in

bytes.

recipient-count The number of recipients in the message.

related-recipient-address This field is used with EXPAND, REDIRECT, and RESOLVE

events to display other recipient email addresses
associated with the message.
FIELD NAME DESCRIPTION

reference This field contains additional information for specific types

of events. For example:
DSN Contains the report link, which is the Message-Id
value of the associated delivery status notification (DSN) if
a DSN is generated subsequent to this event. If this is a
DSN message, the Reference field contains the
Message-Id value of the original message for which this
DNS was generated.
EXPAND The Reference field contains the related-
recipient-address value of the related messages.
RECEIVE The Reference field may contain the Message-
Id value of the related message if the message was
generated by other processes, for example, journaling or
Inbox rules.
SEND The Reference field contains the Internal-
Message-Id value of any DSN messages.
THROTTLE The Reference field contains the reason why
the message was throttled.
TRANSFER The Reference field contains the Internal-
Message-Id of the message that is being forked.
For messages generated by inbox rules, the Reference
field contains the Internal-Message-Id value of the
inbound message that caused the inbox rule to generate
the outbound message.
For other types of events, the Reference field may
contain the Internal-Message-Id value for forked
messages.
For other types of events, the Reference field is usually
blank.

message-subject The message's subject found in the Subject: header

field. The tracking of message subjects is controlled by the
MessageTrackingLogSubjectLoggingEnabled parameter in
the Set-TransportService or Set-MailboxServer
cmdlets. By default, message subject tracking is enabled.

sender-address The email address specified in the Sender: header field,

or the From: header field if Sender: is not present.

return-path The return email address specified by MAIL FROM: in the

message envelope. Although this field is never empty, it
can have the null sender address value represented as
<> .
 FIELD NAME DESCRIPTION

message-info Additional information about the message. For example:

The message origination UTC date-time for
DELIVER and SEND events. The origination date-
time is the time when the message first entered
the Exchange organization. The UTC date-time is
represented in the ISO 8601 date-time format:
yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year,
mm = month, dd = day, T indicates the beginning
of the time component, hh = hour, mm = minute,
ss = second, fff = fractions of a second, and Z
signifies Zulu, which is another way to denote
UTC.
Authentication errors. For example you may see
the value 11a and the type of authentication
used when authentication errors occur.

directionality The direction of the message. Example values include

Incoming , Undefined , and Originating .

tenant-id This field isn't used in on-premises Exchange 2013

organizations.

original-client-ip The IPv4 or IPv6 address of the original client.

original-server-ip The IPv4 or IPv6 address of the original server.

custom-data This field contains data related to a specific event types.

For example, the Transport Rule agent uses this field to
record the GUID of the transport rule or DLP policy that
acted on the message. For more information about these
Transport Rule agent values, see the "Data logging"
section in the View DLP policy detection reports topic,

Event types in the message tracking log

Various event types in the event-id field are used to classify the message events in the message tracking log.
Some message events appear in only one type of message tracking log file, and some message events appear in
all types of message tracking log files. The events types that are used to classify each message event are explained
in the following table.

EVENT NAME DESCRIPTION

AGENTINFO This event is used by transport agents to log custom

data.

BADMAIL A message submitted by the Pickup directory or the

Replay directory that can't be delivered or returned.
EVENT NAME DESCRIPTION

DEFER Message delivery was delayed.

DELIVER A message was delivered to a local mailbox.

DROP A message was dropped without a delivery status

notification (also known as a DSN, bounce message, non-
delivery report, or NDR). For example:
Completed moderation approval request
messages.
Spam messages that were silently dropped
without an NDR.

DSN A delivery status notification (DSN) was generated.

DUPLICATEDELIVER A duplicate message was delivered to the recipient.

Duplication may occur if a recipient is a member of
multiple nested distribution groups. Duplicate messages
are detected and removed by the information store.

DUPLICATEEXPAND During the expansion of the distribution group, a

duplicate recipient was detected.

DUPLICATEREDIRECT An alternate recipient for the message was already a

recipient.

EXPAND A distribution group was expanded.

FAIL Message delivery failed. Sources include SMTP, DNS,

QUEUE, and ROUTING.

HADISCARD A shadow message was discarded after the primary copy

was delivered to the next hop. For more information, see
Shadow redundancy.

HARECEIVE A shadow message was received by the server in the local

database availability group (DAG) or Active Directory site.

HAREDIRECT A shadow message was created.

HAREDIRECTFAIL A shadow message failed to be created. The details are

stored in the source-context field.
EVENT NAME DESCRIPTION

INITMESSAGECREATED A message was sent to a moderated recipient, so the

message was sent to the arbitration mailbox for approval.
For more information, see Manage message approval.

LOAD A message was successfully loaded at boot.

MODERATIONEXPIRE A moderator for a moderated recipient never approved or

rejected the message, so the message expired. For more
information about moderated recipients, see Manage
message approval.

MODERATORAPPROVE A moderator for a moderated recipient approved the

message, so the message was delivered to the moderated
recipient.

MODERATORREJECT A moderator for a moderated recipient rejected the

message, so the message wasn't delivered to the
moderated recipient.

MODERATORSALLNDR All approval requests sent to all moderators of a

moderated recipient were undeliverable, and resulted in
non-delivery reports (NDRs).

NOTIFYMAPI A message was detected in the Outbox of a mailbox on

the local server.

NOTIFYSHADOW A message was detected in the Outbox of a mailbox on

the local server, and a shadow copy of the message needs
to be created.

POISONMESSAGE A message was put in the poison message queue or

removed from the poison message queue.

PROCESS The message was successfully processed.

PROCESSMEETINGMESSAGE A meeting message was processed by the Mailbox

Transport Delivery service.

RECEIVE A message was received by the SMTP receive component

of the transport service or from the Pickup or Replay
directories (source: SMTP ), or a message was submitted
from a mailbox to the Mailbox Transport Submission
service (source: STOREDRIVER ).
EVENT NAME DESCRIPTION

REDIRECT A message was redirected to an alternative recipient after

an Active Directory lookup.

RESOLVE A message's recipients were resolved to a different email

address after an Active Directory lookup.

RESUBMIT A message was automatically resubmitted from Safety

Net. For more information, see Safety Net.

RESUBMITDEFER A message resubmitted from Safety Net was deferred.

RESUBMITFAIL A message resubmitted from Safety Net failed.

SEND A message was sent by SMTP between transport services.

SUBMIT The Mailbox Transport Submission service successfully

transmitted the message to the Transport service. For
SUBMIT events, the source-context property contains
the following details:
MDB The mailbox database GUID.
Mailbox The mailbox GUID.
Event The event sequence number.
MessageClass The type of message. For
example, IPM.Note .
CreationTime Date-time of the message
submission.
ClientType For example, User , OWA ,or
ActiveSync .

SUBMITDEFER The message transmission from the Mailbox Transport

Submission service to the Transport service was deferred.

SUBMITFAIL The message transmission from the Mailbox Transport

Submission service to the Transport service failed.

SUPPRESSED The message transmission was suppressed.

THROTTLE The message was throttled.

TRANSFER Recipients were moved to a forked message because of

content conversion, message recipient limits, or agents.
Sources include ROUTING or QUEUE.
Source values in the message tracking log
The values in the source field in the message tracking log indicate the transport component that's responsible for
the message tracking event. The following table describes the values of the source field.

SOURCE VALUE DESCRIPTION

ADMIN The event source was human intervention. For example,

an administrator used Queue Viewer to delete a message,
or submitted message files using the Replay directory.

AGENT The event source was a transport agent.

APPROVAL The event source was the approval framework that's used
with moderated recipients. For more information, see
Manage message approval.

BOOTLOADER The event source was unprocessed messages that exist on

the server at boot time. This is related to the LOAD event
type.

DNS The event source was DNS.

DSN The event source was a delivery status notification (DSN).

For example, a non-delivery report (NDR).

GATEWAY The event source was a Foreign connector. For more

information, see Foreign connectors.

MAILBOXRULE The event source was an Inbox rule. For more

information, see Inbox rules.

MEETINGMESSAGEPROCESSOR The event source was the meeting message processor,

which updates calendars based on meeting updates.

ORAR The event source was an Originator Requested Alternate

Recipient (ORAR). You can enable or disable support for
ORAR on Receive connectors using the OrarEnabled
parameter on the New-ReceiveConnector or Set-
ReceiveConnector cmdlets.

PICKUP The event source was the Pickup directory. For more
information, see Pickup directory and Replay directory .

POISONMESSAGE The event source was the poison message identifier. For
more information about poison messages and the poison
message queue, see Queues
 SOURCE VALUE DESCRIPTION

PUBLICFOLDER The event source was a mail-enabled public folder.

QUEUE The event source was a queue.

REDUNDANCY The event source was Shadow Redundancy. For more

information, see Shadow redundancy.

ROUTING The event source was the routing resolution component

of the categorizer in the Transport service.

SAFETYNET The event source was Safety Net. For more information,
see Safety Net.

SMTP The message was submitted by the SMTP send or SMTP

receive component of the transport service.

STOREDRIVER The event source was a MAPI submission from a mailbox

on the local server.

Example entries in the message tracking log

An uneventful message sent between two users generates several entries in the message tracking log. You can see
the results using the Get-MessageTrackingLog cmdlet. For more information, see Search message tracking logs.
This is a condensed example of the message tracking log entries created when the user [email protected]
successfully sends a test message to the user [email protected]. Both users have mailboxes on the same
server.

EventId Source Sender Recipients MessageSubject

------- ------ ------ ---------- --------------
NOTIFYMAPI STOREDRIVER {}
RECEIVE STOREDRIVER [email protected] {[email protected]} test
SUBMIT STOREDRIVER [email protected] {[email protected]} test
HAREDIRECT SMTP [email protected] {[email protected]} test
RECEIVE SMTP [email protected] {[email protected]} test
AGENTINFO AGENT [email protected] {[email protected]} test
SEND SMTP [email protected] {[email protected]} test
DELIVER STOREDRIVER [email protected] {[email protected]} test

Security concerns for the message tracking log

No message content is stored in the message tracking log. By default, the subject line of an email message is
stored in the message tracking log. You may want to disable message subject logging to comply with increased
security or privacy requirements. Before you enable or disable message subject logging, make sure that you verify
your organization's policy about revealing subject line information. For more information, see Configure message
tracking.
 Configure message tracking
6/11/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Message tracking records the SMTP transport activity of all messages transferred to and from the Transport
service or mailboxes on a Microsoft Exchange Server 2013 Mailbox server. You can use message tracking logs for
message forensics, mail flow analysis, reporting, and troubleshooting.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport service" entries in the Mail flow permissions topic or the "Mailbox
server configuration" entry in the Recipients Permissions topic.
You can use the Exchange admin center (EAC ) to enable or disable message tracking, or set the message
tracking log path. For all other message tracking options, you need to use the Exchange Management Shell.
On an Exchange 2013 Mailbox server, you can use either the Set-TransportService or the Set-
MailboxServer cmdlet to configure the message tracking options. The procedures in this topic use the Set-
TransportService cmdlet.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to configure message tracking on Mailbox servers

1. In the EAC, navigate to Servers > Servers.
2. Select the Mailbox server you want to configure, and then click Edit .
3. On the server properties page, click Transport Logs.
4. In the Message tracking log section, change any of the following:
Enable message tracking log: To disable message tracking on the server, clear the check box. To
enable message tracking on the server, select the check box.
Message tracking log path: The value you specify must be on the local Exchange server. If the
folder doesn't exist, it will be created for you when you click Save.
5. Click Save.

Use the Shell to configure message tracking

To configure message tracking, run the following command:
 Set-TransportService <ServerIdentity> -MessageTrackingLogEnabled <$true | $false> -MessageTrackingLogMaxAge
<dd.hh:mm:ss> -MessageTrackingLogMaxDirectorySize <Size> -MessageTrackingLogMaxFileSize <Size> -
MessageTrackingLogPath <LocalFilePath> -MessageTrackingLogSubjectLoggingEnabled <$true|$false>

This example sets the following message tracking log settings on the Mailbox server named Mailbox01:
Sets the location of the message tracking log files to D:\Message Tracking Log. Note that if the folder
doesn't exist, it will be created for you.
Sets the maximum size of a message tracking log file to 20 MB.
Sets the maximum size of the message tracking log directory to 1.5 GB.
Sets the maximum age of a message tracking log file to 45 days.

Set-TransportService Mailbox01 -MessageTrackingLogPath "D:\Hub Message Tracking Log" -

MessageTrackingLogMaxFileSize 20MB -MessageTrackingLogMaxDirectorySize 1.5GB -MessageTrackingLogMaxAge
45.00:00:00

NOTE
Setting the MessageTrackingLogPath parameter to the value $null , effectively disables message tracking. However,
if the value of the MessageTrackingLogEnabled parameter is $true , event log errors are generated.
Setting the MessageTrackingLogMaxAge parameter to the value 00:00:00 prevents the automatic removal of
message tracking log files because of their age.
On Exchange 2013 Mailbox servers, the maximum size of the message tracking log directory is three times the value
of the MessageTrackingLogMaxDirectorySize parameter. Although the message tracking log files that are generated
by the four different services have four different name prefixes, the amount and frequency of data written to the
MSGTRKMA log files is negligible compared to the three other log file prefixes. For more information, see the
"Structure of the message tracking log files" section in the Message tracking topic.

This example disables message subject logging in the message tracking log on the Mailbox server named
Mailbox01:

Set-TransportService Mailbox01 -MessageTrackingLogSubjectLoggingEnabled $false

This example disables message tracking on the Mailbox server named Mailbox01:

Set-TransportService Mailbox01 -MessageTrackingLogEnabled $false

How do you know this worked?

To verify that you have successfully configured message tracking, do the following:
1. In the Shell, run the following command:

Get-TransportService <ServerIdentity> | Format-List MessageTrackingLog*

2. Verify that the values displayed are the values you configured.
 Search message tracking logs
6/11/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, the message tracking log is a detailed record of all message activity as
messages are transferred to and from the Transport service on Mailbox servers, mailboxes on Mailbox servers,
and Edge Transport servers.
You can use the Get-MessageTrackingLog cmdlet in the Exchange Management Shell to search for entries in the
message tracking log by using specific search criteria.

What do you need to know before you begin?

Estimated time to complete: 30 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Message tracking" entry in the Mail flow permissions topic.
Searching the message tracking logs requires the Microsoft Exchange Transport Log Search service to be
running. If you disable or stop this service, you can't search the message tracking logs or run delivery
reports. However, stopping this service does not affect other features in Exchange.
The field names displayed by the results from the Get-MessageTrackingLog cmdlet are similar to the
actual field names used in the message tracking logs. The biggest differences are:
The dashes are removed from the field names. For example internal-message-id is displayed as
InternalMessageId .

The date-time field is displayed as Timestamp .

The recipient-address field is displayed as Recipients .
The sender-address field is displayed as Sender .
The date-time field in the message tracking log stores information in Coordinated Universal Time (UTC ).
However, you should enter your date-time search criteria for the Start or End parameters in the regional
date-time format of the computer that you are using to perform the search.
You can't copy the message tracking log files from another Exchange server and then search them by using
the Get-MessageTrackingLog cmdlet. Also, if you manually save an existing message tracking log file, the
change in the file's date-time stamp breaks the query logic that Exchange uses to search the message
tracking logs.
The Exchange 2013 Get-MessageTrackingLog cmdlet is able to search the message tracking logs on
Exchange 2007 and Exchange 2010 servers in the same Active Directory site.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.
Use the Shell to search the message tracking logs
To search the message tracking log entries for specific events, use the following syntax.

Get-MessageTrackingLog [-Server <ServerIdentity.] [-ResultSize <Integer> | Unlimited] [-Start <DateTime>] [-

End <DateTime>] [-EventId <EventId>] [-InternalMessageId <InternalMessageId>] [-MessageId <MessageId>] [-
MessageSubject <Subject>] [-Recipients <RecipientAddress1,RecipientAddress2...>] [-Reference <Reference>] [-
Sender <SenderAddress>]

To view the 1000 most recent message tracking log entries on the server, run the following command:

Get-MessageTrackingLog

This example searches the message tracking logs on the local server for all entries from 3/28/2013 8:00 AM to
3/28/2013 5:00 PM for all FAIL events where the message sender was [email protected].

Get-MessageTrackingLog -ResultSize Unlimited -Start "3/28/2013 8:00AM" -End "3/28/2013 5:00PM" -EventId "Fail"
-Sender "[email protected]"

Use the Shell to control the output of a message tracking log search
Use the following syntax.

Get-MessageTrackingLog <SearchFilters> | <Format-Table | Format-List> [<FieldNames>] [<OutputFileOptions>]

This example searches the message tracking logs using the following search criteria:
Return results for the first 1,000 Send events.
Display the results in the list format.
Display only those field names that begin with Send or Recipient .
Write the output to a new file named D:\Send Search.txt

Get-MessageTrackingLog -EventId Send | Format-List Send*,Recipient* > "D:\Send Search.txt"

Use the Shell to search the message tracking logs for message entries
on multiple servers
Typically, the value in the MessageID: header field remains constant as the message travels throughout the
Exchange organization. This property is named InternetMessageId in queue viewing utilities, and MessageId in
the message tracking log viewing utilities. After you have determined the MessageID: value of a specific message,
you can search for information about that message in the message tracking logs on every Mailbox server in your
Exchange organization.
To search all message tracking log entries for a specific message across all Mailbox servers, use the following
syntax.

Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isMailboxServer -eq $true} | Get-
MessageTrackingLog -MessageId <MessageID> | Select-Object <CommaSeparatedFieldNames> | Sort-Object -Property
<FieldName>
This example searches the message tracking logs on all Exchange 2013 Mailbox servers using the following search
criteria:
Find any entries related to a message that has a MessageID: value of
<[email protected]> . Note that you can omit the angle bracket
characters ( < > ). If you don't, you need to enclose the entire MessageID: value in quotation marks.
For each entry, display the fields date-time, server-hostname, client-hostname, source, event-id, and
recipient-address.
Sort the results by the date-time field.

Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isMailboxServer -eq $true} | Get-
MessageTrackingLog -MessageId [email protected] | Select-Object
Timestamp,ServerHostname,ClientHostname,Source,EventId,Recipients | Sort-Object -Property Timestamp

Use the EAC to search the message tracking logs

You can use the Delivery Reports for administrators feature in the Exchange admin center (EAC ) to search the
message tracking logs for information about messages sent by or received by a specific mailbox in your
organization. For more information see Track messages with delivery reports .
 Delivery reports for administrators
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

With delivery reports for administrators, you can track delivery information about messages sent by or received
from any specific mailbox in your organization. Specifically, delivery reports for administrators uses the Exchange
admin center (EAC ) to perform a targeted search of the message tracking logs. The search is always scoped to a
specific mailbox. You can search for messages sent by the mailbox, or sent to the mailbox, and you can filter the
search results by the message subject.
The content of the message body isn't returned in a delivery report, but the subject line is displayed in the results.
If you want to search the mailboxes in your organization for specific email messages based on message content,
see In-Place eDiscovery.
You may find delivery report searches useful in the following situations:
A manager gives a poor review for a trainee because the trainee didn't turn in an assignment on time. The
trainee insists he sent a message with the assignment attached. The manager asks you to verify the status
of the message.
A security bulletin has been sent to users asking that they reply immediately, but no one has replied. Are
they ignoring the message or did they just not receive it?
Users complain that no one is receiving their messages. They check delivery status for their mail but can't
figure out what is going on. This may be because a rule is being applied to messages at the organization
level.
After you create a delivery report search, the resulting delivery report will show the following information: Who
the message was sent from and to, the subject line, and when the message was sent. The delivery report also
shows message delivery status and reasons why delivery may be delayed or failed.

More about delivery reports

Here's how to create a new delivery report: Track messages with delivery reports .
On-premises Exchange organizations can use the Exchange Management Shell to query the message
tracking logs directly. For more information, see Search message tracking logs.
Users can track their own messages. For more information, see Delivery Reports for Users.
If your organization contains a previous version of Exchange, you need to consider how the delivery
reports feature in Exchange 2013 works across Exchange versions.
Exchange 2013 delivery reports can track messages across Exchange 2010 servers in the same
Active Directory site.
Exchange 2013 delivery reports can't track messages across Exchange 2007 servers in the same
Active Directory site. The delivery reports feature uses a remote procedure call and a web service
interface that doesn't exist in Exchange 2007.
 Track messages with delivery reports
6/14/2019 • 4 minutes to read • Edit Online

Applies to: Exchange Server 2013

Delivery Reports is a message tracking tool in the Exchange admin center (EAC ) that you can use to search for
delivery status on email messages sent to or from users in your organization's address book, with a certain
subject. You can track delivery information about messages sent by or received from any specific mailbox in your
organization. The content of the message body isn't returned in a delivery report, but the subject line is displayed
in the results. You can track messages for up to 14 days after they were sent or received.

NOTE
Delivery Reports tracks messages sent by people using the Microsoft Outlook or Outlook Web App email clients. It doesn't
track messages sent from POP or IMAP email clients, such as Windows Mail, Outlook Express, or Mozilla Thunderbird.

What do you need to know before you begin?

Estimated time to complete each procedure: Time to complete will vary based on the scope of your search.
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Message tracking" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the EAC to track messages

1. In the EAC, navigate to Mail Flow > Delivery Reports.
2. Enter the following information:
* Mailbox to search: Click Browse to select the mailbox from the address book and then click OK.
Selecting the mailbox to search is required.
Select one of the following:
Search for messages sent to Use this option to search for messages sent to specific users.
Click Select users and then pick users from the address book by selecting a user from the
list and clicking Add. You can select more than one user here. When you're finished selecting
users, click OK to return to the Delivery Reports page. If you select this option, you can
also leave the field blank to find messages sent to anyone.
Search for messages received from Use this option to search for messages received from
a specific user. Again, just select the user from the address book and click OK to return to the
Delivery Reports page. If you select this option, you have to specify a sender.
Search for these words in the subject line Enter subject line information here, or leave it blank
to expand your search.
3. When you are finished, click Search. If you want to start over, click Clear.
Use the EAC to review a delivery report
To view delivery information, select a message in the Search results pane and click Details.
The delivery report shows delivery status and detailed delivery information for the message you have selected
from the Search results pane. At the top of the report, you'll see the following fields:
Subject The subject line of the message appears as the heading of the report.
From Alias, display name, or email address of the person who sent the message.
To: Alias, display name, or email address for each recipient of the message.
Sent Date and time the message was sent.

Summary to date section

This section appears in the delivery report if a message was sent to more than one person or recipient. The top
of this section tells you the total number of recipients that the message was sent to and gives brief delivery
information for each recipient.
Summary to date Displays total number of recipients, and if there are messages Pending, Delivered, or
Unsuccessful. Click the hyperlinks to sort by status.
Search box: The search box is useful if you sent the message to a group of more than 30 recipients. In the
search box, type an email address that you want to get delivery information about and click the
magnifying glass.
To Shows the email address of the recipient.
Status This column displays the status of the message for each recipient.

Detailed report information

This section contains detailed delivery information for a message sent to the recipient you select in the Summary
to date section.
Delivery Report for: The email address of the selected recipient is shown here.
Submitted: Date and time that the message was submitted for delivery by the system.
Depending on the delivery status of the message, you may see a variety of status states, including:
Delivered Indicates successful delivery.
Deferred Indicates that a message is delayed.
Pending If message delivery is pending because a message meets the criteria for an organization-wide
rule or policy or because it's subject to message approval, the status message explains what action a rule is
performing or that the message must be approved by a moderator before delivery.
Moderator: The status indicates whether the message was approved or rejected by the moderator.
Groups Expanded If a message was sent to a group, the individual users are shown in the Summary to
date section so you can see the delivery status for each recipient. If you need to remove or add a user to a
group during a delivery report investigation, you can modify a group by clicking Edit Groups.
Failed: Shows the date, time, and reason for a message delivery failure. For example, an organization-
wide rule may be blocking message delivery or the message couldn't be delivered.
When you're done reviewing the report, click Close. Delivery reports aren't saved, but you can re-run a report at
any time. Remember there is a two-week search window.

How do you know this worked?

If your search was successful, messages that fit the search criteria are listed in the Search results pane. To view
the delivery information for a specific message, select it and then click Details. If no messages are displayed in
the Search results pane, change the search criteria and then re-run the search.
 Content conversion
6/11/2019 • 15 minutes to read • Edit Online

Applies to: Exchange Server 2013

Content conversion is the process of correctly formatting a message for each recipient. The decision to perform
content conversion on a message depends on the destination and format of the message being processed. In
Microsoft Exchange Server 2013, there are two different kinds of content conversion:
Message conversion for external recipients: This type of content conversion includes the Transport
Neutral Encapsulation Format (TNEF ) conversion options and message encoding options for external
recipients. Messages sent to recipients inside the Exchange organization don't require this type of content
conversion. This type of content conversion is handled by the categorizer in the Transport service on
Mailbox server. Categorization on each message happens after a newly arrived message is put in the
Submission queue. In addition to recipient resolution and routing resolution, content conversion is
performed on the message before the message is put in a delivery queue. If a single message contains
multiple recipients, the categorizer determines the appropriate encoding for each message recipient.
Content conversion tracing doesn't capture any content conversion failures that the categorizer encounters
as it converts messages sent to external recipients.
MAPI conversion for internal recipients: This type of content conversion is handled by the Mailbox
Transport service. The Mailbox Transport service exists on Mailbox servers to transmit messages between
mailbox databases on the local server, and the Transport service on Mailbox servers. Specifically, the
Mailbox Transport Submission service transmits messages from the sender's Outbox to the Transport
service on a Mailbox server. The Mailbox Transport Delivery service transmits messages from the Transport
service on a Mailbox server to the recipient's Inbox. The Mailbox Transport Submission service converts all
outgoing messages from MAPI and the Mailbox Transport Delivery service converts all incoming messages
to MAPI. Content conversion tracing captures these MAPI conversion failures. For more information, see
Content conversion tracing.
This topic explains the message conversion options for external recipients.

Exchange and Outlook message formats

The following list describes the basic message formats available in Exchange and Microsoft Outlook:
Plain text: A plain text message uses only US -ASCII text as described in RFC 2822. The message can't
contain different fonts or other text formatting. The following two formats can be used for a plain text
message:
The message headers and the message body are composed of US -ASCII text. Attachments must be
encoded by using Uuencode. Uuencode represents Unix-to-Unix encoding and defines an encoding
algorithm to store binary attachments in the body of an email message by using US -ASCII text
characters.
The message is MIME -encoded with a Content-Type value of text/plain, and a Content-Transfer-
Encoding value of 7bit for the text parts of a multipart message. Any message attachments are
encoded by using Quoted-printable or Base64 encoding. By default, when you compose and send a
plain text message in Outlook, the message is MIME -encoded with a Content-Type value of
text/plain.
HTML: An HTML message supports text formatting, background images, tables, bullet points, and other
graphical elements. By definition, an HTML -formatted message must be MIME -encoded to preserve these
formatting elements.
Rich text format (RTF): RTF supports text formatting and other graphical elements. RTF is synonymous
with TNEF. TNEF and RTF can be used interchangeably. The rich text message format is completely
different from the rich text document format available in Microsoft Word.
Only Outlook and a few other MAPI email clients understand RTF messages.
TNEF: The Transport Neutral Encapsulation Format is a Microsoft-specific format for encapsulating MAPI
message properties. A TNEF message contains a plain text version of the message and an attachment that
packages the original formatted version of the message. Typically, this attachment is named Winmail.dat.
The Winmail.dat attachment includes the following information:
Original formatted version of the message, including, for example, fonts, text sizes, and text colors
OLE objects, including, for example, embedded pictures or embedded Microsoft Office documents
Special Outlook features, including, for example, custom forms, voting buttons, or meeting requests
Regular message attachments that were in the original message
The resulting plain text message can be represented in the following formats:
RFC 2822-compliant message composed of only US -ASCII text with a Winmail.dat attachment
encoded in Uuencode
Multipart MIME -encoded message that has a Winmail.dat attachment
A MAPI-compliant email client that fully understands TNEF, such as Outlook, processes the
Winmail.dat attachment and displays the original message content without ever displaying the
Winmail.dat attachment. An email client that doesn't understand TNEF may present a TNEF
message in any of the following ways:
The plain text version of the message is displayed, and the message contains an attachment named
Winmail.dat, Win.dat, or some other generic name such as Attnnnnn.dat or Attnnnnn.eml where the
nnnnn placeholder represents a random number.
The plain text version of the message is displayed. The TNEF attachment is ignored or removed. The
result is a plain text message.
Messaging servers that understand TNEF can be configured to remove TNEF attachments from
incoming messages. The result is a plain text message. Moreover, some email clients such as
Microsoft Outlook Express may not understand TNEF, but recognize and ignore TNEF attachments.
The result is a plain text message.
There are third-party utilities that can help convert Winmail.dat attachments.
TNEF is understood by all versions of Exchange since Exchange Server version 5.5.
Summary Transport Neutral Encapsulation Format (STNEF): STNEF is equivalent to TNEF. However,
STNEF messages are encoded differently than TNEF messages. Specifically, STNEF messages are always
MIME -encoded and always have a Content-Transfer-Encoding value of Binary. Therefore, there's no plain
text representation of the message, and there's no distinct Winmail.dat attachment contained in the body of
the message. The whole message is represented by using only binary data. Messages that have a Content-
Transfer-Encoding value of Binary can only be transferred between SMTP messaging servers that support
and advertise the BINARYMIME and CHUNKING SMTP extensions as defined in RFC 3030. The
messages are always transferred between SMTP messaging by using the BDAT command, instead of the
standard DATA command.
 STNEF is understood by all versions of Exchange since Exchange 2000. STNEF is automatically used for all
messages transferred between Exchange servers in the organization since native mode Exchange Server
2003.
Exchange never sends STNEF messages to external recipients. Only TNEF messages can be sent to
recipients outside the Exchange organization.

Content conversion options for external recipients

The content conversion options that you can set in an Exchange organization for external recipients can be
described in the following categories:
TNEF conversion options: These conversion options specify whether TNEF should be preserved or
removed from messages that leave the Exchange organization.
Message encoding options: These options specify message encoding options, such as MIME and non-
MIME character sets, message encoding, and attachment formats.
These conversion and encoding options are independent of one another. For example, whether TNEF messages
can leave the Exchange organization isn't related to the MIME encoding settings or plain text encoding settings of
those messages.
You can specify the content conversion at various levels of the Exchange organization as described in the following
list:
Remote domain settings: Remote domains define the settings for outgoing message transfers between
the Exchange organization and external domains.. Even if you don't create remote domain entries for
specific domains, there's a predefined remote domain named Default that applies to all remote address
spaces (*).
Mail user and mail contact settings: Mail users and mail contacts are similar because both have external
email addresses and contain information about people outside the Exchange organization. The main
difference is mail users have accounts that can be used to log on to the Active Directory domain and access
resources in the organization.
Outlook settings: In Outlook, you can set the message formatting and encoding options described in the
following list:
Message format: You can set the default message format for all messages. You can override the
default message format as you compose a specific message.
Internet message format: You can control whether TNEF messages are sent to remote recipients
or whether they are first converted to a more compatible format. You can also specify various
message encoding options for messages sent to remote recipients. These settings don't apply to
messages sent to recipients in the Exchange organization.
Internet recipient message format: You can control whether TNEF messages are sent to specific
recipients or whether they are first converted to a more compatible format. You can set the
conversion options for specific contacts in your Contacts folder, and you can override the conversion
options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. These
conversion options aren't available for recipients in the Exchange organization.
Internet recipient message encoding options: You can control the MIME or plain text encoding
options for specific contacts in your Contacts folder, and you can override the conversion options for
a specific recipient in the To, Cc, or Bcc fields as you compose a message. These conversion options
aren't available for recipients in the Exchange organization.
International options: You can control the character sets used in messages.
TNEF conversion options
You can specify the TNEF conversion options at the following levels:
Remote domain settings
Mail user and mail contact settings
Outlook settings, including:
Message format
Internet message format
Internet recipient message format

Message encoding options

You can specify the message encoding options at the following levels:
Remote domain settings
Mail user and mail contact settings
Outlook settings, including:
Message format
Internet message
Internet recipient message format
Message character set encoding options
For detailed information, see Message encoding options.

Understanding the structure of email messages

To better understand the content conversion options for external recipients, you need to understand the structure
of email messages. An SMTP message is based on plain 7-bit US -ASCII text to compose and send email
messages. A standard SMTP message consists of the following elements:
Message envelope: The message envelope is defined in RFC 2821. The message envelope contains
information required to transmit and deliver the message. Recipients never see the message envelope,
because it's generated by the message transmission process and isn't actually part of the message contents.
Message contents: The message contents are defined in RFC 2822. The message contents consist of the
following elements:
Message header: The message header is a collection of header fields. Header fields consist of a field
name, followed by a colon (:) character, followed by a field body, and ended by a carriage return/line
feed (CR/LF ) character combination.
A field name must be composed of printable US -ASCII text characters except the colon (:)
character. Specifically, ASCII characters that have values from 33 through 57 and 59 through
126 are permitted.
A field body may be composed of any US -ASCII characters, except for the carriage return
(CR ) character and the line feed (LF ) character. However, a field body may contain the CR/LF
character combination when used in header folding. Header folding is the separation of a
single header field body into multiple lines as described in section 2.2.3 of RFC 2822. Other
 field body syntax requirements are described in sections 3 and 4 of RFC 2822.
Message body: The message body is a collection of lines of US -ASCII text characters that appears
after the message header. The message header and the message body are separated by a blank line
that ends with the CR/LF character combination. The message body is optional. Any line of text in
the message body must be less than 998 characters. The CR and LF characters can only appear
together to indicate the end of a line.
When SMTP messages contain elements that aren't plain US -ASCII text, the message must be encoded to
preserve those elements. The MIME standard defines a method of encoding content in messages that isn't text.
MIME allows for text in other character sets, attachments without text, multipart message bodies, and header
fields in other character sets. MIME is defined in RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2077.
MIME defines a collection of header fields that specifies additional message attributes. The following table
describes some important MIME header fields.
Important MIME header fields
HEADER FIELD NAME DEFAULT VALUE DESCRIPTION

MIME-Version 1.0 This header field is the first MIME

header field that appears in a
MIME-formatted message. This
header field appears after the other
standard RFC 2822 header fields,
but before any other MIME header
fields. MIME-aware email clients
use this header field to identify a
MIME-encoded message. When
this header field is absent, MIME-
aware email clients identify the
message as plain text.

Content-Type text/plain This header field identifies the

media type of the message content
as described in RFC 2046. A media
type consists of a type, a subtype,
and one or more optional
parameters, such as a charset=
parameter that defines the MIME
character encoding. Types that
begin with "x-" aren't standard.
Subtypes that begin with "vnd." are
vendor-specific. The Internet
Assigned Numbers Authority
(IANA) maintains a list of registered
media types. For more information,
see MIME Media Types.
The multipart media type allows for
multiple message parts in the same
message by using sections defined
by different media types. Some
Content-Type field values include
text/plain, text/html,
multipart/mixed, and
multipart/alternative.

Content-Transfer-Encoding 7bit This header field can describe the

following information about a
message:
 The encoding algorithm
HEADER FIELD NAME DEFAULT VALUE DESCRIPTION
used to transform any non-
US-ASCII text or binary data
that exists in the message
body.
An indicator that describes
the current condition of the
message body.
There can be multiple values of the
Content-Transfer-Encoding header
field in a MIME message. When the
Content-Transfer-Encoding header
field appears in the message
header, it applies to the whole body
of the message. When the
Content-Transfer-Encoding header
field appears in one of the parts of
a multipart message, it applies only
to that part of the message.
When an encoding algorithm is
applied to the message body data,
the message body data is
transformed into plain US-ASCII
text. This transformation allows the
message to travel through older
SMTP messaging servers that only
support messages in US-ASCII text.
The values of the Content-Transfer-
Encoding header field that indicate
an encoding algorithm was used on
the message body are as follows:
Quoted-printable This
encoding algorithm uses
printable US-ASCII
characters to encode the
message body data. If the
original message text is
mostly US-ASCII text,
Quoted-printable encoding
gives somewhat readable
and compact results. All
printable US-ASCII text
characters except the equal
sign (=) character can be
represented without
encoding.
Base64 This encoding
algorithm is based primarily
on the privacy-enhanced
mail (PEM) standard defined
in RFC 1421. Base64
encoding uses the 64-
character alphabet encoding
algorithm and output
padding characters defined
by PEM to encode the
message body data. A
Base64 encoded message is
typically 33 percent larger
than the original message.
Base64 encoding creates a
predictable increase in
 message size and is optimal
HEADER FIELD NAME DEFAULT VALUE DESCRIPTION
for binary data and non-
US-ASCII text.
Typically, you won't see multiple
encoding algorithms used in the
same message.
When no encoding algorithm has
been used on the message body,
the Content-Transfer-Encoding
header field merely identifies the
current condition of the message
body data. The following values of
the Content-Transfer-Encoding
header field indicate that no
encoding algorithms were used on
the message body:
7bit This value indicates
that the message body data
is already in the RFC 2822
format. Specifically, this
means that the following
conditions must be true:
All lines of text must
be less than
998 characters long.
All characters must
be US-ASCII text
that have character
values from 1
through 127.
The CR and LF
characters can only
be used together to
indicate the end of a
line of text.
The whole message body
may be 7bit, or part of the
message body in a
multipart message may be
7bit. If the multipart
message contains other
parts that have any binary
data or non-US-ASCII text,
that part of the message
must be encoded using the
Quoted-printable or Base64
encoding algorithms.
Messages that have 7bit
bodies can travel between
SMTP messaging servers by
using the standard DATA
command.
8bit This value indicates
that the message body data
contains non-US-ASCII
characters. Specifically, this
means that the following
conditions must be true:
All lines of text must
 be less than
HEADER FIELD NAME DEFAULT VALUE DESCRIPTION
998 characters long.
One or more
characters in the
message body have
values larger
than 127.
The CR and LF
characters can only
be used together to
indicate the end of a
line of text.
The whole message body
may be 8bit, or part of the
message body in a
multipart message may be
8bit. If the multipart
message contains other
parts that have binary data,
that part of the message
must be encoded using the
Quoted-printable or Base64
encoding algorithms.
Messages that have 8bit
bodies can only travel
between SMTP messaging
servers that support the
8BITMIME SMTP extension
as defined in RFC 1652,
such as servers running
Exchange 2000 Server or
newer versions. Specifically,
this means that the
following conditions must
be true:
The 8BITMIME
keyword must be
advertised in the
server's EHLO
response.
Messages are still
transferred by using
the SMTP standard
DATA command.
However, the
BODY=8BITMIME
parameter must be
added to the end of
the MAIL FROM
command.
Binary This value indicates
that the message body
contains non-US-ASCII text
or binary data. Specifically,
this means that the
following conditions are
true:
Any sequence of
characters is allowed.
There is no line
 length limitation.
HEADER FIELD NAME DEFAULT VALUE DESCRIPTION
Binary message
elements don't
require encoding.
Messages that have Binary
bodies can only travel
between SMTP messaging
servers that support the
BINARYMIME SMTP
extension as defined in
RFC 3030, such as servers
running Exchange 2000
Server or newer versions.
Specifically, this means that
the following conditions
must be true:
The BINARYMIME
keyword must be
advertised in the
server's EHLO
response.
The BINARYMIME
SMTP extension can
only be used with
the CHUNKING
SMTP extension.
Chunking enables
large message
bodies to be sent in
multiple, smaller
chunks. Chunking is
also defined in
RFC 3030. The
CHUNKING keyword
must also be
advertised in the
server's EHLO
response.
Messages are
transferred using the
BDAT command
instead of the
standard DATA
command.
The
BODY=BINARYMIME
parameter must be
added to the end of
the MAIL FROM
command when the
message has a
message body.
The values 7bit, 8bit, and Binary
never exist together in the same
multipart message. The values are
mutually exclusive. The Quoted-
printable or Base64 values may
appear in a 7bit or 8bit multipart
message body, but never in a
Binary message body. If a multipart
message body contains different
 parts composed of 7bit and 8bit
HEADER FIELD NAME DEFAULT VALUE DESCRIPTION
content, the whole message is
classified as 8bit. If a multipart
message body contains different
parts composed of 7bit, 8bit, and
Binary content, the whole message
is classified as Binary.

Content-Disposition Attachment This header field instructs a MIME-

enabled email client on how it
should display an attached file, and
is described in RFC 2183. The
values of this field may be Inline or
Attachment. When the value of this
field is Inline, the attachment is
displayed in the message body.
When the value of this field is
Attachment, the attached file
appears as a regular attachment
separate from the message body.
Other parameters are available
when the value is Attachment, such
as Filename, Creation-date, and
Size.
 Configure content transfer encoding
6/7/2019 • 3 minutes to read • Edit Online

Applies to: Exchange Server 2013

Content transfer encoding defines encoding methods for transforming binary email message data into the US -
ASCII plain text format. This transformation allows the message to travel through older SMTP messaging servers
that only support messages in US -ASCII text. Content transfer encoding is defined in RFC 2045. The transfer
encoding method is stored in the Content-Transfer-Encoding header field in the message. In Microsoft Exchange
Server 2013, the following content transfer encoding methods are available:
7-bit: This value indicates that the message body data is already in the US ASCII plain text format, and no
message encoding has been done to the message.
Quoted-printable (QP ): This encoding method uses printable US -ASCII characters to encode the message
body data. If the original message text is mostly US -ASCII text, QP encoding gives somewhat readable and
compact results. By default, Exchange 2013 uses QP for encoding binary message data.
Base64: This encoding method is based primarily on the privacy-enhanced mail (PEM ) standard defined in
RFC 1421. Base64 encoding uses the 64-character alphabet encoding method and output padding
characters defined by PEM to encode the message body data. Base64 encoding creates a predictable
increase in message size and is optimal for binary data and non-US -ASCII text.
You configure the transfer encoding method using the ByteEncoderTypeFor7BitCharsets parameter on the Set-
OrganizationConfig and Set-RemoteDomain cmdlets. The content transfer encoding settings you configure
with Set-OrganizationConfig apply to all messages in the Exchange organization. The content transfer encoding
settings you configure with Set-RemoteDomain apply only to message sent to external recipients in the remote
domain.
The following table lists the values that you can use to set the transfer encoding method.

PARAMETER IN SET-
ORGANIZATIONCONFIG PARAMETER IN SET-REMOTEDOMAIN DESCRIPTION

0 Use7Bit Always use 7-bit encoding for

HTML and for plain text. This is the
default value.

1 UseQP Always use QP encoding for HTML

and for plain text.

2 UseBase64 Always use Base64 encoding for

HTML and for plain text.

5 UseQPHtmlDetectTextPlain Use QP encoding for HTML and for

plain text unless line wrapping is
enabled in plain text. If line
wrapping is enabled, use 7-bit
encoding for plain text.
 PARAMETER IN SET-
ORGANIZATIONCONFIG PARAMETER IN SET-REMOTEDOMAIN DESCRIPTION

6 UseBase64HtmlDetectTextPlain Use Base64 encoding for HTML and

for plain text, unless line wrapping is
enabled in plain text. If line
wrapping is enabled in plain text,
use Base64 encoding for HTML, and
use 7-bit encoding for plain text.

13 UseQPHtml7BitTextPlain Always use QP encoding for HTML.

Always use 7-bit encoding for plain
text.

14 UseBase64Html7BitTextPlain Always use Base64 encoding for

HTML. Always use 7-bit encoding
for plain text.

For more details about Content-Transfer-Encoding header field, see the "Understanding the structure of email
messages" section in Content conversion.
For more information about remote domains, see Remote domains.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Transport service" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to configure the content transfer encoding method for
the organization
To configure the content transfer encoding method for the organization, run the following command:

Set-OrganizationConfig -ByteEncoderTypeFor7BitCharsets <Integer>

For example, to set the content transfer encoding method to Base64, run the following command:

Set-OrganizationConfig -ByteEncoderTypeFor7BitCharsets 2

Use the Shell to configure the content transfer encoding method for a
remote domain
To configure the content transfer encoding method for all the recipients in a remote domain, run the following
command:

Set-RemoteDomain -ByteEncoderTypeFor7BitCharsets <Value>

For example, to set the content transfer encoding method to Base64, run the following command:

Set- RemoteDomain -ByteEncoderTypeFor7BitCharsets UseBase64

How do you know this worked?

To verify that you have successfully configured the method for content transfer encoding, do the following:
1. Send a test message that contains a mixture of US -ASCII text and binary data or non-US -ASCII text to an
internal or external test account. Use an internal account to test organization settings, and an external
account in the remote domain to test remote domain settings.
2. In an email client, view the Content-Transfer-Encoding header field in the message, and verify the content
transfer encoding method that was used on the message matches the method you configured.
 Message encoding options
5/30/2019 • 7 minutes to read • Edit Online

Applies to: Exchange Server 2013

The message encoding options that are available in Exchange specify message characteristics, such as MIME and
non-MIME character sets, binary encoding, and attachment formats. You can specify message encoding options in
the following locations:
Remote domain settings
Mail user and mail contact settings
Microsoft Outlook settings
Message format
Internet message format
Internet recipient message format
Message character set encoding options
Content
Message encoding options for messages sent to remote domains
Message encoding options for mail users and mail contacts
Message encoding options available in Outlook
Message encoding options available in Outlook Web App
Order of precedence for message encoding options
For more information

Message encoding options for messages sent to remote domains

When you configure message encoding options for a remote domain, the specific settings are applied for all
messages sent to that domain. For remote domains in your organization, you have the following configuration
options for message encoding.

Setting Available in EAC in Exchange Available in the Shell

Online Dedicated
MIME character set The Yes Yes
character set that you specify will
only be used for MIME messages
that don't have their own character
set specified. Setting this parameter
won't overwrite character sets that
are already specified in the
outgoing mail.
Non-MIME character set This
setting is used if either of the
following conditions are true:
Incoming messages from a
remote domain are missing
the value of the charset=
setting in the MIME
Content-Type: header field.
Outgoing messages to a
remote domain are missing
the value of the MIME
character set.

Content type You can specify the No Yes

content type for MIME messages
sent to the recipients in the remote
domain. You can use of the
following settings:
MimeHtmlText All
messages are converted to
MIME messages that use
HTML formatting, unless the
original message is a text
message. If the original
message is a text message,
the outgoing message will
be a MIME message that
uses text formatting. This is
the default setting.
MimeText All messages
are converted to MIME
messages that use text
formatting.
MimeHtml All messages
are converted to MIME
messages that use HTML
formatting.

Line wrap size You can specify No Yes

the maximum number of characters
that can exist on a single line of text
in the body of the e-mail message.
Older email client applications may
prefer 78 characters per line. This
option is only available by using the
Shell.
Message encoding options for mail users and mail contacts
When you configure message encoding options for a mail contact or a mail user, that option is applied to all
messages sent to that specific recipient. For mail contacts and mail users in your organization, you have the
following configuration options for message encoding:
UsePreferMessageFormat: This parameter specifies whether the message format settings configured for
the mail contact override the global settings configured for the remote domain. If you disable this setting,
Exchange ignores other message encoding options for this recipient and the message encoding is
determined by the configuration of the remote domain or the settings configured by the message sender.
MessageFormat: This parameter specifies the message format. You can either specify Text or Mime as the
message format. The value of this setting is dependent on the MessageBodyFormat parameter. If the
message body format is Html or TextAndHtml, you must set this parameter to Mime.
MessageBodyFormat: This parameter specifies the message body format. You can specify Text, Html, or
TextAndHtml. The value of this setting is dependent on the MessageFormat parameter. If the message
format is Text, you must also set this parameter to Text.
MacAttachmentFormat: This parameter specifies the Apple Macintosh operating system attachment
format for messages. You can specify BinHex, UuEncode, AppleSingle, or AppleDouble. The value of this
setting is dependent on the MessageFormat parameter. If the message format is set to Text, you must set
this parameter to either BinHex or UuEncode. If the message format is set to Mime, you must set this
parameter to BinHex, AppleSingle or AppleDouble.
You need to use these parameters in the Exchange Management Shell to set the message encoding options for
mail users and mail contacts. For more information, see the following topics:
Enable-MailContact
New -MailContact
Set-MailContact
Enable-MailUser
New -MailUser
Set-MailUser

Message encoding options available in Outlook

As a sender, you can specify message encoding options in Outlook at any of the following stages:
By configuring the default message format to be either plain text or HTML.
By setting the message format as you're composing it to either plain text or HTML using the Format area in
the Options tab.
By configuring the message encoding options for messages that are sent to all recipients outside the
Exchange organization. These options are called Internet message format options. The options only apply to
remote recipients, and not to recipients in the Exchange organization.
By configuring the message encoding options for messages that are sent to specific recipients outside the
Exchange organization. These options are called Internet recipient message format options. The options
only apply to remote recipients in your Contacts folder, and not to recipients in the Exchange organization.
By default, Outlook uses automatic character set message encoding by scanning the whole text of the outgoing
message to determine the appropriate encoding to use for the message. This setting applies to messages that you
send to Internet recipients and recipients in the Exchange organization. However, you can bypass this and specify a
preferred encoding for outgoing messages.

Message encoding options available in Outlook Web App

As a sender, you can specify message encoding options in Outlook Web App at any of the following stages:
By configuring the default message format to be either plain text or HTMLin the Message format section
of the Settings >Options > Settings page.
By setting the message format as you're composing it to either plain text or HTML by using the More
options (...) menu, and selecting Switch to plain text or Switch to HTML.

Order of precedence for message encoding options

Exchange uses the order of precedence as described in the following list to determine the message encoding
options for outgoing messages sent to recipients outside the Exchange organization:
1. Remote domain settings
2. Outlook or Outlook Web App settings
3. Mail user or mail contact settings
The list specifies the order of precedence from lowest to highest. A setting made at a higher level may override a
setting made at a lower level.
The following table describes the order of precedence from lowest priority to highest priority for message
character set encoding options.
Order of precedence from lowest priority to highest priority for message character set encoding options
SOURCE PARAMETER VALUES

Remote domain entry setting, using CharacterSet Specified

the EAC or Set-RemoteDomain

Remote domain entry setting, using NonMimeCharacterSet Specified

the EAC or Set-RemoteDomain

Outlook setting Message character set encoding Auto-select

Specified

When you set the non-MIME character set for a remote domain, the character set is assigned to the following
types of messages:
Outgoing messages to a configured remote domain that don't contain a specified character set.
Incoming messages from a configured remote domain that don't contain a specified character set.
The value of the Windows ANSI code page for the transport server is used to assign a character set to the
following types of messages:
Internal messages that don't contain a specified character set.
Internal messages that contain a specified character set, but don't contain a specified server code page.
If a message contains a specified but invalid character set, the transport server tries to replace the invalid character
set with a valid character set.
The following table describes the order of precedence from lowest priority to highest priority for plain text
message encoding options.
Order of precedence from lowest priority to highest priority for plain text message encoding options
SOURCE PARAMETER VALUES

Set-RemoteDomain LineWrapSize From 0 through 132

unlimited

Outlook settings Message format Plain text

Outlook settings Internet message format Plain text options:

Encode attachments in
UuEncode format when you
send a plain text message
Automatically wrap text at
nn characters

Outlook settings Internet recipient message format Plain text format:

Encode attachments in
UuEncode attachment
format
Use BinHex Mac attachment
format

Set-MailUser UsePreferMessageFormat $true

Set-MailContact $false

If the value is $false or if the

recipient isn't defined as a mail user
or mail contact in the Exchange
organization, the mail user or mail
contact settings are ignored.

Set-MailUser MessageFormat Text

Set-MailContact

Set-MailUser MessageBodyFormat Text

Set-MailContact

Set-MailUser MacAttachmentFormat BinHex

Set-MailContact UuEncode

The following table describes the order of precedence from lowest priority to highest priority for MIME message
encoding options.
Order of precedence from lowest priority to highest priority for MIME message encoding options
SOURCE PARAMETER VALUES

Set-RemoteDomain ContentType MimeHtmlText

MimeText

MimeHtml

Outlook or Outlook Web App Message format Plain text

settings
HTML

Outlook settings Internet recipient message format MIME message format

Plain text
Include both plain text and
HTML
HTML

Set-MailUser UsePreferMessageFormat $true

Set-MailContact $false

If the value is $false or if the

recipient isn't defined as a mail user
or mail contact in the Exchange
organization, the mail user or mail
contact settings are ignored.

Set-MailUser MessageFormat Text

Set-MailContact Mime

Set-MailUser MessageBodyFormat Text

Set-MailContact Html

TextAndHtml

Set-MailUser MacAttachmentFormat BinHex

Set-MailContact AppleSingle
AppleDouble

For more information

Message encoding options
TNEF conversion options
Remote domains
Remote domains in Exchange Online
Manage mail users
Manage mail contacts
Change the message format in Outlook
 TNEF conversion options
6/14/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can specify whether Transport Neutral Encapsulation Format (TNEF ) should be preserved or removed from
messages that leave the Exchange organization. TNEF, also known as Outlook Rich Text Format or Exchange Rich
Text Format, is a Microsoft-specific format for encapsulating MAPI message properties. All versions of
Microsoft Outlook fully understand TNEF. Outlook Web App translates TNEF into MAPI and displays the
formatted messages. However, other email clients that don't understand TNEF typically display TNEF formatted
messages as plain text messages with Winmail.dat or Win.dat attachments.

TNEF conversion options for remote domains

When you configure TNEF conversion options for a remote domain, those TNEF conversion options are applied to
all messages sent to that domain.
For Exchange Online Dedicated, you use the Exchange admin center (EAC ) to set TNEF conversion options
for a remote domain at Mail flow > Remote domains > Edit ( ) > Use Exchange rich-text format.
For Exchange Online and Exchange 2013, you use the TnefEnabled parameter on the Set-RemoteDomain
cmdlet to set TNEF conversion options for a remote domain.
For remote domains in your organization, you have the following configuration options for TNEF conversion:

SETTING IN THE EAC IN THE SHELL

Use TNEF for all messages sent to Always $true

the remote domain.

Never use TNEF for any messages Never $false

sent to the remote domain.

TNEF messages aren't specifically Follow user settings $null (blank)

allowed or prevented for recipients
in the remote domain. Whether
TNEF messages are sent to
recipients in the remote domain
depends on the specific setting on
the mail contact or mail user, or the
setting specified by the sender in
Outlook. This is the default value.

For more information about remote domains, see Remote domains or Remote domains in Exchange Online.

TNEF conversion options for mail users and mail contacts

When you configure TNEF conversion options for a mail contact or a mail user, those TNEF conversion options are
applied to all messages sent to that specific recipient. You use the UseMapiRichTextFormat parameter on the Set-
MailUser and Set-MailContact cmdlets to configure the TNEF conversion options for mail users and mail
contacts.
For mail users and mail contacts in your organization, you have the following configuration options for TNEF
conversion:
Always: TNEF is used for all messages sent to the recipient. The corresponding value for the
UseMapiRichTextFormat parameter is Always .
Never: TNEF is never used for any messages sent to the recipient. The corresponding value for the
UseMapiRichTextFormat parameter is Never .
Use default settings: TNEF messages aren't specifically allowed or prevented for the mail user or mail
contact. Whether TNEF messages are sent to the recipient depends on the specific setting for the
corresponding remote domain or the setting specified by the sender in Outlook. The corresponding value
for the UseMapiRichTextFormat parameter is UseDefaultSettings . This is the default setting.

TNEF conversion options in Outlook

Senders can control the default TNEF message conversion options for TNEF messages sent to all recipients
outside the Exchange organization. These options are called Internet message format options. The options only
apply to remote recipients, and not to recipients in the Exchange organization.

NOTE
The following options define how messages containing Outlook rich text are handled when sent to external recipients. If the
message format you're using is HTML or plain text, these settings don't apply.

You have the following TNEF conversion options in Outlook:

Convert to HTML format: This is the default option. Any TNEF messages sent to remote recipients are
converted to HTML. Any formatting in the message should closely resemble the original message. MIME -
encoded HTML messages are supported by many, but not all, email clients.
Convert to Plain Text format: Any TNEF messages sent to remote recipients are converted to plain text.
Any formatting in the message is lost.
Send using Outlook Rich Text Format: Any TNEF messages sent to remote recipients remain TNEF
messages.
You can configure these options in the following locations in Outlook:
Outlook 2010 or Outlook 2013: File > Options > Mail > Message format.
Outlook 2007: Tools > Options > Mail Format > Internet Format.
Senders can also control the default TNEF message conversion options for TNEF messages sent to specific
recipients outside the Exchange organization. These options are called Internet recipient message format options.
The options only apply to remote recipients stored in your Contacts folder, and not to recipients in the Exchange
organization. You have the following TNEF conversion options for remote recipients in your Contacts folder:
Let Outlook decide the best sending format: This is the default setting. This setting forces Outlook to
use the TNEF conversion option that's specified by the default Internet format. The possible values are
Convert to HTML format, Convert to Plain Text format, or Send using Outlook Rich Text Format.
Therefore, the TNEF message may be left as TNEF, converted to HTML, or converted to plain text. If you
want to make sure that the TNEF message remains TNEF for this recipient, you should change this setting
from Let Outlook decide the best sending format to Send using Outlook Rich Text format.
Send Plain Text only: Any TNEF messages sent to the recipient are converted to plain text. Any formatting
in the message is lost.
 Send using Outlook Rich Text format: Any TNEF messages sent to remote recipients remain TNEF
messages.
You can configure these options for a contact in the following locations in Outlook:
Outlook 2010 or Outlook 2013: Open the contact card, double-click the email address, click the View
more options for interacting with this person icon, and select Outlook properties. In the E -mail
Properties dialog box, select Internet format.
Outlook 2007: Open the contact card, double-click the E -mail field and select Internet format.

Order of precedence for TNEF conversion options

Exchange uses the order of precedence as described in the following list to determine the TNEF conversion options
for outgoing messages sent to recipients outside the Exchange organization:
1. Remote domain settings
2. Mail user or mail contact settings
3. Outlook settings
The list specifies the order of precedence from highest to lowest. The TNEF setting on the remote domain
overrides the TNEF settings on the mail user, mail contact or in Outlook. For example, suppose you send a Rich
Text message in Outlook, but the recipient is in a domain where the remote domain setting specifically doesn't
allow TNEF -formatted messages. The message received by the recipient will be plain text or HTML, but not TNEF.
Also, Exchange never sends Summary Transport Neutral Encoding Format (STNEF ) messages to external
recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.
 Content conversion tracing
6/11/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Content conversion tracing captures failures in the MAPI content conversion that's performed by the Mailbox
Transport service on inbound and outbound messages on a Microsoft Exchange Server 2013 Mailbox server.
The Mailbox Transport service on a Mailbox server is responsible for the content conversion of messages sent to
and from mailbox recipients. Specifically, the Mailbox Transport Submission service converts outbound messages
from mailbox users from MAPI to MIME. The Mailbox Transport Delivery service converts inbound messages for
mailbox users from MIME to MAPI. Content conversion tracing is responsible for capturing these MAPI
conversion failures.
The categorizer in the Transport service on a Mailbox server is responsible for the content conversion of all
messages sent to external recipients. Content conversion tracing doesn't capture any content conversion failures
that the categorizer in the Transport service encounters as it converts messages sent to external recipients.

Configure content conversion tracing

Content conversion tracing is controlled by the following parameters in the Set-TransportService and Set-
MailboxTransportService cmdlets in the Exchange Management Shell:
ContentConversionTracingEnabled: This parameter enables or disables content conversion tracing in the
Transport service on the Mailbox server, or in the Mailbox Transport service on the Mailbox server. Valid
values for this parameter are $true and $false . The default value is $false . If your Exchange
organization contains multiple Mailbox servers, you must enable content conversion tracing on each
Mailbox server.
PipelineTracingPath: Although this parameter is associated with pipeline tracing, it also specifies the root
location of the content conversion tracing files. The default location in the Transport service is
%ExchangeInstallPath%TransportRoles\Logs\Hub\PipelineTracing . The default location in the Mailbox
Transport service is %ExchangeInstallPath%TransportRoles\Logs\Mailbox\PipelineTracing .The path must be
local to the Exchange computer.
Content conversion creates a folder named ContentConversionTracing in the path specified by the
PipelineTracingPath parameter. In the ContentConversionTracing folder, content conversion creates two subfolders:
InboundFailures and OutboundFailures . The InboundFailures folder contains the information from inbound
message content conversion failures. The OutboundFailures folder contains the information from outbound
message content conversion failures.
The maximum size for all the files in the InboundFailures folder or the OutboundFailures folder is 128 megabytes
(MB ). Content conversion tracing doesn't use circular logging to remove old files based on the age or size of the
files. As soon as the maximum size for a folder is reached, content conversion tracing stops writing information to
the folder. If you want to make sure that the maximum folder size limits aren't exceeded, you can create a
scheduled task that periodically moves the content conversion tracing files to a different location.
The permissions required on the folders and subfolders used in content conversion tracing are as follows:
Administrators: Full Control
Network Service: Full Control
 System: Full Control

WARNING
Content conversion tracing copies the complete contents of email messages. To avoid the unwanted disclosure of confidential
information, you need to set appropriate security permissions on the location of the content conversion tracing files.

How content conversion tracing works

When the content conversion of an inbound message fails, a delivery status notification (DSN ) that has the status
code 5.6.0 is sent to the message sender. If content conversion tracing is enabled, the failure information is
recorded at the time that the 5.6.0 DSN message is generated. Each content conversion error generates two
separate files.
A content conversion error that occurs when an inbound message is converted from MIME to MAPI generates the
following two files in the InboundFailures folder:
<GUID>.eml: This file contains the failed message in text format.
<GUID>.txt: This file contains the exception description, conversion results, conversion options, and
message size limits imposed on all messages by the Mailbox Transport service.
A content conversion error that occurs when an outbound message is converted from MAPI to MIME generates
the following two files in the OutboundFailures folder:
<GUID>.msg: This file contains the failed message in the Microsoft Outlook message format.
<GUID>.txt: This file contains the exception description, conversion results, conversion options, and
message size limits imposed on all messages by the store driver.
The placeholder <GUID> is the same in both file names. Each content conversion error generates a different GUID
that's used in the file names of the corresponding message and text files. An example of a GUID that's used in the
file names is 038b930e-61fd-4bfd-b9b4-0374c18b73f7 .

Considerations for content conversion tracing

You can leave content conversion tracing enabled for proactive monitoring. Or, you can enable content conversion
tracing to troubleshoot a specific failure event. You can usually reproduce inbound content conversion failures by
asking the recipient of the 5.6.0 DSN message to resend the original message.
Inbound content conversion failures are the most common. Some of the reasons for inbound content conversion
errors include the following:
Violations of message size limits: These message size limits are imposed by the Mailbox Transport
service to help prevent denial of service attacks (DoS ). These message limits are listed in the <GUID>.txt
file. These message limits include the following:
MaxMimeTextHeaderLength: This limit specifies the maximum number of text characters that can
be used in a MIME header. The value is 2000.
MaxMimeSubjectLength: This limit specifies the maximum number of text characters that can be
used in the subject line. The value is 255.
MSize: This limit specifies the maximum message size. The value is 2147483647 bytes.
MaxMimeRecipients: This limit specifies the total number of recipients allowed in the To, Cc, and
Bcc fields. The value is 12288.
 MaxRecipientPropertyLength: This limit specifies the maximum number of text characters that can
be used in a recipient description. The value is 1000.
MaxBodyPartsTotal: This limit specifies the maximum number of message parts that can be used in
a MIME multipart message. The value is 250.
MaxEmbeddedMessageDepth: This limit specifies the maximum number of forwarded messages
that can exist in a message. The value is 30.
For more information about configurable message size limits used in the Transport service on
Mailbox servers or on Edge Transport servers, see Message size limits.
Failure to convert an inbound iCalendar message to a meeting request: RFC 2445 defines iCalendar
as a standard for calendar data exchange. Specific causes of the conversion failure include the following:
Incorrect use of iCalendar by the sending agent.
Constructs of iCalendar that can't be supported by the Outlook or Exchange calendar schema.
Conversion failures of iCalendar don't result in the sender receiving a 5.6.0 DSN message. Instead, the
message is delivered with an attached .ics file that contains the iCalendar message body.
Failures caused by badly formatted MIME messages: Unsolicited commercial email or spam messages
may have formatting errors in the message header, such as unmatched quotation marks in recipient
descriptions. A much smaller number of failures caused by badly formatted MIME messages are considered
bugs.
Outbound content conversion failures are much less common than inbound failures. When outbound failures
occur, they are usually caused by Exchange code bugs or corrupted message content.
 DSNs and NDRs in Exchange 2013
6/11/2019 • 18 minutes to read • Edit Online

Applies to: Exchange Server 2013

NOTE
If you need help with NDRs in Office 365 or Exchange Online, see Email non-delivery reports in Office 365 .

When there's a problem delivering a message, Exchange Server 2013 will send a delivery status notification
(DSN ) to the message sender. These system-generated messages are also known as bounce messages, and they
contain an error code, technical details about the problem, and sometimes troubleshooting steps for the message
sender. Non-delivery report (NDR ) messages are a common type of status notification. This topic for email
administrators describes likely causes and solutions for many NDR status codes. It also tells how to read and
interpret NDR messages.

Common enhanced status codes

The following table contains a list of the enhanced status codes that are returned in NDRs for the most common
message delivery failures.

ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

4.3.1 Insufficient system An out-of-memory Ensure that your

resources error occurred. A Exchange server has
resource problem, such enough disk storage.
as a full disk, can cause
this problem.
Instead of getting a disk
full error, you might be
getting an out-of-
memory error.

4.3.2 System not This NDR is generated You can resolve this
accepting network when a queue has been condition by unfreezing
messages
frozen. the queue.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

4.4.1 Connection timed The destination server is Monitor the situation.

out not responding. This might be a
Transient network transient problem that
conditions can cause might correct itself.
this error. The Exchange
server tries
automatically to connect
to the server again and
deliver the mail. If
delivery fails after
multiple attempts, an
NDR with a permanent
failure code is
generated.

4.4.2 Connection dropped A connection dropped Monitor the situation as

between the servers. the server retries
Transient network delivery. This might be a
conditions or a server transient problem that
that is experiencing might correct itself.
problems can cause this
error. The sending server This situation can also
will retry to deliver the occur when the message
message for a specific size limit for the
time period, and then it connection is reached,
will generate further or if the message
status reports. submission rate for the
client IP address has
exceeded the configured
limit.

4.4.7 Message expired The message in the This message usually

queue has expired. The indicates an issue on the
sending server tried to receiving server. Check
relay or deliver the the validity of the
message, but the action recipient address, and
was not completed determine if the
before the message receiving server is
expiration time occurred. configured correctly to
This message can also receive messages.
indicate that a message
header limit has been You might have to
reached on a remote reduce the number of
server, or some other recipients in the
protocol time-out message header for the
occurred while host about which you
communicating with the are receiving this error. If
remote server. you send the message
again, it is placed in the
queue again. If the
receiving server is
available, the message is
delivered.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.0.0 HELO / EHLO This situation is a Some potential

requires domain permanent failure. resolutions include:
address
Possible causes include:
On one or more
There is no route SMTP
for the given connectors, add
address space; an asterisk (*)
for example, an value as the
SMTP connector SMTP address
is configured, but space.
this address does
not match. Verify that DNS
is working.
DNS returned an
authoritative
host that was
not found for the
domain.
An SMTP error
occurred.

5.1.0 Sender denied This NDR is caused by a Either the recipient

general failure (bad address is incorrectly
address failure). An formatted, or the
email address or recipient could not be
another attribute could correctly resolved. The
not be found in Active first step in resolving
Directory Domain this error is to check the
Services. Contact entries recipient address, and
without the send the message again.
targetAddress
attribute set can cause
this problem. Another
possible cause could be
that the homeMDB
attribute of a user could
not be determined. The
homeMDB attribute
corresponds to the
Exchange server on
which the user's mailbox
resides.
Another common cause
of this NDR is when you
use Microsoft Outlook
to save an email
message as a file, and
then someone opened
the message offline and
replied to it. The
message property only
preserves the
legacyExchangeDN
attribute when Outlook
delivers the message,
and therefore the
lookup could fail.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.1.1 Bad destination This failure might be This error typically

mailbox address caused by the following occurs when the sender
conditions: of the message
incorrectly enters the
The recipient's email address of the
email address recipient. The sender
was entered should check the
incorrectly by the recipient's email address
sender. and send again. This
No recipient's error can also occur if
exists in the the recipient email
destination email address was correct in
system. the past but has
changed or has been
The recipient's removed from the
mailbox has been destination email
moved and the system.
Outlook recipient
cache on the If the sender of the
sender's message is in the same
computer has Exchange organization
not updated. as the recipient, and the
recipient's mailbox still
An invalid legacy exists, determine
domain name whether the recipient's
(DN) exists for mailbox has been
the recipient's relocated to a new email
mailbox Active server. If this is the case,
Directory Outlook might not have
Domain Service. updated the recipient
cache correctly. Instruct
the sender to remove
the recipient's address
from sender's Outlook
recipient cache and then
create a new message.
Resending the original
message will result in
the same failure.
Other issues might
cause this error, such as
an invalid legacy
distinguished name (DN)
in Active Directory
Domain Services.
Examine and correct the
former DN of the
recipient's mailbox. Then
instruct the sender to
remove the recipient's
address from sender's
Outlook recipient cache
and then create a new
message. Resending the
original message will
result in the same
failure.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.1.2 Invalid X.400 The recipient has a non- Verify that the
address SMTP address that can't recipient's address was
be matched to a entered correctly. If the
destination. The address recipient's address is in a
does not appear to be non-SMTP email system
local, and there are no that you specifically
connectors configured want to provide mail
with address spaces that delivery to, you need to
contain the recipient's add the appropriate
address. type of connector to
your topology and
configure it to provide
service to the recipient's
email system.

5.1.3 Invalid recipient This message indicates Either the recipient's

address that the recipient's address is formatted
address appears incorrectly, or the
incorrectly on the recipient's address could
message. not be correctly
resolved. The first step
in resolving this error is
to check the recipient's
address and send the
message again.
Also, examine the SMTP
recipient policy, and
ensure that each mail
domain for which you
want to accept mail
appears correctly.

5.1.4 Destination mailbox Two or more recipients This error typically

address ambiguous in the Exchange occurs because of a
organization have the misconfiguration in
same address. Active Directory Domain
Services. Possibly
because of replication
problems, two recipient
objects in Active
Directory Domain
Services have the same
SMTP address or
Exchange Server (EX)
address.

5.1.7 Invalid address The sender has a Check the sender

malformed or missing directory structure, and
SMTP address, the mail determine if the mail
attribute in the directory attribute exists.
service. The mail item
cannot be delivered
without a valid mail
attribute.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.2.1 Mailbox cannot be The mailbox cannot be Check to see if the

accessed accessed. The mailbox recipient database is
may be offline, disabled, online, the recipient
or the message has mailbox is disabled, or
been quarantined by a the message has been
rule. quarantined.

5.2.2 Mailbox full The recipient's mailbox This error occurs when
has exceeded its storage the recipient's mailbox
quota and is no longer has exceeded its storage
able to accept new quota. The recipient
messages. must reduce the size of
the mailbox or the
administrator must
increase the storage
quota before delivery
can be successful.

5.2.3 Message too large The message is too Send the message again
large, and the local without attachments, or
quota is exceeded. For set the server or the
example, a remote client-side limit to allow
Exchange user might a larger message size
have a restriction on the limit.
maximum size of an
incoming message.

5.2.4 Mailing list The recipient is a Set the categorizer

expansion problem misconfigured dynamic event logging level to at
distribution list. Either least the minimum level,
the filter string or the and send another
base DN of the dynamic message to the dynamic
distribution list is invalid. distribution list. Check
the application event log
for a 6025 event or a
6026 event detailing
which attribute is
misconfigured on the
dynamic distribution list
object.

5.3.3 Unrecognized When the Exchange Ensure that the remote

command remote server reaches server has enough
capacity of its disk storage capacity to hold
storage to hold mail, it mail. Check the SMTP
could respond with this log.
NDR. This error usually
occurs when the
sending server is
sending mail with an
ESMTP BDAT command.
This error also indicates
a possible SMTP
protocol error.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.3.4 Message too big for The message exceeds a This error occurs when
system size limit configured on the size of the message
a transport or mailbox that was sent by the
database and can't be sender exceeds the
accepted. This failure can maximum allowed
be generated by either message size when
the sending email passing through a
system or the recipient transport component or
email system. mailbox database. The
sender must reduce the
size of the message for
the message to be
successfully delivered.
For more information
about how to configure
message size limits, see
Message size limits.

5.3.5 System incorrectly A mail-looping situation Check the configuration

configured was detected, which of the server's
means that the server is connectors for loops,
configured to loop mail and ensure that each
back to itself. connector is defined by
a unique incoming port.
If there are multiple
virtual servers, ensure
that none are set to "All
Unassigned."

5.4.4 Invalid arguments This NDR occurs if no Check that the domain
route exists for message name specified is valid
delivery, or if the and that a mail
categorizer could not exchanger (MX) record
determine the next-hop exists.
destination.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.4.6 Routing loop A configuration error This error occurs when

detected has caused an email the delivery of a
loop. By default, after 20 message generates
iterations of an email another message in
loop, Exchange response. That message
interrupts the loop and then generates a third
generates an NDR to message, and the
the sender of the process is repeated,
message. creating a loop. To help
protect against
exhausting system
resources, Exchange
interrupts the mail loop
after 20 iterations. Mail
loops are typically
created because of a
configuration error on
the sending mail server,
the receiving mail server,
or both. Check the
sender's and the
recipient's mailbox rules
configuration to
determine whether
automatic message
forwarding is enabled.

5.5.2 Send hello first A generic SMTP error View the SMTP Log or a
occurs when SMTP Netmon trace, and
commands are sent out ensure that there is
of sequence. For adequate disk storage
example, a server and virtual memory
attempts to send an available.
AUTH (authorization)
command before
identifying itself with an
EHLO command.
It is possible that this
error can also occur
when the system disk is
full.

5.5.3 Too many recipients The combined total of This error occurs when
recipients on the To, Cc, the sender has included
and Bcc lines of the too many recipients on
message exceeds the the message. The sender
total number of must reduce the
recipients allowed in a number of recipient
single message. addresses in the
message or the
maximum number of
recipients must be
increased to allow the
message to be
successfully delivered.
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.5.4 Invalid domain name The message contains Check the recipient's
either an invalid sender address for nonstandard
or an incorrect recipient characters.
address format.
One possible cause is
that the recipient
address format might
contain characters that
are not conforming to
Internet standards.

5.5.6 Invalid message This message indicates a Check Event Log for
content possible protocol error. possible failures.

5.7.1 Delivery not The sender of the This error occurs when
authorized message is not allowed the sender tries to send
to send messages to the a message to a recipient
recipient. but the sender is not
authorized to do this.
This frequently occurs
when a sender tries to
send messages to a
distribution group that
has been configured to
accept messages only
from members of that
distribution group or
other authorized
senders. The sender
must request permission
to send messages to the
recipient.
This error can also occur
if an Exchange transport
rule rejects a message
because the message
matched conditions that
are configured on the
transport rule.

5.7.1 Unable to relay The sending email This error occurs when
system is not allowed to the sending email
send a message to an system tries to send an
email system where that anonymous message to
email system is not the a receiving email system,
final destination of the and the receiving email
message. system does not accept
messages for the
domain or domains
specified in one or more
of the recipients. The
following are the most
common reasons for
this error:
A third party
tries to use a
 receiving email
ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION
system to send
spam, and the
receiving email
system rejects
the attempt. By
the nature of
spam, the
sender's email
address might
have been
forged, and the
resulting NDR
could have been
sent to the
unsuspecting
sender's email
address. It is
difficult to avoid
this situation.
An MX record for
a domain points
to a receiving
email system
where that
domain is not
accepted. The
administrator
responsible for
the specific
domain name
must correct the
MX record or
configure the
receiving email
system to accept
messages sent to
that domain, or
both.
A sending email
system or client
that should use
the receiving
email system to
relay messages
does not have
the correct
permissions to
do this.
 ENHANCED STATUS CODE DESCRIPTION POSSIBLE CAUSE ADDITIONAL INFORMATION

5.7.1 Client was not The sending email This error occurs when
authenticated system did not the receiving server
authenticate with the must be authenticated
receiving email system. before message
The receiving email submission, and the
system requires sending email system
authentication before has not authenticated
message submission. with the receiving email
system. The sending
email system
administrator must
configure the sending
email system to
authenticate with the
receiving email system
for delivery to be
successful. This error can
also occur if you try to
accept anonymous
messages from the
Internet on a Mailbox
server that has not been
configured to do this.

5.7.3 Not Authorized The sender prohibited

reassignment to the
alternate recipient.

NDR sections
In Exchange 2013, NDRs are designed to be easy to read and understand by both end users and administrators.
Information that is displayed in an NDR is separated into the following two areas:
A user information section
A administrator information section
The information in each section is targeted to the readers of that section. The user information section appears
first and contains feedback to help the user understand in nontechnical terms why the delivery of the message
failed. The Diagnostic information for administrators section provides deeper technical information, such as
the original message headers, which help email administrators troubleshoot a delivery issue. The following figure
shows the user information section and Diagnostic information for administrators section of an NDR.
NDR Sections
User information section
The user information section of an NDR generated by Exchange contains information that you want to
communicate to an end user who has sent a message that is later returned with an NDR. The text that is displayed
in this section is inserted by the Exchange server that generated the NDR.
The text in the user information section is designed to help end users determine why the message was rejected
and how to resend the message successfully if the message should be resent. When applicable, the fully qualified
domain name (FQDN ) of the server that rejected the message is included in the user information section. If
delivery fails to more than one recipient, the email address of each recipient is listed and the reason for the failure
is included in the space below the recipient's email address.
You can modify the text in the user information section by using the New-SystemMessage cmdlet. By creating a
custom message, you can provide specific information to end users, such as a telephone number to use to contact
the helpdesk department or a hyperlink to use to obtain self-service support.

Diagnostic information for administrators

The Diagnostic information for administrators section contains more detailed information about the specific
error that occurred during delivery of the message, the server that generated the NDR, and the server that
rejected the message. The following fields are present in most NDRs and are visible in the "NDR sections" figure
earlier in this topic:
Generating server: The generating server is the SMTP server that created the NDR. The generating
server takes the enhanced status code that is explained later in this topic. This code creates an easy-to-read
NDR. If no remote server is listed below the email address of the sender in the Diagnostic information
for administrators section, the generating server is also the server that rejected the original email
 message. If message delivery fails when the message is sent to another recipient in the Exchange
organization, the same server typically rejects the original message and generates the NDR.
Rejected recipient: The rejected recipient is the email address of the recipient to which delivery of the
original message failed. If delivery to more than one recipient has failed, the email address for each
recipient is listed. The rejected recipient field also contains the following subfields for each email address
listed:
Remote server: The remote server field contains the FQDN of the server that rejects delivery of the
message during the SMTP conversation. The remote server field is only populated when delivery
has been attempted to a remote server, and that delivery attempt has been rejected before the
receiving server successfully acknowledges the message after the message body is sent. If the
original message is successfully acknowledged by the receiving server and is then rejected because
of content restrictions, for example, the remote server field is not populated.
Enhanced status code: The enhanced status code is the code returned by the server that rejected
the original message. The enhanced status code indicates why the original message was rejected.
The enhanced status code is not rewritten by Exchange but is used to determine what text to display
in the user information section. The enhanced status codes you're most likely to encounter are listed
in "Common Enhanced Status Codes" later in this topic. For a detailed list of enhanced status codes,
see RFC 3463.
SMTP response: The SMTP response is the machine readable text returned by the server that
rejected the original message. The SMTP response typically contains a short string that provides an
explanation of the enhanced status code that is also returned. The SMTP response is not rewritten by
Exchange. Additionally, this response is always presented in US -ASCII format.
Original message headers: The original message headers section contains the message headers of the
rejected message. These headers can provide useful diagnostic information, such as information that can
help you determine the path that the message took before it was rejected or whether the To field matches
the email address that is specified in the rejected recipient field.

Examples of NDR messages

The following sections provide examples of two ways that NDR messages can be generated:
By the same server
By different servers

NDR generated and original message rejected by the same server

The following example shows what happens when a remote email organization accepts delivery of an email
message through an Edge Transport server, and then rejects that message because of a policy restriction on the
recipient's mailbox. In this case, the sender is not allowed to send messages to the recipient. Edge Transport
servers do not perform message size validation so the Edge Transport server in this example accepts the message
because it has a valid recipient address and the message does not violate another content restrictions. Because the
remote email organization accepts the whole message, including the message contents, the remote email
organization is responsible for rejecting the message and for generating the NDR message to be sent to the
sender.
NDR generated and message rejected by the same server
Also, messages that are rejected when they are sent to recipients that are part of the same Exchange organization
are typically rejected by the same email server that generates the NDR message. Messages sent to local recipients
can be rejected for various reasons, such as mailboxes that have exceeded their quota, lack of authorization to
send messages to the recipient address, or hardware failures that result in an extended loss of connectivity to
other servers in the organization.
In both situations, no remote server is included under the email address of the recipients listed in the NDR
message.

NDR generated and original message rejected by different servers

The following example shows what happens when a remote email organization rejects delivery of an email
message before it ever accepts the message. In this example, the remote server rejects the message and returns an
enhanced status code to the local sending server because the specified recipient does not exist. The rejection
happens before the receiving server ever acknowledges the message. Because the receiving server doesn't
successfully acknowledge the message, the receiving server is not responsible for the message. Therefore, the
local sending server generates the NDR message and sends it to the sender of the original message.
NDR generated and message rejected by different servers
See Also
What are Exchange NDRs in Exchange Online and Office 365
 Manage DSN messages
6/10/2019 • 5 minutes to read • Edit Online

Applies to: Exchange Server 2013

Microsoft Exchange Server 2013 uses delivery status notifications (DSN ) to provide non-delivery reports (NDRs)
and other status messages to message senders. You can use the built-in DSNs, or you can create custom DSN
messages to meet the needs of your organization.

What do you need to know before you begin?

Estimated time to complete: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "DSNs" entry in the Mail flow permissions topic.
You can't remove a built-in DSN message that's included with Exchange. To change a built-in DSN message,
you need to create a custom DSN message for the DSN code that you want to customize. When you
remove a custom DSN message, the DSN code associated with that message reverts to the built-in DSN
message that's included with Exchange.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

Use the Shell to view built-in and custom DSN messages

To view a summary list of all built-in DSN messages included with Exchange 2013, run the following command:

Get-SystemMessage -Original

To view a summary list of all custom DSN messages in your organization, run the following command:

Get-SystemMessage

To view detailed information for the custom DSN message for DSN code 5.1.2 that's sent to internal senders in
English, run the following command:

Get-SystemMessage En\Internal\5.1.2 | Format-List

Use the Shell to create a custom DSN message

Run the following command:
 New-SystemMessage -Internal <$true | $false> -Language <Locale> -DSNCode <x.y.z> -Text "<DSN text>"

This example creates a custom plain text DSN message for the DSN code 5.1.2 that's sent to internal senders in
English.

New-SystemMessage -Internal $true -Language En -DSNCode 5.1.2 -Text "You tried to send a message to a disabled
mailbox that's no longer accepting messages. Please contact the Help Desk at extension 123 for assistance."

This example creates a custom plain text DSN message for the DSN code 5.1.2 that's sent to external senders in
English.

New-SystemMessage -Internal $false -Language En -DSNCode 5.1.2 -Text "You tried to send a message to a disabled
mailbox that's no longer accepting messages. Please contact your System Administrator for more information."

This example creates a custom HTML DSN message for the DSN code 5.1.2 that's sent to internal senders in
English.

New-SystemMessage -DSNCode 5.1.2 -Internal $true -Language En -Text 'You tried to send a message to a
<B>disabled</B> mailbox. Please visit <A HREF="http://it.contoso.com">Internal Support</A> or contact
&quot;InfoSec&quot; for more information.'

How do you know this worked?

To verify that you have successfully created a custom DNS message, do the following:
1. Run the following command:

Get-SystemMessge -DSNCode <x.y.z> | Format-List Name,Internal,Text,Language

2. Verify the values you see are the values you configured.
3. Send a test message that will generate the custom DSN you configured.

Use the Shell to change the text of a custom DSN message

To change the text of a custom DSN message the following command:

Set-SystemMessage <Locale>\<Internal | External>\<DSNcode> -Text "<DSN text>"

This example changes the text assigned to the custom DSN message for DSN code 5.1.2 that's sent to internal
senders in English.

Set-SystemMessage En\Internal\5.1.2 -Text "The mailbox you tried to send an e-mail message to is disabled and
is no longer accepting messages. Please contact the Help Desk at extension 123 for assistance."

How do you know this worked?

To verify that you have successfully changed the text of a custom DNS message, do the following:
1. Run the following command: Get-SystemMessage .
 Set-SystemMessage <Locale>\<Internal | External>\<DSNcode> | Format-List -Text

2. Verify the value displayed is the value you configured.

Use the Shell to remove a custom DSN message

Run the following command:

Remove-SystemMessage <Local>\<Internal | External>\<DSNcode>

This example removes the custom DSN message for the DSN code 5.1.2 that's sent to internal senders in English.

Remove-SystemMessage En\Internal\5.1.2

How do you know this worked?

To verify that you have successfully removed a custom DNS message, do the following:
1. Run the command: Get-SystemMessage .
2. Verify a DSN for the locale, internal or external recipients, and DSN code you deleted isn't listed.

Forward copies of DSN messages to the Exchange recipient mailbox

You can specify a list of DSN codes that you want to monitor by having the DSN messages copied to the mailbox
of the Exchange recipient. However, by default, no mailbox is assigned to the Exchange recipient, so any messages
sent to the Exchange recipient are discarded. To send copies of DSN messages to the Exchange recipient mailbox,
you need to assign a mailbox to the Exchange recipient, and then specific the DSN codes you want to monitor. By
default, the following DSN codes are monitored: 5.4.8 , 5.4.6 , 5.4.4 , 5.2.4 , 5.2.0 , and 5.1.4 .

Step 1: Use the Shell to assign a mailbox to the Exchange recipient

To assign a mailbox to the Exchange recipient, perform the following steps:
1. Due to the potentially high volume of email, consider creating a dedicated mailbox and Active Directory user
account for the Exchange recipient. For more information, see Create user mailboxes. Otherwise, identify the
existing mailbox you want to associate with the Exchange recipient.
2. Run the following command:

Set-OrganizationConfig -MicrosoftExchangeRecipientReplyRecipient <MailboxIdentity>

For example, to assign the existing mailbox named "Contoso System Mailbox" to the Exchange recipient, run
the following command:

Set-OrganizationConfig -MicrosoftExchangeRecipientReplyRecipient "Contoso System Mailbox"

Step 2: Specify the DSN codes you want to monitor

Use the EAC to specify the DSN codes
1. In the EAC, navigate to Mail flow > Receive connectors > More options > Organization transport
settings > Delivery.
2. In the DNS codes section, type the DSN codes you want to monitor using the format <x.y.z>, and click Add
. Select an existing entry and click Edit to modify it, or click Remove to remove it. When you are
finished, click Save.

Use the Shell to specify the DSN codes

To replace the existing values, run the following command:

Set-TransportConfig -GenerateCopyOfDSNFor <x.y.z>,<x.y.z>...

This example configures the Exchange organization to forward all DSN messages that have the DSN codes 5.7.1,
5.7.2, and 5.7.3 to the Exchange recipient.

Set-TransportConfig -GenerateCopyOfDSNFor 5.7.1,5.7.2,5.7.3

To add or remove entries without modifying any existing values, run the following command:

Set-TransportConfig -GenerateCopyOfDSNFor @{Add="<x.y.z>","<x.y.z>"...; Remove="<x.y.z>","<x.y.z>"...}

This example adds the DSN code 5.7.5 and removes the DSN code 5.7.1 from the existing list of DSN messages
that are forwarded to the Exchange recipient.

Set-TransportConfig -GenerateCopyOfDSNFor @{Add="5.7.5"; Remove="5.7.1"}

How do you know this worked?

To verify that you successfully configured copies of DNS messages to be sent to the mailbox of the Exchange
recipient, monitor the mailbox that's associated with the Exchange recipient, and verify the DSN messages contain
the DSN codes you specified.
 DSN message identity
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can identify a customized delivery status notification (DSN ) message based on its syntax. The identity is the
customized DSN message's GUID or a string that consists of the following values:
Locale: This variable specifies the locale of the language that the DSN message is displayed in. For a list of
locale codes that you can use with the New-SystemMessage command, see Supported languages for
system messages.
Internal or External: This variable specifies whether the DSN message is sent only to senders who are
part of the internal Microsoft Exchange Server 2013 organization or also to senders outside the Exchange
organization. You can use the Internal option when you want to include a specific e-mail contact or
resolution in DSN messages sent to internal senders, but don't want to expose that information to senders
outside your organization.
DSN code: This variable specifies the DSN code of the customized DSN message.
The syntax of the DSN message identity is <Locale>\<Internal or External>\<DSN code> .
For each DSN code, you can create more than one customized DSN message, which can target internal senders or
external senders, and different locales. For example, the following table shows some of the possible configurations
for the DSN code 5.1.2 and the corresponding DSN message identities.
Example DSN configurations and identities
DSN CONFIGURATION DSN IDENTITY

Display DSN messages to internal senders with an English En\Internal\5.1.2

(en) locale

Display DSN messages to external senders with an English En\External\5.1.2

(en) locale

Display DSN messages to internal senders with a Japanese Ja\Internal\5.1.2

(ja) locale

Display DSN messages to external senders with a Ja\External\5.1.2

Japanese (ja) locale
 DSN message text
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can include text in a customized delivery status notification (DSN ) message in Microsoft Exchange Server
2013, and you can format that text in HTML.
You can include any information that you want to display to the recipient of the DSN message. For example, you
can include a detailed description of the DSN, contact information for your help desk, and a link to your support
department's Web site. Each DSN message can contain a maximum of 512 characters.
Because DSN messages can be displayed in HTML, you can embed HTML formatting tags in the DSN text. For
example, if you want to make some text in your DSN message bold, enclose the text in <B> and </B> HTML tags.
The following table provides some examples of valid HTML tags that can be used in DSN message text.
Valid HTML tags for use in DSN messages
HTML TAG DESCRIPTION

<B> Bold begin

</B> Bold end

<A HREF="url"> Hyperlink begin

</A> Hyperlink end

<BR> Link break

<EM> Italic begin

</EM> Italic end

<P> Paragraph begin

</P> Paragraph end

 NOTE
By default, Exchange sends HTML DSN messages, but you can configure whether Exchange sends HTML DSN messages to
internal senders, external senders, or both. To configure this behavior, modify the InternalDsnSendHtml parameter and the
ExternalDsnSendHtml parameter with the Set-TransportService command.
If the InternalDsnSendHtml parameter is set to $false , Exchange suppresses HTML tags in DSN messages sent to internal
senders. If the ExternalDsnSendHtml parameter is set to $false , Exchange suppresses HTML tags in DSN messages sent to
external senders.

The following characters that Exchange uses in DSN message text have special meanings:
Greater than sign (>)
Less than sign (<)
Ampersand (&)
Quotation marks (")
These characters are used to determine where HTML tags begin and end, and where text that should be displayed
to senders starts and stops. If you want to display these characters in your DSN messages, you must use the
escape codes in the following table.
For example, if you want to display the message "Please contact the Help Desk at <1234>." , you must add
"Please contact the Help Desk at &lt;1234&gt;." to the DSN message text.
DSN message character escape codes
ESCAPE CODE CHARACTER

&lt; <

&gt; >

&quot; "

&amp; &

IMPORTANT
If you include an HTML tag in your DSN message text that contains quotation marks ("), such as <A HREF="url"> , you must
use single quotation marks (') around the whole DSN message text. You will receive an error message if you use double
quotation marks around the whole DSN message text and around an HTML tag.
 Supported languages for system messages
5/28/2019 • 2 minutes to read • Edit Online

Applies to: Exchange Server 2013

The following table lists the supported language codes you can use with the New-SystemMessage cmdlet.

LANGUAGE CODE LANGUAGE

af Afrikaans

am-ET Amharic (Ethiopia)

ar Arabic

as-IN Assamese (India)

bg Bulgarian

bn-BD Bengali (Bangladesh)

bn-IN Bengali (India)

bs-Cyrl-BA Bosnian (Cyrillic, Bosnia and Herzegovina)

bs-Latn-BA Bosnian (Latin, Bosnia and Herzegovina)

ca Catalan

cs Czech

cy-GB Welsh (Great Britain)

da Danish

de German

el Greek
LANGUAGE CODE LANGUAGE

en English

es Spanish

et Estonian

eu Basque

fa Persian

fi Finnish

fil-PH Filipino (Philippines)

fr French

ga-IE Irish (Ireland)

gl Galician

gu Gujarati

ha-Latn-NG Hausa (Latin, Nigeria)

he Hebrew

hi Hindi

hr Croatian

hu Hungarian

hy Armenian

id Indonesian

ig-NG Igbo (Nigeria)

LANGUAGE CODE LANGUAGE

is Icelandic

it Italian

iu-Latn-CA Inuktitut (Latin, Canada)

ja Japanese

ka Georgian

kk Kazakh

km-KH Khmer (Cambodia)

kn Kannada

ko Korean

kok Konkani

ky Kyrgyz

lb-LU Luxembourgish (Luxembourg)

lo-LA Lao (Lao People's Democratic Republic)

lt Lithuanian

lv Latvian

mi-NZ Maori (New Zealand)

mk Macedonian

ml-IN Malayalam (India)

mr Marathi
LANGUAGE CODE LANGUAGE

ms Malay

ms-BN Malay (Brunei Darussalam)

mt-MT Maltese (Malta)

ne-NP Nepali (Nepal)

nl Dutch

nn-NO Norwegian (Nynorsk)

no Norwegian

nso-ZA Sesotho sa Leboa (South Africa)

or-IN Oriya (India)

pa Punjabi

pl Polish

ps-AF Pashto (Afghanistan)

pt Portuguese

pt-PT Portuguese (Portugal)

qut-GT K'iche (Guatemala)

quz-PE Quechua (Peru)

ro Romanian

ru Russian

rw-RW Kinyarwanda (Rwanda)

LANGUAGE CODE LANGUAGE

si-LK Sinhala (Sri Lanka)

sk Slovak

sl Slovenian

sq Albanian

sr Serbian

sr-Cyrl-CS Serbian (Cyrillic, Serbia)

sv Swedish

sw Kiswahili

ta Tamil

te Telugu

th Thai

tn-ZA Setswana (South Africa)

tr Turkish

tt Tatar

uk Ukrainian

ur Urdu

uz Uzbek

vi Vietnamese

wo-SN Wolof (Senegal)

LANGUAGE CODE LANGUAGE

xh-ZA isiXhosa (South Africa)

yo-NG Yoruba (Nigeria)

zh-Hans Chinese (Simplified)

zh-Hant Chinese (Traditional)

zh-HK Chinese (Hong Kong)

zu-ZA isiZulu (South Africa)

 Message size limits
6/14/2019 • 9 minutes to read • Edit Online

Applies to: Exchange Server 2013

You can apply limits to messages that move through the Microsoft Exchange Server 2013 organization. You can
restrict the total size of a message or the size of the individual components of a message, such as the message
header, the message attachments, and the number of recipients. You can apply limits globally for the whole
Exchange organization, or specifically to a connector or user object.
As you plan the message size limits for your Exchange organization, consider the following questions:
What size limits should I impose on all incoming messages?
What size limits should I impose on all outgoing messages?
What is the mailbox quota for my Exchange organization?
How do the message size limits that I have chosen relate to the mailbox quota size?
Are there users in my Exchange organization who must send or receive messages that are larger than the
specified allowed size?
Does my Exchange network topology include other messaging systems or distinctly separate business
units that have different message size limits?
This topic provides guidance to help you answer these questions.

Types of message size limits

Following are the basic categories of the size limits available for individual messages:
Message header size limits: These limits apply to the total size of all message header fields that are
present in a message. The size of the message body or attachments isn't considered. Because the header
fields are plain text, the size of the header is determined by the number of characters in each header field
and by the total number of header fields. Each character of text consumes 1 byte.

NOTE
Some third-party firewalls or proxy servers apply their own message header size limits. These third-party firewalls or
proxy servers may have difficulty processing messages that contain attachment file names that are greater than
50 characters or attachment file names that contain non-US-ASCII characters.

Message size limits: These limits apply to the total size of a message, which includes the message header,
the message body, and any attachments. Message size limits may be imposed on incoming messages or
outgoing messages. For internal message flow, Exchange uses the custom
X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the
message as it enters the Exchange organization. Whenever the message is checked against the specified
message size limits, the lower value of the current message size or the original message size header is
used. The size of the message can change because of content conversion, encoding, and agent processing.
Attachment size limits: These limits apply to the maximum allowed size of a single attachment within a
message. The message may contain many attachments that greatly increase the overall size of the
 message. However, an attachment size limit applies to the size of an individual attachment only.
Recipient limits: These limits apply to the total number of message recipients. When a message is first
composed, the recipients exist in the To: , Cc: , and Bcc: header fields. When the message is submitted
for delivery, the message recipients are converted into RCPT TO: entries in the message envelope. A
distribution group is counted as a single recipient during message submission.

Scope of limits
Following are the basic categories for the scope of the limits available for individual messages:
Organizational limits: These limits apply to all Exchange 2013 Mailbox servers and Exchange 2010 and
Exchange 2007 Hub Transport servers that exist in the organization. If you have an Edge Transport server
installed in the perimeter network, the specified limits apply to the specific server.
Connector limits: These limits apply to any messages that use the specified Send connector, Receive
connector, Delivery Agent connector, or Foreign connector for message delivery. Send connectors are
defined in the Transport service on Mailbox servers and on Edge Transport servers. Receive connectors are
defined in the Transport service on Mailbox servers, in the Front End Transport service on Client Access
servers, and on Edge Transport servers.
Active Directory site links: The Transport service on Mailbox servers use Active Directory sites and the
costs that are assigned to the Active Directory IP site links as one of the factors to determine the least-cost
routing path between Mailbox servers in the organization. You can assign specific message size limits to
the Active Directory site links in your organization.
Server limits: These limits apply to a specific Mailbox server or Edge Transport server. You can set the
specified message limits independently on each Mailbox server or Edge Transport server.
In Outlook Web App, the maximum HTTP request size limit setting on the Client Access servers also
controls the size of messages that Outlook Web App users can send.
User limits: These limits apply to a specific user object, such as a mailbox, contact, distribution group, or
public folder.
The following tables show the message limits, including information about how to configure the limits in the
Exchange Management Shell or the Exchange Administrator Center (EAC ).
Organizational limits
SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum size for 10 MB Cmdlet: Set- Mail flow > Receive

messages received TransportConfig connectors > More
options >
Parameter: Organization
MaxReceiveSize transport settings >
Limits tab > Maximum
receive message size

Maximum size for 10 MB Cmdlet: Set- Mail flow > Receive

messages sent TransportConfig connectors > More
options >
Parameter: MaxSendSize Organization
transport settings >
Limits tab > Maximum
send message size
 SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum number of 5000 Cmdlet: Set- Mail flow > Receive

recipients per message TransportConfig connectors > More
options >
Parameter: Organization
MaxRecipientEnvelopeLi transport settings >
mit Limits tab > Maximum
number of recipients

Maximum attachment Not configured Cmdlets: New- Mail flow > Rules >
size in Transport rules TransportRule, Set- Add or Edit .
that apply to all Mailbox TransportRule
servers in the Use the predicate
organization Parameter: Apply this rule if >
AttachmentSizeOver Any attachment > is
greater than or equal
to
Use the predicate
Apply this rule if >
The message > size is
greater than or equal
to

Maximum message size Cmdlets: New- Mail flow > Rules >
in Transport rules that TransportRule, Set- Add or Edit .
apply to all Mailbox TransportRule
servers in the Use the predicate
organization Parameter: Apply this rule if >
MessageSizeOver The message > size is
greater than or equal
to

Connector limits
SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum header size 128 KB Cmdlets: New- N/A

through a Receive ReceiveConnector,
connector Set-ReceiveConnector
Parameter:
MaxHeaderSize
SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum message size Transport service on Cmdlets: New- Mail flow > Receive
through a Receive Mailbox servers ReceiveConnector, connectors > Edit >
connector Set-ReceiveConnector General tab >
35 MB for the Default Maximum receive
and Client Proxy Receive Parameter: message size
NOTE connectors MaxMessageSize
The actual message
Front End Transport
size may be smaller
service on Client
due to message
Access servers
encoding and
content conversion. 36 MB for the Default
Frontend and
Outbound Proxy
Frontend Receive
connectors.
35 MB for the Client
Frontend Receive
connector.

Maximum number of Transport service on Cmdlets: New- N/A

recipients per message Mailbox servers ReceiveConnector,
through a Receive Set-ReceiveConnector
connector 5,000 for the Default
Receive connector Parameter:
MaxRecipientsPerMessa
200 for the Client Proxy ge
Receive connector
Front End Transport
service on Client
Access servers
200 for the Default
Frontend, Client
Frontend, and Client
Proxy Frontend Receive
connectors.

NOTE
If the number of
recipients is
exceeded for an
anonymous sender,
the message is
accepted for the first
200 recipients. Most
SMTP messaging
servers detect that a
recipient limit is in
effect. The SMTP
messaging server
continues to resend
the message in
groups of
200 recipients until
the message is
delivered to all
recipients.
 SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum message size 10 MB Cmdlets: New- Mail flow > Send

through a Send SendConnector, Set- connectors > Edit >
connector SendConnector General tab >
Maximum send
Parameter: message size
MaxMessageSize

Maximum message size Unlimited Cmdlet: Set-AdSiteLink N/A

through an Active
Directory site link Parameter:
MaxMessageSize

Maximum message size Unlimited Cmdlets: New- N/A

through a delivery DeliveryAgentConnect
agent connector or, Set-
DeliveryAgentConnect
or
Parameter:
MaxMessageSize

Maximum message size Unlimited Cmdlet: Set- N/A

through a foreign ForeignConnector
connector Parameter:
MaxMessageSize

Server limits
SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum header size 64 KB Cmdlet: Set- N/A

for messages in the TransportService
pickup directory
Parameter:
PickupDirectoryMaxHea
derSize

Maximum number of 100 Cmdlet: Set- N/A

recipients per message TransportService
for messages in the
pickup directory Parameter:
PickupDirectoryMaxReci
pientsPerMessage
 SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Client-specific maximum Outlook Web You configure these N/A

messages size limits for App 35 MB values in the
Outlook Web App, appropriate web.config
Exchange ActiveSync, Exchange XML application
and Exchange Web ActiveSync 10 MB configuration file on
Services clients Exchange Web Client Access servers.
Services 64 MB For more information,
see Configure client-
specific message size
NOTE limits.
These values are
approximately 33%
larger than the actual
usable maximum
message size
because of the
overhead that's
associated with
Base64 encoding.

User limits
SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum message size Unlimited Cmdlets: For mailboxes:

that can be sent by this
recipient Set-DistributionGroup Recipients >
Mailboxes > Edit >
Set- Mailbox features >
DynamicDistributionG Mail flow > Message
roup size restrictions >
Set-Mailbox View details > Sent
messages
Set-MailContact
Set-MailUser NOTE
Set-MailPublicFolder This setting isn't
configurable using
Set-RemoteMailbox the EAC for other
recipient types.
Parameter: MaxSendSize
 SIZE LIMIT DEFAULT VALUE SHELL CONFIGURATION EAC CONFIGURATION

Maximum message size Unlimited Cmdlets: For mailboxes:

that can be sent to this
recipient For site mailbox Set-DistributionGroup Recipients >
provisioning policies: Mailboxes > Edit >
36 MB Set- Mailbox features >
DynamicDistributionG Mail flow > Message
roup size restrictions >
Set-Mailbox View details >
Received messages
Set-MailContact
Set-MailUser NOTE
Set-MailPublicFolder This setting isn't
configurable using
New- the EAC for other
SiteMailboxProvisioni recipient types.
ngPolicy
Set-
SiteMailboxProvisioni
ngPolicy
Parameter:
MaxReceiveSize

Maximum number of Unlimited Cmdlets: N/A

recipients per message
sent by this recipient Set-Mailbox, Set-
MailUser
Parameter:
RecipientLimits

Order of precedence for message size limits

You can set different message size limits at different levels in the Exchange organization. As a message is routed
through your Transport infrastructure, it may be subjected to several different message size restrictions. You
should plan your message size restrictions in a way that makes sure that messages in the transport pipeline are
rejected as early as possible if they violate message size limits. Generally speaking, you should set more
restrictive limits at the points where messages enter your infrastructure. For example, any message size
restrictions on your Receive connectors that receive messages from the Internet should be less than or equal to
the message size restrictions you configure for your internal Exchange organization. It would be a waste of
system resources for the Exchange server to accept and process a message from the Internet that would be
rejected by the Transport service on your Mailbox servers. Make sure that your organization, server, and
connector limits are configured in a way that minimizes any unnecessary processing of messages.
One exception to this approach is the user limits. User level limits take precedence over other message size
restrictions. Therefore, you can configure a user to exceed the default message size limits for your organization.
For example, you can allow a specific group of user mailboxes to send larger messages than the rest of the
organization by configuring custom send and receive limits for those mailboxes.
The exceptions for the user limits only apply to message exchanges between authenticated users. If a message is
sent to or received by a recipient on the Internet, the organizational limits will be applied. For example, assume
that you have an organizational message size restriction of 10 MB, but you have configured the users in your
marketing department to send and receive messages up to 50 MB. These users will be able to exchange large
messages with each other, but they still won't be able to receive large messages from Internet users because such
messages will be coming from unauthenticated senders.
Messages exempt from size limits
The following list shows the types of messages generated by a Mailbox server or an Edge Transport server and
exempted from all message size limits:
System messages
Agent-generated message
Delivery status notification (DSN ) messages
Journal report messages
Quarantined messages
However, these messages are still subject to the organizational value for maximum number of recipients in a
message.
 Message throttling
6/14/2019 • 12 minutes to read • Edit Online

Applies to: Exchange Server 2013

Message throttling refers to a group of limits that are set on the number of messages and connections that can be
processed by a Microsoft Exchange Server 2013 computer. These limits prevent the accidental or intentional
exhaustion of system resources on the Exchange server.

Message throttling scope

Message throttling involves a variety of limits on message processing rates, SMTP connection rates, and SMTP
session time-out values. These limits work together to protect an Exchange server from being overwhelmed by
accepting and delivering messages. Although a large backlog of messages and connections may be waiting to be
processed, the message throttling limits enable the Exchange server to process the messages and connections in an
orderly manner.
In addition to message throttling, you can also put size limits on the individual components of messages, such as
the number of recipients, the size of the message header, or the size of individual attachments. For more
information about message size limits, see Message size limits.
Another feature that helps avoid overwhelming the system resources of an Exchange transport server is back
pressure. Back pressure is a system resource monitoring feature in the Transport service on Mailbox servers and on
Edge Transport servers. When a monitored system resource, such as hard disk utilization or memory utilization,
exceeds the specified threshold, the server reduces the rate at which it accepts new connections and messages, and
focuses on delivering existing messages. When the utilization of the monitored system resources returns to normal
levels, the server slowly increases the rate at which it accepts new connections and then establishes a normal level.

Message cost and mail flow throttling

To provide more consistent message throughput and predictable message delivery latency, Exchange 2013
establishes an accumulated cost for messages. This quality of service (QoS ) feature was added in Microsoft
Exchange Server 2010 SP1This cost is based on the following criteria:
Message size
Number of recipients
Frequency of transmission
Exchange 2013 transport servers track the average delivery cost of messages that are sent by individual users. By
using message costs, Exchange 2013 provides a group of settings that can control the effect that a user or
connection has on an Exchange organization. This group of settings is known as a throttling policy. When a user
repeatedly sends costly messages, such as messages that have large attachments or messages that are sent to
many recipients, the Exchange 2013-based transport servers use a throttling policy to assign a lower priority to
higher-cost messages from the user while continuing to deliver lower-cost messages. This new behavior adds a
"quality of service" aspect to the message throttling functionality in Exchange 2013.
 NOTE
Message throttling doesn't affect the message priority from a user's perspective. Messages still retain the original priority set
by the user. For example, messages retain a setting of Important or Urgent, and so on.

To support this functionality, Exchange 2013 uses the following mechanisms:

Internal prioritization agent: This agent is triggered on the OnResolvedMessage event and assigns a
lower priority to messages from the same sender that have a high accumulated cost. This cost is measured
over a period of one minute and affects messages that have more than 500 recipients or that are larger than
1 megabyte (MB ).
Quota-based priority queuing for the MapiDelivery queue type: This mechanism causes Exchange to
deliver messages in a normal-priority queue more frequently than messages in a low -priority queue. By
default, the normal-to-low message ratio is 20:1. However, new messages from a lower priority queue are
never delivered sooner than new items from a higher priority queue. For example, consider the following
scenario:
1. Twenty normal priority messages are delivered. By default, the next delivered message is a lower
priority message.
2. Two new messages are received by the transport server: One message from a higher priority queue
and one message from a lower priority queue.
In this scenario, the message from the higher priority queue is delivered first. Then, the message from the
lower priority queue is delivered.
Throttle concurrent connections based on messaging database health: This mechanism monitors the
health of the Exchange messaging database (MDB ) health and throttles concurrent connections to Exchange
transport servers based on an assigned Health Measure value. The MDB is monitored by the Resource
Health Monitor API in the Transport service on the Mailbox server and is assigned a health value from -1
through 100. This value is based on the RPC performance statistics that are included with each RPC
response from the Store.exe process in the Mailbox Transport service. The Resource Health framework uses
both the Requests/Second rate performance counter and the Average RPC Latency performance counter
to calculate a health value for the database. To help maintain a consistent interactive user experience,
Exchange reduces the number of concurrent connections as the health value decreases. The following health
value ranges are available:
-1: This value indicates that the MDB health state is unknown. This value is assigned when the
database starts. In this scenario, the database is considered healthy.
0: This value is assigned if the database is in an unhealthy state. In this state, the database should not
be contacted.
1 through 99: These values represent a fair health state. A lower value represents a less healthy
database.
100: This value represents a healthy database.
The Microsoft Exchange Throttling service provides the framework for mail flow throttling. The Microsoft
Exchange Throttling service keeps track of mail flow throttling settings for a specific user and caches the throttling
information in memory. Mail flow throttling settings are also known as a budget. Restarting the Microsoft
Exchange Throttling service also resets mail flow throttling budgets.
You can use the throttling policy cmdlets that are available in Exchange 2013 to configure individual budget
settings for a throttling policy. A budget is the amount of access that a user or application may have for a specific
setting. A budget represents how many connections a user may have or how much activity a user may be
permitted for each one-minute period. For example, a budget may be configured to set the amount of time that a
user may spend using a specific feature in Exchange, such as ActiveSync, Outlook Web App, or Exchange Web
Services. This threshold is stored in a throttling policy and defines the budget.
Time settings for a budget are set as a percentage of one minute. Therefore, a threshold of 100 percent represents
60 seconds. For example, assume that you want to specify Outlook Web App policy settings that limit the amount
of time during which a user may run Outlook Web App code on a Client Access server and the amount of time the
user may communicate with the Client Access server to 600 milliseconds over a one-minute period. To accomplish
this, you need to set the value to 1 percent of one minute (600 milliseconds) for both of the following parameters:
OWAPercentTimeInCAS: 1
OWAPercentTimeInMailboxRPC: 1
A user who has this policy applied has a budget of OWAPercentTimeInCAS of 600 milliseconds and of
OWAPercentageTimeInMailboxRPC of 600 milliseconds. In this scenario, when the user is logged into Outlook
Web App, the user can run Client Access code for up to 600 milliseconds. After the 600 millisecond-period, the
connection is considered over budget and the Exchange server doesn't allow any further Outlook Web App action
until one minute after the budget limit is reached. After the one-minute period, the user can run Outlook Web App
client access code for another 600 milliseconds.

Message throttling on servers

You can set the message throttling options at the following locations:
In the transport service
On a Send connector
On a Receive connector
You can set all the message throttling options that are available in the Transport service on Mailbox servers, in the
Mailbox Transport service on Mailbox servers, or in the Front End Transport service on Client Access servers using
the Exchange Management Shell. You can also set some of the same options by configuring the transport server
properties in the Exchange admin center (EAC ).
The following table shows the message throttling options that are available on transport servers.
Message throttling options on transport servers
SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-TransportService MaxConcurrentMailboxD 20 This parameter specifies

eliveries the maximum number of
Set- delivery threads that the
MailboxTransportServ transport service can
ice have open at the same
time to deliver messages
to mailboxes. The valid
input range for this
parameter is from 1
through 256. We
recommend that you
don't modify the default
value unless Microsoft
Customer Service and
Support advises you to
do this.
SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-TransportService MaxConcurrentMailboxS 20 This parameter specifies

ubmissions the maximum number of
Set- submission threads that
MailboxTransportServ the transport service
ice can have open at the
same time to send
messages from
mailboxes. The valid
input range for this
parameter is from 1
through 256.

Set-TransportService MaxConnectionRatePer 1200 This parameter specifies

Minute the maximum rate that
connections are allowed
to be opened with the
transport service. If
many connections are
attempted with the
transport service at the
same time, the
MaxConnectionRatePer
Minute parameter limits
the rate that the
connections are opened
so that the server's
resources aren't
overwhelmed.

Set-TransportService MaxOutboundConnectio 1000 This parameter specifies

or ns the maximum number of
outbound connections
Transport server that can be open at a
properties time. If you enter a value
of unlimited , no limit
is imposed on the
number of outbound
connections. The value
of this parameter must
be greater than or equal
to the value of the
MaxPerDomainOutboun
dConnections
parameter.
This value can also be
configured using the
EAC at Servers >
Servers > Properties
> Transport limits >
Outbound connection
restrictions.
 SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-TransportService MaxPerDomainOutboun 20 This parameter specifies

or dConnections the maximum number of
concurrent connections
Transport server to any single domain. If
properties you enter a value of
unlimited , no limit is
imposed on the number
of outbound
connections per domain.
The value of this
parameter must be
greater than or equal to
the value of the
MaxOutboundConnectio
ns parameter.
This value can also be
configured using the
EAC at Servers >
Servers > Properties
> Transport limits >
Outbound connection
restrictions.

Set-TransportService PickupDirectoryMaxMess 100 This parameter specifies

agesPerMinute the maximum number of
messages processed per
minute by the Pickup
directory and by the
Replay directory. Each
directory can
independently process
message files at the rate
specified by this
parameter.

Message throttling on Send connectors

The following table shows the message throttling option that's available on Send connectors. You need to use the
Exchange Management Shell to configure this option.
Message throttling option available on Send connectors
SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-SendConnector ConnectionInactivityTim 10 minutes This parameter specifies

eOut the maximum time that
an open SMTP
connection with a
destination messaging
server can remain idle
before the connection is
closed.

Message throttling on Receive connectors

The following table shows the message throttling options that are available on Receive connectors that are
configured in the Transport service on a Mailbox server or on an Edge Transport server. You need to use the
Exchange Management Shell to configure these options.
Message throttling options available on Receive connectors
SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-ReceiveConnector ConnectionInactivityTim 5 minutes in the This parameter specifies

eOut Transport service on the maximum time that
Mailbox servers an open SMTP
connection with a source
5 minutes in the Front messaging server can
End Transport service on remain idle before the
Client Access servers. connection is closed. The
1 minute on Edge value of this parameter
Transport servers. must be smaller than
the value specified by
the ConnectionTimeout
parameter.

Set-ReceiveConnector ConnectionTimeOut 10 minutes in the This parameter specifies

Transport service on the maximum time that
Mailbox servers an SMTP connection
with a source messaging
10 minutes in the Front server can remain open,
End Transport service on even if the source
Client Access servers. messaging server is
5 minutes on Edge transmitting data. The
Transport servers. value of this parameter
must be larger than the
value specified by the
ConnectionInactivityTim
eout parameter.

Set-ReceiveConnector MaxInboundConnection 5000 This parameter specifies

the maximum number of
inbound SMTP
connections that this
Receive connector allows
at the same time.
SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-ReceiveConnector MaxInboundConnection 100 percent on the This parameter specifies

PercentagePerSource Default Receive the maximum number of
connector in the SMTP connections that a
Transport service on a Receive connector allows
mailbox server at the same time from a
single source messaging
2 percent on the other server. The value is
Receive connectors in expressed as the
the Transport service on percentage of available
Mailbox servers, and in remaining connections
the Front End Transport on a Receive connector.
service on Client Access The maximum number
servers. of connections that are
permitted by the Receive
connector is defined by
the
MaxInboundConnection
parameter.

Set-ReceiveConnector MaxInboundConnection unlimited on the Default This parameter specifies

PerSource Receive connector in the the maximum number of
Transport service on a SMTP connections that a
mailbox server Receive connector allows
at the same time from a
20 on the other Receive single source messaging
connectors in the server.
Transport service on
Mailbox servers, and in
the Front End Transport
service on Client Access
servers.

Set-ReceiveConnector MaxProtocolErrors 5 This parameter specifies

the maximum number of
SMTP protocol errors
that a Receive connector
allows before the
Receive connector closes
the connection with the
source messaging server.
 SOURCE PARAMETER DEFAULT VALUE DESCRIPTION

Set-ReceiveConnector TarpitInterval 5 seconds This parameter specifies

the delay that's used in
tarpitting. Tarpitting is
the practice of artificially
delaying SMTP
responses for specific
SMTP communication
patterns that indicate a
directory harvest attack
or other unwelcome
messages. A directory
harvest attack is an
attempt to collect valid
e-mail addresses from a
particular organization
to use as a target for
unsolicited commercial
e-mail.
The delay that's specified
by the TarpitInterval
parameter only applies
to anonymous
connections.

Message throttling policies

In Exchange 2013, each mailbox has a ThrottlingPolicy setting. The default value for this setting is blank ( $null ).
You can use the ThrottlingPolicy paramenter on the Set-Mailbox cmdlet to configure a throttling policy for a
mailbox.
A default throttling policy exists to provide a default set budget configuration for users who connect to Exchange.
To configure customized budget settings for one or more users, create a new throttling policy. Then, apply the
policy to the appropriate user or group.

IMPORTANT
We recommend that you don't modify the default throttling policy.

You can set all the message throttling options that are available on Mailbox servers in the Exchange Management
Shell. The following cmdlets are available to manage throttling policies:
Get-ThrottlingPolicy
Remove-ThrottlingPolicy
New-ThrottlingPolicy
Set-ThrottlingPolicy
You can use the New-ThrottlingPolicy and Set-ThrottlingPolicy cmdlets to configure how much activity a user
can perform against Exchange over a specific connection or time period. These settings make up a user's budget.
You can establish throttling policies to control access to the following Exchange features:
Exchange ActiveSync
Exchange Web Services
Outlook Web App
Unified Messaging
IMAP4
POP3
Outlook client connections (MAPI or RPC connections)
Mail flow settings
PowerShell commands
CPU usages
 Back pressure
6/11/2019 • 14 minutes to read • Edit Online

Applies to: Exchange Server 2013

Back pressure is a system resource monitoring feature of the Microsoft Exchange Transport service that exists on
Microsoft Exchange 2013 Mailbox servers and Edge Transport servers.
Exchange can detect when vital resources, such as available hard drive space and memory, are under pressure, and
take action in an attempt to prevent service unavailability. Back pressure prevents the system resources from being
completely overwhelmed, and the Exchange server tries to process the existing messages before accepting any
new messages. When utilization of the system resource returns to a normal level, the Exchange server gradually
resumes normal operation and starts accepting new messages again.
In Exchange 2013, when the Transport service on a Mailbox server or an Edge Transport server is under resource
pressure, incoming connections are accepted, but incoming messages over those connections are either accepted at
a slower rate or are rejected. When an SMTP host attempts to connect to an Exchange server that's under resource
pressure, the connection will succeed. However, when the host issues the MAIL FROM command to submit a
message, depending on the resource that's under pressure, the Transport service either delays the
acknowledgement of the MAIL FROM command or rejects the connection.

Resources monitored
The following system resources are monitored as part of the back pressure feature:
Free space on the hard drive that stores the message queue database.
Free space on the hard drive that stores the message queue database transaction logs.
The number of uncommitted message queue database transactions that exist in memory.
The memory that's used by the EdgeTransport.exe process.
The memory that's used by all other processes.
The number of messages in the Submission queue.
For each monitored system resource on a Mailbox server or Edge Transport server, the following three levels of
resource utilization are applied:
Normal: The resource isn't overused. The server accepts new connections and messages.
Medium: The resource is slightly overused. Back pressure is applied to the server in a limited manner. Mail
from senders in the authoritative domain can flow. However, depending on the specific resource under
pressure, the server uses tarpitting to delay server response or rejects incoming MAIL FROM commands
from other sources.
High: The resource is severely overused. Full back pressure is applied. All message flow stops, and the
server rejects all new incoming MAIL FROM commands.
The following sections explain how Exchange handles the situation when a specific resource is under pressure.

Free hard drive space for the message queue database

By default, the message queue database is stored at %ExchangeInstallPath%TransportRoles\data\Queue. Exchange
monitors the hard drive space utilization for this location. The high level of hard drive space utilization is calculated
by using the following formula:
100 * (hard disk size - fixed constant) / hard drive size
The value of fixed constant is 500 megabytes (MB ).
The results of this formula are expressed as a percentage of the total hard drive space that's being used. The results
of the formula are always rounded down to the nearest integer. By default, the medium level of hard drive
utilization is 2 percent less than the high level. By default, the normal level of hard drive utilization is 4 percent less
than the high level.

Free hard drive space for the message queue database transaction logs
By default, the message queue database transaction logs are stored at
%ExchangeInstallPath%TransportRoles\data\Queue. Exchange monitors the hard drive space utilization for this
location. The %ExchangeInstallPath%Bin\EdgeTransport.exe.config application configuration file contains a
DatabaseCheckPointDepthMax key that has a default value of 384 MB. This key controls the total allowed size of
all uncommitted transaction logs that exist on the hard drive. This key is used in the formula that calculates hard
drive utilization.

NOTE
The value of the DatabaseCheckPointDepthMax key applies to all transport-related Extensible Storage Engine (ESE) databases
that exist on the Mailbox server or Edge Transport server. This would include the message queue database and the IP filter
database.

By default, the high level of disk utilization is calculated by using the following formula:
100 * (hard drive size - Min(5 GB, 3*DatabaseCheckPointDepthMax)) / hard drive size
The results of the formula are always rounded down to the nearest integer. By default, the medium level of hard
drive utilization is 2 percent less than the high level. The normal level of hard drive utilization is 4 percent less than
the high level.

Number of uncommitted message queue database transactions in

memory
A list of changes that are made to the message queue database is kept in memory until those changes can be
committed to a transaction log. Then the list is committed to the message queue database itself. These outstanding
message queue database transactions that are kept in memory are known as version buckets. The number of
version buckets may increase to unacceptably high levels because of an unexpectedly high volume of incoming
messages, spam attacks, problems with the message queue database integrity, or hard drive performance.
When Exchange starts receiving messages, these messages are grouped together in batches and then prepared as
version buckets. If an incoming message has a large attachment, it can be separated into multiple batches. These
batches that are being processed are known as batch points. The number of outstanding batch points can exceed
the set thresholds, especially when there's an unexpectedly high volume of incoming messages with large
attachments.
When version buckets or batch points are under pressure, the Exchange server will start throttling incoming
connections by delaying acknowledgement to incoming messages. Exchange will reduce the rate of inbound
message flow by tarpitting, which introduces a delay to the MAIL FROM commands. If the resource pressure
condition continues, Exchange will gradually increase the tarpitting delay. After the resource utilization returns to
normal, Exchange will gradually start reducing the acknowledgement delay and ease into normal operation. By
default, Exchange will start delaying message acknowledgements 10 seconds when under resource pressure. If the
resources continue to be under pressure, the delay is increased in 5-second increments up to 55 seconds.
Exchange keeps a history of version bucket and batch point resource utilization. If the resource utilization doesn't
go down to normal level for a specific number of polling intervals, known as the history depth, Exchange will stop
the tarpitting delay and start rejecting incoming messages until the resource utilization goes back to normal. By
default, the history depths for version buckets and batch points are in 10 and 300 polling intervals respectively.

Memory used by the EdgeTransport.exe process

By default, the high level of memory utilization by the EdgeTransport.exe process is calculated by using the
following formula:
75 percent of the total physical memory or 1 terabyte, whichever is less
This calculation doesn't include virtual memory that's available on the hard drive in the paging file, or the memory
that's used by other processes. The results of this formula are expressed as a percentage of the total memory that's
used by the EdgeTransport.exe process. The results of the formula are always rounded down to the nearest integer.
By default, the medium level of memory utilization by the EdgeTransport.exe file is calculated as 73 percent of the
total physical memory or 2 percent less than the value of the high level, whichever is less. By default, the normal
level of memory utilization by the EdgeTransport.exe file is calculated as 71 percent of the total physical memory or
4 percent less than the value of the high level, whichever is less.
If the memory utilization of the EdgeTransport.exe process is higher than the specified normal level, garbage
collection is forced. Garbage collection is a process that checks for unused objects that exist in memory, and
reclaims the memory that's used by those unused objects.
Exchange keeps a history of the memory utilization of the EdgeTransport.exe process. If the utilization doesn't go
down to normal level for a specific number of polling intervals, known as the history depth, Exchange will start
rejecting incoming messages until the resource utilization goes back to normal. By default, the history depth for
EdgeTransport.exe memory utilization is 30 polling intervals.

Memory used by all processes

By default, the high level of memory utilization by all processes is 94 percent of total physical memory. This value
doesn't include virtual memory that's available on the hard drive in the paging file.
When the specified memory utilization level is reached, message dehydration occurs. Message dehydration is the
act of removing unnecessary elements of queued messages that are cached in memory. Complete messages are
cached in memory for enhanced performance. Removal of the MIME content of queued messages from memory
reduces the memory that's used at the expense of higher latency because the messages are read directly from the
message queue database. By default, message dehydration is enabled.

Number of messages in the Submission queue

The Submission queue is associated with the Transport service on Exchange 2013 Mailbox servers and on Edge
Transport servers. The categorizer processes each message in the Submission queue. This categorization results in
the message being put in a delivery queue. For more information, see Mail flow and Queues. A large number of
messages in the Submission queue indicates the categorizer is having difficulty processing messages.
When the Submission queue is under pressure, the Exchange server will start throttling incoming connections by
delaying acknowledgement to incoming messages. Exchange will reduce the rate of inbound message flow by
tarpitting, which introduces a delay to the MAIL FROM commands. If the Submission queue pressure condition
continues, Exchange will gradually increase the tarpitting delay. After the Submission queue utilization returns to
normal, Exchange will gradually start reducing the acknowledgement delay and ease into normal operation. By
default, Exchange will start delaying message acknowledgements 10 seconds when under Submission queue
pressure. If the Submission queue continues to be under pressure, the delay is increased in 5-second increments
up to 55 seconds.
Exchange keeps a history of Submission queue utilization. If the Submission queue utilization doesn't go down to
normal level for a specific number of polling intervals, known as the history depth, Exchange will stop the tarpitting
delay and start rejecting incoming messages until the Submission utilization goes back to normal. By default, the
history depth for the Submission queue is in 300 polling intervals.

Actions taken by Exchange Transport when under resource pressure

The following table summarizes the actions taken by Exchange transport when a specific resource is under
pressure.
Back pressure actions taken by Mailbox and Edge Transport servers when responding to resource pressure
RESOURCE UNDER PRESSURE UTILIZATION LEVEL ACTIONS TAKEN

Hard drive space for message Medium Reject incoming messages

queue database from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Hard drive space for message High Reject incoming messages

queue database from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submission service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Hard drive space for message Medium Reject incoming messages

queue database transaction logs from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
RESOURCE UNDER PRESSURE UTILIZATION LEVEL ACTIONS TAKEN

Hard drive space for message High Reject incoming messages

queue database transaction logs from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submission service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Version buckets Medium Introduce or increment the

tarpitting delay to incoming
messages. If normal level isn't
reached for the entire version
bucket history depth, take the
following actions:
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Version buckets High Introduce or increment the

tarpitting delay to incoming
messages. If normal level isn't
reached for the entire version
bucket history depth, take the
following actions:
Reject incoming messages
from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submission service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
RESOURCE UNDER PRESSURE UTILIZATION LEVEL ACTIONS TAKEN

Batch point Medium Introduce or increment the

tarpitting delay to incoming
messages. If normal level isn't
reached for the entire batch point
history depth, take the following
actions:
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Batch point High Introduce or increment the

tarpitting delay to incoming
messages. If normal level isn't
reached for the entire batch point
history depth, take the following
actions:
Reject incoming messages
from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submission service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Memory used by EdgeTransport.exe Medium Reject incoming messages

process from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
Force garbage collection
RESOURCE UNDER PRESSURE UTILIZATION LEVEL ACTIONS TAKEN

Memory used by EdgeTransport.exe High Reject incoming messages

process from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submission service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories

Memory used by all processes Medium Reject incoming messages

from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
Force garbage collection

Memory used by all processes High Reject incoming messages

from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submission service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
Flush enhanced DNS cache
from memory
Start message dehydration

Number of messages in the Medium Introduce or increment the

Submission queue tarpitting delay to incoming
messages. If normal level isn't
reached for the entire Submission
queue history depth, take the
following actions:
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
Force garbage collection
 RESOURCE UNDER PRESSURE UTILIZATION LEVEL ACTIONS TAKEN

Number of messages in the High Introduce or increment the

Submission queue tarpitting delay to incoming
messages. If normal level isn't
reached for the entire Submission
queue history depth, take the
following actions:
Reject incoming messages
from other Exchange servers
Reject message submissions
from mailbox databases by
the Mailbox Transport
Submissions service on
Mailbox servers
Reject incoming messages
from non-Exchange servers
Reject message submissions
from Pickup and Replay
directories
Flush enhanced DNS cache
from memory
Start message dehydration

Back pressure configuration options in the EdgeTransport.exe.config

file
All configuration options for back pressure are available in the
%ExchangeInstallPath%Bin\EdgeTransport.exe.config XML application configuration file.

WARNING
These settings are listed as a reference only. We strongly discourage any modifications to the back pressure settings in the
EdgeTransport.exe.config file. Modifications to the back pressure settings may result in poor performance or data loss. We
recommend that you investigate and correct the root cause of any back pressure events that you may encounter.

Back pressure configuration options

KEY NAME DEFAULT VALUE

EnableResourceMonitoring true

ResourceMonitoringInterval 00:00:02 (2 seconds)

PercentageDatabaseDiskSpaceUsedHighThreshold 0. This value indicates that the default formula will be

used.
KEY NAME DEFAULT VALUE

PercentageDatabaseDiskSpaceUsedMediumThreshold 0. This value indicates that the actual value is 2 percent

less than the value of
PercentageDatabaseDiskSpaceUsedHighThreshold.

PercentageDatabaseDiskSpaceUsedNormalThreshold 0. This value indicates that the actual value is 2 percent

less than the value of
PercentageDatabaseDiskSpaceUsedMediumThreshold.

PercentageDatabaseLoggingDiskSpaceUsedHighThreshol 0. This value indicates that the default formula will be

d used.

PercentageDatabaseLoggingDiskSpaceUsedMediumThres 0. This value indicates that the actual value is 2 percent

hold less than the value of
PercentageDatabaseLoggingDiskSpaceUsedHighThreshol
d.

PercentageDatabaseLoggingDiskSpaceUsedNormalThres 0. This value indicates that the actual value is 2 percent

hold less than the value of
PercentageDatabaseLoggingDiskSpaceUsedMediumThres
hold.

PercentagePrivateBytesUsedHighThreshold 0. This value indicates that the default calculation will be

used.

PercentagePrivateBytesUsedMediumThreshold 0. This value indicates that the actual value is 2 percent

less than the value of
PercentagePrivateBytesUsedHighThreshold.

PercentagePrivateBytesUsedNormalThreshold 0. This value indicates that the actual value is 2 percent

less than the value of
PercentagePrivateBytesUsedMediumThreshold.

VersionBucketsHighThreshold 2500

VersionBucketsMediumThreshold 2000

VersionBucketsNormalThreshold 1750

VersionBucketsHistoryDepth 10

BatchPointHighThreshold 4000

BatchPointMediumThreshold 2000
 KEY NAME DEFAULT VALUE

BatchPointNormalThreshold 1000

BatchPointHistoryDepth 300

BatchPointUseCostForPressure true

BatchPointBatchSize 40

BatchPointBatchTimeout 00:00:00.100 (0.1 seconds)

BatchPointItemExpiryInterval 00:05:00 (5 minutes)

SMTPBaseThrottlingDelayInterval 00:00:00

SMTPMaxThrottlingDelayInterval 00:00:55 (55 seconds)

SMTPStepThrottlingDelayInterval 00:00:05 (5 seconds)

SMTPStartThrottlingDelayInterval 00:00:10 (10 seconds)

PercentagePhysicalMemoryUsedLimit 94

DehydrateMessagesUnderMemoryPressure true

PrivateBytesHistoryDepth 30

SubmissionQueueHighThreshold 10000

SubmissionQueueMediumThreshold 4000

SubmissionQueueNormalThreshold 2000

SubmissionQueueHistoryDepth 300

Back pressure logging information

The following list describes the event log entries that are generated by specific back pressure events in Exchange:
Event log entry for an increase in any resource utilization level
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15004
Description: Resource pressure increased from Previous Utilization Level to Current Utilization Level.
Event log entry for a decrease in any resource utilization level
Event Type: Information
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15005
Description: Resource pressure decreased from Previous Utilization Level to Current Utilization Level.
Event log entry for critically low available disk space
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15006
Description: The Microsoft Exchange Transport service is rejecting messages because available disk space is
below the configured threshold. Administrative action may be required to free disk space for the service to
continue operations.
Event log entry for critically low available memory
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15007
Description: The Microsoft Exchange Transport service is rejecting message submissions because the service
continues to consume more memory than the configured threshold. This may require that this service be
restarted to continue normal operation.
 Queues
6/14/2019 • 26 minutes to read • Edit Online

Applies to: Exchange Server 2013

A queue is a temporary holding location for messages that are waiting to enter the next stage of processing or delivery to
a destination. Each queue represents a logical set of messages that the Exchange server processes in a specific order. In
Microsoft Exchange Server 2013, queues hold messages before, during and after delivery. Queues exist on Mailbox
servers and Edge Transport servers. Mailbox servers and Edge Transport servers are called transport servers throughout
this topic.
Like the previous versions of Exchange, Exchange 2013 uses a single Extensible Storage Engine (ESE ) database for queue
storage.
You can manage queues and the messages in queues using the Exchange Management Shell and Queue Viewer in the
Exchange Toolbox. You can use these interfaces to view the status and contents of queues and detailed message
properties. You can also use these interfaces to perform actions that modify queues or the messages in the queues.

Types of queues
The following types of queues are used in Exchange 2013:
Persistent queues: Perisistent queues are queues that exist on every transport server in every Exchange
organization. Like previous versions of Exchange, there are three persistent queues in Exchange 2013:
Submission queue: The Submission queue is used by the categorizer to gather all messages that have to
be resolved, routed, and processed by transport agents on the transport server. All messages that are
received by a transport server enter processing in the Submission queue. On Mailbox servers, messages are
submitted through a Receive connector, the Pickup or Replay directories, or the Mailbox Transport
Submission service. On Edge Transport servers, messages are typically submitted through a Receive
connector, but the Pickup and Replay directories are also available.
The categorizer retrieves messages from this queue and, among other things, determines the location of the
recipient and the route to that location. After categorization, the message is moved to a delivery queue or to
the Unreachable queue. Each transport server has only one Submission queue. Messages that are in the
Submission queue can't be in other queues at the same time. For more information about the categorizer
and the transport pipeline, see Mail flow.
Unreachable queue: The Unreachable queue contains messages that can't be routed to their destinations.
Typically, an unreachable destination is caused by configuration changes that have modified the routing path
for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue.
Each transport server has only one Unreachable queue.
Messages in the Unreachable queue are automatically resubmitted when a routing change is detected. So,
after the condition or configuration error caused the messages to enter the Unreachable queue is repaired,
you don't need to take additional action to move the messages out of the Unreachable queue for delivery.

The Unreachable queue is typically empty. If the Unreachable queue contains no messages it doesn't
appear in Queue Viewer or **Get-Queue** results.

Poison message queue: The poison message queue is a special queue that's used to isolate messages that
are determined to be harmful to the Exchange 2013 system after a transport server or service failure. The
messages may be genuinely harmful in their content and format. Alternatively, they may be the results of a
poorly written agent that has caused the Exchange server to fail when it processed the supposedly bad
messages.
The poison message queue is typically empty. If the poison message queue contains no messages it doesn't
 appear in Queue Viewer or Get-Queue results. The messages in the poison message queue are never
automatically resumed or expired. Messages remain in the poison message queue until they're manually
resumed or removed by an administrator.
Delivery queues: Delivery queues hold messages that are being delivered to any local or remote destinations by
using SMTP. All messages are transmitted between Exchange servers by using SMTP. Non-SMTP destinations
also use delivery queues if the destination is serviced by a Delivery Agent connector. . Each delivery queue contains
messages that are being routed to the same destination. It's practically inevitable that multiple delivery queues will
exist on a transport server. Delivery queues are dynamically created when they're required and are automatically
deleted when the queue is empty and the expiration time has passed. The queue expiration time is controlled by the
QueueMaxIdleTime parameter on the Set-TransportService cmdlet. The default value is three minutes.
Shadow queues: Shadow queues hold redundant copies of a message while the message is in transit. For more
information, see Shadow redundancy.
Safety Net: Safety Net retains copies of messages that were successfully delivered by the transport server.
Although it's not accessible by queue management tools, Safety Net is just another queue in the queue database.
For more information, see Safety Net.

Queue database files

All the different queues are stored in a single ESE database. By default, this queue database is located on the transport
server at %ExchangeInstallPath%TransportRoles\data\Queue .
Like any ESE database, the queue database uses log files to accept, track, and maintain data. To enhance performance, all
message transactions are written first to log files and memory, and then to the database file. The checkpoint file tracks the
transaction log entries that have been committed to the database. During an ordinary shutdown of the Microsoft
Exchange Transport service, uncommitted database changes that are found in the transaction logs are always committed
to the database.
Circular logging is used for the queue database. This means that the history of committed transactions that are found in
the transaction logs isn't maintained. Any transaction logs that are older than the current checkpoint are immediately and
automatically deleted. Therefore, the transaction logs can't be replayed for queue database recovery from backup.
Exchange 2013 uses generation tables for storage and clean-up of messages in the queue database. Instead of processing
and deleting individual message records from one large table, the queue database stores messages in time-based tables,
and only deletes the entire table after all the messages in the table have been successfully processed. For example, all
messages queued from 1:00 PM to 2:00 PM, regardless of the queue or destination, are stored in the 1p-2p_msgs table. At
2:00 PM, new messages are stored in the 2p-3p_msgs table. At 4:00 PM, a new table named 4p-5p_msgs is created, and
the entire 1p-2p_msgs table is deleted, but only if all messages in the table have been successfully processed. This
approach of deleting entire messages tables instead of individual messages helps improves the I/O performance of the
drive that holds the queue database.
The following table lists the files that constitute the queue database.
Files that constitute the queue database
FILE DESCRIPTION

Mail.que This queue database file stores all the queued messages.

Tmp.edb This temporary database file is used to verify the queue

database schema on startup.
 FILE DESCRIPTION

Trn*.log This transaction log records all changes to the queue

database. Changes to the database are first written to the
transaction log and then committed to the database. Trn.log is
the current active transaction log file. Trntmp.log is the next
provisioned transaction log file that's created in advance. If the
existing Trn.log transaction log file reaches its maximum size,
Trn.log is renamed to Trnnnnn.log, where nnnn is a sequence
number. Trntmp.log is then renamed Trn.log and becomes the
current active transaction log file.

Trn.chk This checkpoint file tracks the transaction log entries that have
been committed to the database. This file is always in the
same location as the mail.que file.

Trnres00001.jrs These reserve transaction log files act as placeholders. They're

only used when the hard disk that contains the transaction
Trnres00002.jrs log runs out of space to stop the queue database cleanly.

Options for configuring the queue database

You configure the queue database by adding or modifying keys in the %ExchangeInstallPath%Bin\EdgeTransport.exe.config
XML application configuration file. This file is associated with the Microsoft Exchange Transport service. Changes you
make to the EdgeTransport.exe.config file take effect after you restart the Microsoft Exchange Transport service.
The <appSettings> section of the EdgeTransport.exe.config file is where you can add new keys or modify existing keys. If a
specific key doesn't exist, you can add it manually to change its value.
The keys for the queue database that are available in the EdgeTransport.exe.config file are described in the following table.
Message queue database keys that are available in the EdgeTransport.exe.config file
KEY DEFAULT VALUE DESCRIPTION

QueueDatabaseBatchSize 40 This key specifies the number of

database I/O operations that can be
grouped together before they're
executed. By default, this key doesn't
exist in the EdgeTransport.exe.config
file.

QueueDatabaseBatchTimeout 100 This key specifies the maximum time

in milliseconds that the database will
wait for multiple database I/O
operations to group before it executes
them. The database I/O operations are
executed without waiting for any more
if the following conditions are true:
The number of database I/O
operations that's specified by
the QueueDatabaseBatchSize
key hasn't been reached.
The time specified by the
QueueDatabaseBatchTimeout
key has passed.
By default, this key doesn't exist in the
EdgeTransport.exe.config file.
KEY DEFAULT VALUE DESCRIPTION

QueueDatabaseMaxConnections 4 This key specifies the number of ESE

database connections that can be
open.

QueueDatabaseLoggingBufferSize 5 MB This key specifies the memory that's

used to cache the transaction records
before they're written to the
transaction log file.

QueueDatabaseLoggingFileSize 5 MB This key specifies the maximum size of

a transaction log file. When the
maximum log file size is reached, a
new log file is opened.

QueueDatabaseLoggingPath This key specifies the default directory

%ExchangeInstallPath%TransportRoles\data\Queue
for the queue database log files. For
instructions on how to change the
location of the queue database, see
Change the location of the queue
database.

QueueDatabaseMaxBackgroundClean 32 This key specifies the maximum

upTasks number of background cleanup work
items that can be queued to the
database engine thread pool at any
time.

QueueDatabaseOnlineDefragEnabled True The key enables or disables scheduled

online defragmentation of the mail
queue database. By default, this key
doesn't exist in the
EdgeTransport.exe.config file.

QueueDatabaseOnlineDefragSchedul 1:00:00 or 1:00 A.M. This key specifies the time of day in
e 24 hour format to start the online
defragmentation of the mail queue
database. To specify a value, enter the
value as a time: hh:mm:ss, where h =
hours, m = minutes, and s = seconds.

QueueDatabaseOnlineDefragTimeToR 3:00:00 or 3 hours This key specifies the length of time

un the online defragmentation task is
allowed to run. Even if the
defragmentation task doesn't finish in
the time specified, the queue database
is left in a consistent state. To specify a
value, enter the value as a time span:
hh:mm:ss, where h = hours, m =
minutes, and s = seconds.

QueueDatabasePath This key specifies the default directory

%ExchangeInstallPath%TransportRoles\data\Queue
for the queue database files. For
instructions on how to change the
location of the queue database, see
Change the location of the queue
database.
 NOTE
Any customized per-server settings you make in Exchange XML application configuration files, for example, web.config files on Client
Access servers or the EdgeTransport.exe.config file on Mailbox servers, will be overwritten when you install an Exchange Cumulative
Update (CU). Make sure that you save this information so you can easily re-configure your server after the install. You must re-
configure these settings after you install an Exchange CU.

Queue properties
A queue has many properties that describe the purpose and status of the queue. Some queue properties are applied to
the queue when the queue is created, and don't change. Other properties contain status size, time, or other indicators that
are updated frequently.

NextHopSolutionKey
The routing component of the categorizer in the Microsoft Exchange Transport service selects the destination for a
message, and this destination is used to create the delivery queue. The destination is stamped on every recipient as the
NextHopSolutionKey attribute. Every unique value of the NextHopSolutionKey attribute corresponds to a separate
delivery queue.
The NextHopSolutionKey attribute contains the following fields:
DeliveryType: The value of this field represents the results of the categorization of the message, and how the
Transport service intends to transmit the message to the next hop, which could be the ultimate destination of the
message, or an intermediate hop along the way. The Transport service uses a predefined list of values for
DeliveryType based on the target routing destination or delivery group.
NextHopDomain: This field uses specific values based on the value of the DeliveryType field. For delivery
queues, the value of this field is effectively the name of the queue. The value of NextHopDomain isn't always a
domain name. For example, the value could be the name of the target Active Directory site or database availability
group (DAG ). Think of this field as the next hop name, where the value is the name of the routing destination or the
target delivery group.
NextHopConnector: This field uses specific values based on the value of the DeliveryType field. The value is
always expressed as a GUID. If this field isn't used, the value is a GUID with all zeroes. The value of
NextHopConnector isn't always the GUID of a connector. For example, the value could be the GUID of the target
Active Directory site or DAG. Think of this field as the next hop GUID, where the value is the GUID of the routing
destination or the target delivery group.
Exchange 2013 also adds the NextHopCategory property to the queue based on the value of DeliveryType. The value
of NextHopCategory is External or Internal . The value External indicates the next hop of the queue is outside the
Exchange organization. The value Internal indicates the next hop of the queue is inside the Exchange organization. Note
that a message for an external recipient may require one or more internal hops before the message is delivered externally.
The values of DeliveryType, NextHopCategory, NextHopDomain and NextHopConnector are described in the
following table.

DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT

QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

Delivery DeliveryAgen The queue External This value is This value is

Agent t holds the destination he GUID of
messages for address space the Delivery
delivery to that's Agent
recipients in a configured on connector. For
non-SMTP the Delivery example,
address space. Agent 4520e633-
The messages connector. d83d-411a-
bbe4-
are delivered 6a84648674ee
by using a .
Delivery Agent
connector
that's
configured on
the local
server.

DnsConnecto DnsConnecto The queue External This value is This value is

rDelivery rDelivery holds the destination the GUID of
messages for address space the Send
delivery to that's connector. For
recipients in an configured on example,
SMTP address the Send 4520e633-
space. The connector. For d83d-411a-
bbe4-
messages are example, 6a84648674ee
delivered by contoso.com .
.
using a Send
connector
that's
configured on
the local
server. The
Send
connector is
configured to
use DNS
routing.

NonSmtpGat NonSmtpGat The queue External This value is This value is

ewayDelivery ewayDelivery holds the destination the GUID of
messages for address space the Foreign
delivery to that's connector. For
recipients in a configured on example,
non-SMTP the Foreign 4520e633-
address space. connector. d83d-411a-
bbe4-
The messages 6a84648674ee
are delivered .
by using a
Foreign
connector
that's
configured on
the local
server.

SmartHostCo SmartHostCo The queue External This value is This value is

nnectorDeliv nnectorDeliv holds the list of the GUID of
ery ery messages for smart hosts the Send
delivery to that are connector. For
recipients in an configured on example,
SMTP address the Send 4520e633-
space. The connector. d83d-411a-
bbe4-
messages are Smart hosts 6a84648674ee
 delivered by can be .
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL using a Send
DESCRIPTION NEX THOPCATEGORY configured as
NEX THOPDOMAIN OR
connector FQDNs, IP
that's addresses or
configured on both. The
the local values can be
server. The one of the
Send following:
connector is
configured to FQDN
use smart host The
routing. syntax
is
<FQDN1,FQDN2,...>
. For
exampl
e,
smarthost01.contoso.com
or
smarthost01.contoso.com,smarthost02.fabrikam.com
.
IP
addres
s The
syntax
is
<[IPAddress1],
[IPAddress2],...>
. For
exampl
e,
[10.10.10.100]
or
[10.10.10.100],
[10.10.10.101]
.
FQDN
and IP
addres
s The
syntax
is
<[IPAddress1],FQDN1,...>
, and
depend
s on
how
the
smart
hosts
are
listed
on the
Send
connec
tor. For
exampl
e,
[172.17.17.7],relay.tailspintoys.com
or
mail.contoso.com,
[192.168.1.50]
.
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

SMTP SmtpDelivery The queue Internal This value is This value is

Delivery to ToMailbox holds the name of the GUID of
Mailbox messages for the destination the target
delivery to mailbox mailbox
Exchange database. For database. For
2013 mailbox example, example,
recipients. The Mailbox 6dcb5a1e-
destination Database 0a88-4fc9-
0471695037 b8f9-
mailbox 634c34b1a123
database is in .
.
one of the
following
locations:
The
local
Exchan
ge
2013
Mailbo
x
server.
An
Exchan
ge
2013
Mailbo
x
server
in the
same
DAG.
An
Exchan
ge
2013
Mailbo
x
server
in the
same
Active
Directo
ry site
in non-
DAG
environ
ments.
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

SMTP Relay SmtpRelayTo The queue Internal This value is This value is
to Send ConnectorSo holds the name of the GUID of
Connector urceServers messages for the destination the
Source delivery to Send destination
Servers SMTP or non- connector, Send
SMTP Delivery Agent connector,
recipients. The connector, or Delivery Agent
messages are Foreign connector, or
delivered by connector. For Foreign
using a Send example, connector. For
connector, Contoso.com example,
Delivery Agent Send 4520e633-
Connector d83d-411a-
connector, or
. bbe4-
Foreign 6a84648674ee
connector .
that's
configured on
a remote
transport
server. The
remote
transport
server could
be an
Exchange
2013 Mailbox
server, or an
Exchange
2007 or
Exchange
2010 Hub
Transport
server from a
previous
version of
Exchange. The
remote server
could be
located in the
local Active
Directory site,
or in a remote
Active
Directory site.
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

SMTP Relay SmtpRelayTo The queue Internal This value is This value is
to Database Dag holds the name of the GUID of
Availability messages for the destination the
Group delivery to DAG. For destination
Exchange example, DAG. For
2013 mailbox DAG1 . example,
recipients, 6dcb5a1e-
where the 0a88-4fc9-
b8f9-
destination 634c34b1a123
mailbox
database is
located in a
remote DAG.
The remote
DAG could be
in the local
Active
Directory site,
or a remote
Active
Directory site.

SMTP Relay SmtpRelayTo The queue Internal The queue This value is
to Mailbox MailboxDeliv holds name uses the blank.
Delivery eryGroup messages for syntax:
Group delivery to Site:
legacy mailbox <ADSiteName>;Version:
<ExchangeVersion>
recipients,
where the , where
destination <ADSiteName
mailbox is on > is the name
an Exchange of the
2007 or destination
Exchange Active
2010 Mailbox Directory site,
server. The and
message is <ExchangeVer
related to a sion> is the
Hub Transport version of
server that's Exchange on
running the the Mailbox
same version server.
of Exchange as
the destination
mailbox. The
destination
Hub Transport
server could
be in the local
Active
Directory site,
or a remote
Active
Directory site.
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

SMTP Relay SmtpRelayTo The queue Internal This value is This value is
to Remote RemoteActiv holds the target the GUID of
Active eDirectorySit messages for Active the target
Directory e delivery to a Directory site Active
Site remote name. For Directory site.
destination, example, For example,
and the NorthAmericanSite bfd6c3df-
routing 5b65-8bfb-
. 53f1f2c0d55c
topology
requires the .
message to be
routed
through a
specific Active
Directory site.
The site is an
intermediate
hop on the
way to the
final
destination.
This situation
occurs under
the following
circumstances:
The
messag
e needs
to be
routed
throug
h a hub
site.
The
messag
e
require
s
delivery
throug
ha
Send
connec
tor
that's
configu
red on
an
Edge
Transp
ort
server
that's
subscri
bed to
a
remote
Active
Directo
ry site.
DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

SMTP Relay SmtpRelayTo The queue Internal This value is This value is
to Specified Servers holds the FQDN of 00000000-
Exchange messages for the target 0000-0000-
0000-
Servers delivery to a expansion 000000000000
distribution server. For .
group that's example,
configured for mailbox01.contoso.com
a specific .
expansion
server. The
expansion
could be an
Exchange
2013 Mailbox
server, or an
Exchange
2007 or
Exchange
2010 Hub
Transport
server. The
server could
be in the local
Active
Directory site,
or in a remote
Active
Directory site.

SMTP Relay SmtpRelayWi The queue Internal This value is This value is
in Active thinAdSiteToE holds the name of the GUID of
Directory dge messages for the Send the Send
Site to Edge delivery to an connector that connector. For
Transport SMTP address sends example,
Server space. The outbound 4520e633-
messages are Internet mail d83d-411a-
bbe4-
delivered by from the 6a84648674ee
using a Send organization .
connector to the
that's Internet. This
configured on Send
an Edge connector is
Transport automatically
server that's created by the
subscribed to Edge
the local Active subscription,
Directory site. and is named
EdgeSync -
<ADSiteName>
to Internet
.
<ADSiteName
> is the name
of the local
Active
Directory site
to which the
Edge Transport
server is
subscribed.
 DELIVERY TYPE IN DELIVERYTYPE IN NEX THOPCONNECT
QUEUE VIEWER THE SHELL DESCRIPTION NEX THOPCATEGORY NEX THOPDOMAIN OR

Heartbeat Heartbeat This value is n/a n/a n/a

reserved for
internal
Microsoft use.
For more
information
about
heartbeat, see
Shadow
redundancy.

Shadow ShadowRedu The queue Internal This value is This value is

Redundancy ndancy holds the FQDN of 00000000-
messages in a the primary 0000-0000-
0000-
shadow queue. server for 000000000000
A shadow which the .
queue holds shadow queue
redundant is holding
copies redundant
messages in copies of the
transit in case primary
the primary messages. For
messages example,
aren't mailbox01.contoso.com
successfully .
delivered. For
more
information,
see Shadow
redundancy.

Undefined Undefined This value is Internal For the This value is

used only on Submission 00000000-
the queue, this 0000-0000-
0000-
Submission value is 000000000000
queue and the Submisssion . .
poison For the poison
message message
queue. queue, this
value is
Poison
Message
.

Undreachabl Unreachable This value is Internal This value is This value is

e used only on Unreachable 00000000-
the Domain 0000-0000-
. 0000-
Unreachable 000000000000
queue. .

Note that Exchange 2013 supports legacy values of DeliveryType for backwards compatibility with previous versions of
Exchange. These values are available in Queue Viewer and the Shell, but they aren't used by Exchange 2013. These legacy
DeliveryType values are:
MapiDelivery: The queue holds messages for delivery by an Exchange 2007 or Exchange 2010 Hub Transport
server to a mailbox on an Exchange 2007 or Exchange 2010 Mailbox server in the local Active Directory site.
SmtpRelayWithinAdSite: The queue holds messages for delivery by an Exchange 2007 or Exchange 2010 Hub
Transport server to another Hub Transport server in the same Active Directory site. The destination Hub Transport
server can be the source server for a connector, or a distribution group expansion server.
 SmtpRelaytoTiRg: The queue holds messages for delivery by an Exchange 2007 or Exchange 2010 Hub Transport
server to an Exchange Server 2003 routing group. The destination server can be the source server for a connector,
a distribution group expansion server, or an Exchange 2003 bridgehead server.

IncomingRate, OutgoingRate, and Velocity

Exchange 2013 measures the rate of messages entering and leaving a queue and stores these values in queue properties.
You can use these rates as an indicator of queue and transport server health. The properties are:
IncomingRate: This property is the rate that messages are entering the queue.
This value is calculated from the number of messages entering the queue every 5 seconds averaged over the last
60 seconds. The formula can be expressed as (i1+i2+i3+i4+i5+i6)/6 , where in = the number of incoming
messages in 5 seconds.
OutgoingRate: This property is the rate that messages are leaving the queue.
This value is calculated from the number of messages leaving the queue every 5 seconds averaged over the last 60
seconds. The formula can be expressed as (o1+o2+o3+o4+o5+o6)/6 , where on = the number of outgoing messages
in 5 seconds.
Velocity: This property is the drain rate of the queue, and is calculated by subtracting the value of IncomingRate
from the value of OutgoingRate.
If the value of Velocity is greater than 0, messages are leaving the queue faster than they are entering the queue.
If the value of Velocity is equals 0, messages are leaving the queue as fast as they are entering the queue. This is
also the value you'll see when the queue is inactive.
If the value of Velocity is less than 0, messages are entering the queue faster than they are leaving the queue.
At a basic level, a positive value of Velocity indicates a healthy queue that's efficiently draining, and a negative value of
Velocity indicates a queue that isn't efficiently draining. However, you also need to consider the values of the
IncomingRate, OutgoingRate, and MessageCount properties, as well as the magnitude of the Velocity value for the
queue. For example, a queue that has a large negative value of Velocity, a large MessageCount value, a small
OutgoingRate value, and a large IncominRate value are accurate indicators that the queue isn't draining properly.
However, a queue with a negative Velocity value that's very close to zero that also has very small values for
IncomingRate, OutgoingRate, and MessageCount doesn't indicate a problem with the queue.

Queue status
The current status of a queue is stored in the Status property of the queue. A queue can have one of the following status
values:
Active: The queue is actively transmitting messages.
Connecting: The queue is in the process of connecting to the next hop.
Ready: The queue recently transmitted messages, but the queue is now empty.
Retry: The last automatic or manual connection attempt failed, and the queue is waiting to retry the connection.
Suspended: The queue has been manually suspended by an administrator to prevent message delivery. New
messages can enter the queue, and messages that are in the act of being transmitted to the next hop will finish
delivery and leave the queue. Otherwise, messages won't leave the queue until the queue is manually resumed by
an administrator. Note that suspending a queue doesn't change the status of the individual messages in the queue.
You can suspend a queue that has a status of Active or Retry. You can also suspend the Unreachable queue and the
Submission queue.
If you suspend the Unreachable queue, messages won't be automatically resubmitted to the categorizer when
configuration updates are detected. To automatically resubmit these messages, you need to manually resume the
Unreachable queue. If you suspend the Submission queue, messages won't be picked up by the categorizer until
the queue is resumed.
Other queue properties
There are other queue properties that are self-explanatory. You use most of the queue properties as filter options. By
specifying filter criteria, you can quickly locate queues and take action on them. For a complete description of the filterable
queue properties, see Queue filters.
An important queue property that's also worth mentioning here is the MessageCount property that shows how many
messages are in a queue. This property is an important indicator of queue health. For example, a delivery queue that
contains a large number of messages that continues to grow and never decreases could indicate a routing or transport
pipeline issue that requires your attention.

Message properties
A message in a queue has many properties. Many of the properties reflect the information that was used to create the
message. Some of the messages status and information properties are heavily influenced by corresponding properties on
the queue. However, an individual message may have a different value than the corresponding property of the queue.
Other properties contains status, time, or other indicators that are updated frequently.

Message status
The current status of a message is stored in the Status property of the message. A message can have one of the following
status values:
Active: If the message is in a delivery queue, the message is being delivered to its destination. If the message is in
the Submission queue, the message is being processed by the categorizer.
Locked: This value is reserved for internal Microsoft use, and isn't used in on-premises Exchange organizations.
PendingRemove: The message was deleted by the administrator, but the message was already in the act of being
transmitted to the next hop. The message will be deleted if the delivery ends in an error that causes the message to
reenter the queue. Otherwise, delivery will continue.
PendingSuspend: The message was suspended by the administrator, but the message was already in the act of
being transmitted to the next hop.. The message will be suspended if the delivery ends in an error that causes the
message to reenter the queue. Otherwise, delivery will continue.
Ready: The message is waiting in the queue and is ready to be processed.
Retry: The last automatic or manual connection attempt for the queue in which this message is located failed. The
message is waiting for the next automatic queue connection retry.
Suspended: The message was manually suspended by the administrator. All messages in the poison message
queue are in a permanently suspended state.

Other message properties

There are other message properties that are self-explanatory. You can use most of the message properties as filter
options. By specifying filter criteria, you can quickly locate messages and take action on them. For a complete description
of the filterable message properties, see Message filters.

Manage queues and messages in queues

Queue Viewer and virtually all of the queue and message management cmdlets are restricted to a single Exchange server.
You can view or operate on individual queues or messages, or multiple queues or messages, but only on a specific server.
Exchange 2013 introduces the Get-QueueDigest cmdlet that provides a high-level, aggregate view of the state of queues
on all servers within a specific scope, for example, a DAG, an Active Directory site, a list of servers, or the entire Active
Directory forest. Note that queues on a subscribed Edge Transport server in the perimeter network aren't included in the
results. Also, Get-QueueDigest is available on an Edge Transport server, but the results are restricted to queues on the
Edge Transport server.
 NOTE
By default, the Get-QueueDigest cmdlet displays delivery queues that contain ten or more messages, and the results are between
one and two minutes old. For instructions on how to change these default values, see Configure Get-QueueDigest.

The following table describes the management tasks you can perform on queues or messages in queues.

TASK DESCRIPTION TOOL TO USE INSTRUCTIONS

View and filter queues on This action displays one or Queue Viewer or the Get- Manage queues
a server more queues on a Queue cmdlet.
transport server. You can
use the results to take
action on the queues.

View and filter queues on This action displays a Get-QueueDigest cmdlet Manage queues
specific servers in specific summary view of queues only
DAGs, specific Active across a defined scope
Directory sites, or in the (servers, DAGs, Active
whole Active Directory Directory sites, or the
forest. entire Active Directory
forest).

Suspend queues This action temporarily Queue Viewer or the Manage queues
prevents delivery of Suspend-Queue cmdlet.
messages that are
currently in the queue. The
queue continues to accept
new messages, but no
messages leave the queue.

Resume queues This action reverses the Queue Viewer or the Manage queues
effect of the suspend Resume-Queue cmdlet.
queue action and enables
delivery of queued
messages to resume.

Retry queues This action immediately Queue Viewer or the Manage queues
tries to connect to the Retry-Queue cmdlet.
next hop. Without manual
intervention, when the
connection to the next
hop fails, the connection is
attempted a specific
number of times after a
specific time interval
between each attempt.
Whether the connection
attempt is manual or
automatic, any connection
attempt resets the next
retry time. For more
information, see Message
retry, resubmit, and
expiration intervals.
TASK DESCRIPTION TOOL TO USE INSTRUCTIONS

Resubmit messages in This action causes the Retry-Queue with the Manage queues
queues messages in the queue to Resubmit parameter
be resubmitted to the
Submission queue and to Note that you can use
go back through the Queue Viewer to resubmit
categorization process. messages, but only from
the poison message
queue. To resubmit a
message in poison
message, you resume the
message in Queue Viewer,
or by using the Resume-
Message cmdlet.

Suspend messages in This action temporarily Queue Viewer or the Manage messages in
queues prevents delivery of a Suspend-Message queues
message. You can use the cmdlet.
suspend message action
to prevent delivery of a
message to all the
recipients in a specific
queue or to all recipients
in all queues.

Resume messages in This action reverses the Queue Viewer or the Manage messages in
queues effect of the suspend Resume-Message cmdlet. queues
message action and
enables delivery of queued
messages to resume. You
can use the resume
message action to resume
delivery of a message to
all the recipients in a
specific queue or to all
recipients in all queues.

Remove messages from This action permanently Queue Viewer or the Manage messages in
queues prevents delivery of a Remove-Message queues
message. You can use the cmdlet.
remove message action to
prevent delivery of a
message to any recipients
in a specified queue or to
all recipients in all queues.
You can also configure the
remove message action to
send a non-delivery
report (NDR) to the
sender when the message
is removed.
TASK DESCRIPTION TOOL TO USE INSTRUCTIONS

Export messages from This action copies a Export-Message cmdlet Export messages from
queues message to the file path only. queues
that you specify. The
messages aren't deleted
from the queue, but a
copy of the message is
saved to a file location.
This enables
administrators or officials
in an organization to later
examine the messages.
Before you export a
message, you need to
suspend the message in
the queue so that typical
delivery doesn't continue
during the export process.
 Manage queues
6/10/2019 • 10 minutes to read • Edit Online

Applies to: Exchange Server 2013

In Microsoft Exchange Server 2013, you can use the Queue Viewer in the Exchange Toolbox or the Exchange
Management Shell to manage queues. For more information about using the queue management cmdlets in the
Exchange Management Shell, see Use the Exchange Management Shell to manage queues.

What do you need to know before you begin?

Estimated time to complete each procedure: 15 minutes
You need to be assigned permissions before you can perform this procedure or procedures. To see what
permissions you need, see the "Queues" entry in the Mail flow permissions topic.
For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard
shortcuts in the Exchange admin center.

TIP
Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.

View queues
Use Queue Viewer in the Exchange Toolbox to view queues
1. Click Start > All Programs > Microsoft Exchange 2013 > Exchange Toolbox.
2. In the Mail flow tools section, double-click Queue Viewer to open the tool in a new window.
3. In Queue Viewer, click the Queues tab. A list of all queues on the server to which you're connected is
displayed.
4. You can use the Export List link in the action pane to export the list of queues. For more information, see
Export lists from Queue Viewer.

Use the Shell to view queues

To view queues, use the following syntax.

Get-Queue [-Filter <Filter> -Server <ServerIdentity> -Include <Internal | External | Empty | DeliveryType> -
Exclude <Internal | External | Empty | DeliveryType>]

This example displays basic information about all non-empty queues on the Exchange 2013 Mailbox server
named Mailbox01.

Get-Queue -Server Mailbox01 -Exclude Empty

This example displays detailed information for all queues that contain more than 100 messages on the Mailbox
server on which the command is run.

Get-Queue -Filter {MessageCount -gt 100} | Format-List

Use the Shell to view queue summary information on multiple

Exchange servers
The Get-QueueDigest cmdlet provides a high-level, aggregate view of the state of queues on all servers within
a specific scope, for example, a DAG, an Active Directory site, a list of servers, or the entire Active Directory
forest. Note that queues on a subscribed Edge Transport server in the perimeter network aren't included in the
results. Also, Get-QueueDigest is available on an Edge Transport server, but the results are restricted to queues
on the Edge Transport server.

NOTE
By default, the Get-QueueDigest cmdlet displays delivery queues that contain ten or more messages, and the results are
between one and two minutes old. For instructions on how to change these default values, see Configure Get-
QueueDigest.

To view summary information about queues on multiple Exchange servers, run the following command:

Get-QueueDigest <-Server <ServerIdentity1,ServerIdentity2,..> | -Dag <DagIdentity1,DagIdentity2...> | -Site

<ADSiteIdentity1,ADSiteIdentity2...> | -Forest> [-Filter <Filter>]

This example displays summary information about the queues on all Exchange 2013 Mailbox servers in the
Active Directory site named FirstSite where the message count is greater than 100.

Get-QueueDigest -Site FirstSite -Filter {MessageCount -gt 100}

This example displays summary information about the queues on all Exchange 2013 Mailbox servers in the
database availability group (DAG ) named DAG01 where the queue status has the value Retry.

Get-QueueDigest -Dag DAG01 -Filter {Status -eq "Retry"}

Resume queues
By resuming a queue, you restart outgoing activities on a queue that has a status of Suspended. The queue must
have a status of Suspended for this action to have any effect. When you resume a queue, the status of messages
in the queue doesn't change. Messages that have a status of Suspended remain suspended and don't leave the
queue.

Use Queue Viewer in the Exchange Toolbox to resume queues

1. Click Start > All Programs > Microsoft Exchange 2013 > Exchange Toolbox.
2. In the Mail flow tools section, double-click Queue Viewer to open the tool in a new window.
3. In Queue Viewer, click the Queues tab. A list of all queues on the server to which you're connected is
displayed.
4. Click Create Filter, and enter your filter expression as follows:
 a. Select Status from the queue property drop-down list.
b. Select Equals from the comparison operator drop-down list.
c. Select Suspended from the value drop-down list.
5. Click Apply Filter. All queues on the server that are currently suspended are displayed.
6. Select one or more queues from the list, right-click, and then select Resume.

Use the Shell to resume queues

To resume queues, use the following syntax.

Resume-Queue <-Identity QueueIdentity | -Filter {QueueFilter} [-Server ServerIdentity]>

This example resumes all queues on the local server that have a status of Suspended.

Resume-Queue -Filter {Status -eq "Suspended"}

This example resumes the suspended delivery queue named contoso.com on the server named Mailbox01.

Resume-Queue -Identity Mailbox01\contoso.com

How do you know this worked?

To verify that you have successfully resumed a queue, do the following:
1. Use the Queue Viewer or the Get-Queue cmdlet to find the queue you attempted to resume.
2. Verify the queue Status property doesn't have the value Suspended .

Retry queues
When a transport server can't connect to the next hop, the delivery queue is put in a status of Retry. When you
retry a delivery queue by using Queue Viewer or the Shell, you force an immediate connection attempt and
override the next scheduled retry time. If the connection isn't successful, the retry interval timer is reset. The
delivery queue must be in a status of Retry for this action to have any effect.

Use Queue Viewer in the Exchange Toolbox to retry a queue

1. Click Start > All Programs > Microsoft Exchange 2013 > Exchange Toolbox.
2. In the Mail flow tools section, double-click Queue Viewer to open the tool in a new window.
3. In Queue Viewer, click the Queues tab. A list of all queues on the server to which you're connected is
displayed.
4. Click Create Filter, and enter your filter expression as follows:
a. Select Status from the queue property drop-down list.
b. Select Equals from the comparison operator drop-down list.
c. Select Retry from the value drop-down list.
5. Click Apply Filter. All queues that currently have a Retry status are displayed.
6. Select one or more queues from the list. Right-click, and then select Retry Queue. If the connection
attempt is successful, the queue status changes to Active. If no connection can be made, the queue
remains in a status of Retry and the next retry time is updated.

Use the Shell to retry a queue

To retry queues, use the following syntax.

Retry-Queue <-Identity QueueIdentity | -Filter QueueFilter [-Server ServerIdentity]>

This example retries all queues on the local server with the status of Retry.

Retry-Queue -Filter {status -eq "retry"}

This example retries the queue named contoso.com that's in the Retry state on the server named Mailbox01.

Retry-Queue -Identity Mailbox01\contoso.com

How do you know this worked?

To verify that you have successfully retried a queue, do the following:
1. Use the Queue Viewer or the Get-Queue cmdlet to find the queue you attempted to retry.
2. Verify the queue LastRetryTime property matches the time you attempted to retry the queue.

Resubmit messages in queues

Resubmitting a queue is similar to retrying a queue, except the messages are sent back to the Submission queue
for the categorizer to reprocess. You can resubmit messages that have the following status:
Delivery queues that have the status of Retry. The messages in the queues can't be in the Suspended state.
Messages in the Unreachable queue that aren't in the Suspended state.
Messages in the poison message queue.

Use the Shell to resubmit messages

To resubmit messages, use the following syntax.

Retry-Queue <-Identity QueueIdentity | -Filter {Status -eq "Retry"} -Server ServerIdentity> -Resubmit $true

This example resubmits all messages located in any delivery queues with the status of Retry on the server named
Mailbox01.

Retry-Queue -Filter {Status -eq "Retry"} -Server Mailbox01 -Resubmit $true

This example resubmits all messages located in the Unreachable queue on the server Mailbox01.

Retry-Queue -Identity Mailbox01\Unreachable -Resubmit $true

Resubmit messages in the poison message queue
You resubmit messages in the poison message queue by resuming the message. You can use the Queue Viewer
or the Shell to resubmit messages from the poison message queue. Note that the poison message queue is only
visible in Queue Viewer when there are messages in the poison message queue.

NOTE
The poison message queue contains messages that are determined to be harmful to the Exchange system after a server
failure. The messages may be genuinely harmful in their content or format. Alternatively, they may be victims of a poorly
written agent that crashed the Exchange server while it was processing the supposedly bad messages. If you're unsure of
the safety of the messages in the poison message queue, you should export the messages to files so that you can examine
them. For more information, see Export messages from queues.

Use Queue Viewer in the Exchange Toolbox to resubmit messages in

the poison message queue
1. Click Start > All Programs > Microsoft Exchange 2013 > Exchange Toolbox.
2. In the Mail flow tools section, double-click Queue Viewer to open the tool in a new window.
3. In Queue Viewer, click the Queues tab. A list of all queues on the server to which you're connected is
displayed.
4. Click the poison message queue. In the action pane, select View Messages.
5. Select one or more messages from the list, right-click, and select Resume.

Use the Shell to resubmit messages in the poison message queue

To resubmit a message from the poison message queue, perform the following steps.
1. Find the identity of the message by running the following command.

Get-Message -Queue Poison | Format-Table Identity

2. Use the identity of the message from the previous step in the following command.

Resume-Message <PoisonMessageIdentity>

This example resumes a message from the poison message queue that has the message Identity value of
222.

Resume-Message 222

How do you know this worked?

To verify that you have successfully resubmitted a message from the poison message queue, do the following:
1. Use the Queue Viewer or the Get-Queue cmdlet to view the poison message queue where you attempted
to resubmit the message.
2. Verify the message is no longer in the poison message queue. Note that an empty poison message queue
doesn't appear in the Queue Viewer or the Get-Queue cmdlet. Therefore, if the message you resubmitted
 was the only message in the poison message queue, and the poison message queue is no longer visible,
that is also an indication of a successful message resubmission.

Suspend queues
When you suspend a queue, you prevent messages from leaving the queue, but you don't change the status of
messages in the queue. Messages that are in delivery through SMTP -send will finish operations. You can
suspend a queue to stop mail flow, and then suspend one or more messages in the queue. When you resume the
queue, the messages that were suspended won't leave the queue.
You can suspend a queue that has a status of Active or Retry. You can also suspend the Unreachable queue and
the Submission queue.
If you suspend the Unreachable queue, items won't be resubmitted to the categorizer when configuration
updates are received by the transport server until the queue is resumed. If you suspend the Submission queue,
messages won't be picked up by the categorizer until the queue is resumed.

Use Queue Viewer in the Exchange Toolbox to suspend a queue

1. Click Start > All Programs > Microsoft Exchange 2013 > Exchange Toolbox.
2. In the Mail flow tools section, double-click Queue Viewer to open the tool in a new window.
3. In Queue Viewer, click the Queues tab. A list of all queues on the server to which you're connected is
displayed. You can create a filter to display only queues that meet specific criteria.
4. Select one or more queues, right-click, and then select Suspend.

Use the Shell to suspend a queue

To suspend a queue, use the following syntax.

Suspend-Queue <-Identity QueueIdentity | -Filter {QueueFilter} [-Server ServerIdentity]>

This example suspends all queues on the local server that have a message count equal to or greater than 1,000
and that have a status of Retry.

Suspend-Queue -Filter {MessageCount -ge 1000 -and Status -eq "Retry"}

This example suspends the queue named contoso.com on the server named Mailbox01.

Suspend-Queue -Identity Mailbox01\contoso.com

How do you know this worked?

To verify that you have successfully suspended a queue, do the following:
1. Use the Queue Viewer or the Get-Queue cmdlet to find the queue you attempted to suspend.
2. Verify the queue Status property has the value Suspended .
 Use the Exchange Management Shell to manage
queues
6/6/2019 • 21 minutes to read • Edit Online

Applies to: Exchange Server 2013

As in previous versions of Exchange, you can use the Exchange Management Shell in Microsoft Exchange Server
2013 to view information about queues and the messages in those queues, and to perform management actions
on queues and messages. In Exchange 2013, queues exist on Mailbox servers and Edge Transport servers. This
topic refers to these servers as transport servers.
When you use the Shell to view and manage queues and messages in queues on transport servers, it's important
to understand how to identify the queues or messages you want to manage. Typically, transport servers contain a
large number of queues and messages to be delivered. You use the filtering parameters that are available on the
queue and message management cmdlets to identify the queues or messages that you want to view or manage.
Note that you can also use Queue Viewer in the Exchange Toolbox to manage queues and messages in queues.
However, the queue and message viewing cmdlets support more filterable properties and filter options than
Queue Viewer. For more information about using Queue Viewer, see Queue Viewer.

Queue filtering parameters

The following table describes the filtering parameters that are available on the queue management cmdlets.

CMDLET FILTERING PARAMETERS COMMENTS

Get-Queue Identity You can't use the Identity

parameter in the same command
Filter with the Filter parameters. You can
Include use the Include and Exclude
parameters with the Filter
Exclude parameter in the same command.

Resume-Queue Identity You need to use either the Identity

parameter or the Filter parameter,
Retry-Queue Filter but you can't use both in the same
Suspend-Queue command.

Get-QueueDigest Server You need to use the Server, Dag,

Site, or Forest parameter, but you
Dag can't use any of them together in
Site the same command. You can use
the Filter parameter with any of the
Forest other filtering parameters.
Filter

Note that a Server parameter is available on all queue management cmdlets. On the Get-QueueDigest cmdlet,
the Server parameter is a scope parameter that specifies the server or servers where you want to view summary
information about queues. On all other queue management cmdlets, you use the Server parameter to connect to a
specific server, and run the queue management commands on that server. You can use the Server parameter with
or without the Filter parameter, but you can't use the Server parameter with the Identity parameter. You use the
transport server's hostname or FQDN with the Server parameter.

Queue identity
The Identity parameter on the queue management cmdlets identifies a specific queue. When you use the Identity
parameter, you can't specify any other queue filtering parameters, because you've already uniquely identified the
queue. The Identity parameter uses the basic syntax <Server>\<Queue>.
The <Server> placeholder is the hostname or FQDN of the Exchange server, for example mailbox01 or
mailbox01.contoso.com . If you omit the <Server> qualifier, the local server is implied.

The <Queue> placeholder accepts one of the following values:

Persistent queue name: Persistent queues have unique, consistent names on all Mailbox or Edge
Transport servers. The persistent queue names are:
Submission: This queue contains messages waiting to be processed by the categorizer.
Unreachable: This queue contains messages that can't be routed. This queue doesn't exist until
messages are placed in it.
Poison: This queue contains messages that are determined to be harmful to the Exchange server.
This queue doesn't exist until messages are placed in it.
Delivery queue name: The name of a delivery queue is the value of the NextHopDomain property of
the queue. For example, the queue name could be the address space of a Send connector, the name of an
Active Directory site, or the name of a DAG. For more information, see the "NextHopSolutionKey" section in
the Queues topic.
Queue integer: Delivery queues and shadow queues are assigned a unique integer value in the queue
database. However, you need to run the Get-Queue cmdlet to find the integer value for the queue in the
Identity or QueueIdentity properties.
Shadow queue name: A shadow queue uses the syntax Shadow\ <QueueInteger>
The following table summarizes the syntax you can use with Identity parameter on the queue management
cmdlets. In all values, <Server> is the hostname or FQDN of the server.
Queue identity formats
IDENTITY PARAMETER VALUE DESCRIPTION

<Server>\<PersistentQueueName> or A persistent queue on the specified server or the local

<PersistentQueueName> server.
<PersistentQueueName> is Submission , Unreachable
, or Poison .

<Server>\<NextHopDomain> or <NextHopDomain> A delivery queue on the specified server or the local

server.
<NextHopDomain> is a routing destination or delivery
group for the messages in the queue. For more
information, see the "NextHopSolutionKey" section in the
Queues topic.
 IDENTITY PARAMETER VALUE DESCRIPTION

<Server>\<QueueInteger> or <QueueInteger> A delivery queue on the specified server or the local

server.
<QueueInteger> is the unique integer value of the queue
that's displayed in the Identity property of the Get-
Queue cmdlet.

<Server>\Shadow\<QueueInteger> or A shadow queue on the specified server or the local

Shadow\<QueueInteger> server.

<Server>\* or * All queues on the specified server or the local server. Note
that these values can only be used with the Get-Queue
cmdlet.

Queue Filter parameter

You can use the Filter parameter on the all of the queue management cmdlets to specify the queues you want to
view or manage based on the properties of the queues. The Filter parameter creates an expression with
comparison operators that restricts the queue operation to queues that meet the filter criteria. You can use the
-and logical operator to specify multiple conditions that the results must match.

For a complete list of queue properties you can use with the Filter parameter, see Queues.
For a list of comparison operators you can use with the Filter parameter, see the Comparison operators to use
when filtering queues or messages section in this topic.
For examples of procedures that use the Filter parameter to view and manage queues, see Manage queues.

Include and Exclude parameters

Exchange 2013 has the Include and Exclude parameters available on the Get-Queue cmdlet. You can use these
parameters individually, together, and with the Filter parameter to fine-tune your queue results on the local or
specified transport server. For example, you can:
Exclude empty queues from the results.
Exclude queues to external destinations from the results.
Include queues that have a specific value of DeliveryType in the results.
The Include and Exclude parameters use the following queue properties to filter queues:

VALUE DESCRIPTION SHELL CODE EXAMPLE

DeliveryType This value includes or excludes This example returns all delivery
queues based on the queues on the local server where
DeliveryType property. You can the next hop is a Send connector
specify multiple values separated by on the local server that's configured
commas. The valid values for for smart host routing:
DeliveryType are explained in the
Get-Queue -Include
"NextHopSolutionKey" section in SmartHostConnectorDelivery
the topic Queues topic.
 VALUE DESCRIPTION SHELL CODE EXAMPLE

Empty This value includes or excludes This example returns all queues on
empty queues. Empty queues have the local server that contain
the value 0 in the MessageCount messages
property.
Get-Queue -Exclude Empty

External This value includes or excludes This example returns all internal
queues that have the value queues on the local server
External in the
Get-Queue -Exclude External
NextHopCategory property.
External queues always have one of
the following values for
DeliveryType:
DeliveryAgent

DnsConnectorDelivery

NonSmtpGatewayDelivery

SmartHostConnectorDelivery

For more information, see the

"NextHopSolutionKey" section in
the Queues topic.

Internal This value includes or excludes This example returns all internal
queues that have the value queues on the local server.
Internal in the
Get-Queue -Include Internal
NextHopCategory property. For
more information, see the
"NextHopSolutionKey" section in
the Queues topic.

Note that you can duplicate the functionality of the Include and Exclude parameters by using the Filter parameter.
For example, the command Get-Queue -Exclude Empty yields the same result as
Get-Queue -Filter {MessageCount -gt 0} . However, the syntax of the Include and Exclude parameters is simpler
and easier to remember.

Get-QueueDigest
Exchange 2013 adds a new queue cmdlet named Get-QueueDigest. This cmdlet allows you to view information
about some or all of the queues in your Exchange organization by using a single command. Specifically, the Get-
QueueDigest cmdlet allows you to view information about queues based on their location on servers, in DAGs, in
Active Directory sites, or in the whole Active Directory forest. Note that queues on a subscribed Edge Transport
server in the perimeter network aren't included in the results. Also, Get-QueueDigest is available on an Edge
Transport server, but the results are restricted to queues on the Edge Transport server.

NOTE
By default, the Get-QueueDigest cmdlet displays delivery queues that contain ten or more messages, and the results are
between one and two minutes old. For instructions on how to change these default values, see Configure Get-QueueDigest.

The filtering and sorting parameters that are available with the Get-QueueDigest cmdlet are described in the
following table.

PARAMETER DESCRIPTION

Dag, Server, or Site These parameters are mutually exclusive, and set the
scope for the cmdlet. You need to specify one of these
parameters or the Forest switch. Typically, you would use
the name of the server, DAG or Active Directory site, but
you can use any value that uniquely identifies the server,
DAG, or site. You can specify multiple servers, DAGs, or
sites separated by commas.

Forest This switch is required if you aren't using the Dag, Server,
or Site parameters. You don't specify a value with this
switch. By using this switch, you get queues from all
Exchange 2013 Mailbox servers in the Active Directory
forest. You can't use the Forest switch to view queues in
remote Active Directory forests.

DetailsLevel This parameter accepts the values None , Normal , and

Verbose . The default value is Normal . When you use
the value None , the queue name is omitted from the
Details column in the results.

Filter This parameter allows you to filter queues based on the

queue properties. You can use any of the filterable queue
properties as described in the Queue filters topic.

GroupBy This parameter groups the queue results. You can group
the results by one of the following properties:
DeliveryType
LastError
NextHopCategory
NextHopDomain
NextHopKey
Status
ServerName
By default, the results are grouped by NextHopDomain .
For information about these queue properties, see Queue
filters.

ResultSize This parameter limits the queue results to the value you
specify. The queues are sorted in descending order based
on the number of messages in the queue, and grouped
by the value specified by the GroupBy parameter. The
default value is 1000. This means that by default, the
command displays the top 1000 queues grouped by
NextHopDomain, and sorted by the queues containing
the most messages to the queues containing the least
messages.
 PARAMETER DESCRIPTION

Timeout The parameter specifies the number of seconds before the

operation times out. The default value is 00:00:10 or 10
seconds.

This example returns all non-empty external queues on the Exchange 2013 Mailbox servers named
Mailbox01,Mailbox02, and Mailbox03.

Get-QueueDigest -Server Mailbox01,Mailbox02,Mailbox03 -Include External -Exclude Empty

Message filtering parameters

The following table describes the filtering parameters that are available on the message management cmdlets.

CMDLET FILTERING PARAMETERS COMMENTS

Get-Message Identity All filtering parameters are mutually

exclusive, and you can use them
Filter together in the same command.
Queue

Remove-Message Identity You need to use either the Identity

parameter or the Filter parameter,
Resume-Message Filter but you can't use both in the same
Suspend-Message command.

Export-Message Identity The Identity parameter is required.

Note that a Server parameter is available on all message management cmdlets except for the Export-Message
cmdlet. You use the Server parameter to connect to a specific server, and run the message management
commands on that server. You can use the Server parameter with or without the Filter parameter, but you can't use
the Server parameter with the Identity parameter. You use the transport server's hostname or FQDN with the
Server parameter.

Message identity
The Identity parameter on the message management cmdlets identifies a specific message in one or more queues.
When you use the Identity parameter, you can't specify any other message filtering parameters, because you've
already uniquely identified the message. The Identity parameter uses the basic syntax
<Server>\<Queue>\<MessageInteger>.
The <Server> placeholder is the hostname or FQDN of the Exchange server, for example mailbox01 or
mailbox01.contoso.com . If you omit the <Server> qualifier, the local server is implied.

The <Queue> placeholder accepts the identity of the queue as described in the "Queue identity" section in this
topic. For example, you can use the persistent queue name, the NextHopDomain value, or the unique integer
value of the queue in the queue database.
The <MessageInteger> placeholder represents the unique integer value that's assigned to the message when it
first enters the queue database on the server. If the message is sent to multiple recipients that require multiple
queues, all copies of the message in all queues in the queue database have the same integer value. However, you
need to run the Get-Message cmdlet to find the integer value for the message in the Identity or
MessageIdentity properties.
The following table summarizes the syntax you can use with Identity parameter on the message management
cmdlets. In all values, <Server> is the hostname or FQDN of the server.
Message identity formats
IDENTITY PARAMETER VALUE DESCRIPTION

<Server>\<Queue>\<MessageInteger> or A message in a specific queue on the specified server or

<Queue>\<MessageInteger> the local server.
<MessageInteger> is the unique integer value of the
message that's displayed in the Identity property of the
Get-Message cmdlet.
<Queue> represents one of the following values:
Persistent queue name The value Submission ,
Unreachable , or Poison .

Delivery queue name The value of the

NextHopDomain property of the queue, which is
effectively the name of the queue. This value could
be a routing destination or a delivery group. For
more information, see the "NextHopSolutionKey"
section in the Queues topic.
Queue integer The unique integer value of the
delivery queue or shadow queue that's displayed
in the Identity property of the Get-Message or
Get-Queue cmdlets.
Shadow queue identity The shadow queue
identity uses the syntax Shadow\<QueueInteger> .

<Server>\*\<MessageInteger> or All copies of the message in all queues in the queue

*\<MessageInteger> or <MessageInteger> database on the specified server or the local server.

Message Filter parameter

You can use the Filter parameter on the Get-Message, Remove-Message, Resume-Message, and Suspend-
Message cmdlets to specify the messages you want to view or manage based on the properties of the messages.
The Filter parameter creates an expression with comparison operators that restricts the message operation to
messages that meet the filter criteria. You can use the -and logical operator to specify multiple conditions that the
results must match.
For a complete list of message properties you can use with the Filter parameter, see Queues.
For a list of comparison operators you can use with the Filter parameter, see the Comparison operators to use
when filtering queues or messages section in this topic.
For examples of procedures that use the Filter parameter to view and manage messages, see Manage queues.

Queue parameter
The Queue parameter is used only with the Get-Message cmdlet. You can use this parameter to get all messages
in a specific queue, or all messages from multiple queues by using the wildcard character (*).When you use the
Queue parameter, use the queue identity format <Server>\<Queue> as described in the "Queue identity" section
in this topic.

Comparison operators to use when filtering queues or messages

When you create a queue or message filter expression by using the Filter parameter, you need to include an
comparison operator for the property value to match. The following table shows the comparison operators that
you can use in a filter expression and how each operator functions. For all operators, the values compared aren't
case sensitive.
Comparison operators
OPERATOR FUNCTION SHELL CODE EXAMPLE

-eq This operator is used to specify that To display a list of all queues that
the results must exactly match the have a status of Retry:
property value that's supplied in
Get-Queue -Filter {Status -eq
the expression. "Retry"}

To display a list of all messages that

have a status of Retry:
Get-Message -Filter {Status -
eq "Retry"}

-ne This operator is used to specify that To display a list of all queues that
the results shouldn't match the don't have a status of Active:
property value that's supplied in
Get-Queue -Filter {Status -ne
the expression. "Active"}

To display a list of all messages that

don't ha