Omni-ts.com - Documentation and Knowledgebase
Knowledgebase Search     Classic Search

Prepare the Exchange Mailbox for the Riva Connection User

Article ID: 467
Last updated: 15 Oct, 2014
Views: 14344

The Riva Exchange MAPI and EWS connections (Riva On Premise) and EWS connection wizard (Riva Cloud CORPORATE subscription) need to use the credentials of a fully enabled Exchange mailbox user that is configured to support IMPERSONATION into the mailboxes of the users that Riva will sync to (referred to as the "target users").  This mailbox user is referred to as the "Riva connection user" for Exchange.

This article will explain the system requirements and procedures for configuring the Exchange mailbox for the "Riva connection user" so that it will meet the requirements to support Riva "impersonation":

Procedures in this article apply to:

  • On-Premise Riva Server deployments, and
  • Riva Cloud Corporate subscriptions.

Basic Requirement for the Riva Connection User to Exchange

The Exchange mailbox user must meet the following requirements:

  • Must be a fully enabled Exchange mailbox.

  • Mailbox must be visible in the GAL (Global Access List).

  • Must have been logged into at least one time to create the default folder structure and permissions for a mailbox.

  • Must not be a member of the AD Domain Admins or Enterprise Admins groups (for On-Premise Exchange systems only).

  • Must be configured with the applicable full permissions for delegate access or Exchange application impersonation (see below).

How Riva CRM Integration connects to different versions of Exchange

The Riva CRM Agent uses an Exchange service account to connect to through the Client Access Server (CAS).  That connection is configured in the Riva management application.  The preferred connection type depends on the version of Exchange.

Exchange 2013 / Office 365 Refresh

Microsoft Exchange Web Services (EWS) are used to connect to Exchange 2013 and Office 365 (refresh).  Exchange 2013 . EWS requirements are the same as for Exchange 2010.  Exchange 2013 has replaced Exchange Management Console with Exchange Web Console so steps to enable Delegate Full Access permissions have changed. 

Exchange 2010 (On Premise or Hosted)

Microsoft Exchange Web Services (EWS) are used to connect to Exchange 2010, BPOS and Office 365.  Exchange 2010 includes many improvements to the EWS feature set and the deprecation of WebDAV.  EWS 2010 now completely replaces the WebDAV features and the WebDAV API is no longer used.  EWS is traditionally installed on the same server as Outlook Web Access (CAS - Client Access Server).  If EWS is not available, the Exchange 2003 Extended MAPI connection type is supported.

Exchange 2007 SP 1+

Microsoft Exchange Web Services (EWS) and Microsoft Exchange WebDAV API are used.  The core synchronization capabilities are made via EWS and supplementary capabilities like pre-defining custom fields on a folder and extending the Master Category List are made using WebDAV.  Both the EWS and WebDAV API are traditionally installed on the same server as Outlook Web Access (CAS - Client Access Server).  If EWS is not available, the Exchange 2003 Extended MAPI connection type is supported.

Exchange 2003

The connection API used for Exchange 2003 is the Microsoft Extended Messaging API (MAPI).  MAPI makes use of RPC (Remote Procedure Call).  The design around MAPI and RPC make it a very chatty service and can use many different TCP ports.  For sites where the Exchange server is off-site or hosted, an additional tunnelling over HTTP (RPC-over-HTTP / RoH / Outlook Anywhere) can be used to simplify firewall rules.  The RoH server component is traditionally installed on the same server as Outlook Web Access (CAS - Client Access Server). 

The Microsoft Office Outlook client (2003, 2007, 2010) MUST be installed on the Riva server to provide the Extended MAPI provider.  Because the Outlook client is required, Riva cannot be installed on your Exchange server.

Riva Impersonation Methods

Riva connections to Exchange supports two Exchange "Impersonation Methods":

  • "Impersonation" — is a simpler means of authentication for EWS connections. Impersonation access rights are granted by an administrator and cannot be removed or denied by a target user.  The one limitation with "Impersonation" is that it does not support the WebDAV API that Riva uses for EWS connections to Exchange 2007.  Although "Impersonation" is available for Exchange 2007 connections, it is not recommended:
    • Exchange 2010 and 2013 EWS — recommended
    • Exchange 2007 EWS — supported¹
  • "Delegate Access" — normally used for one-to-one relationships in a connection.  Administrators and users can grant and remove delegate access.  Riva can use it to establish a one-to-one relationship between the Riva connection account and each target user.  Riva can use "Delegate Access" for the following types of Riva connections:
    • Exchange 2010/2013 using EWS connections — supported
    • Exchange 2007 using EWS connections — recommended
    • Exchange 2007/2010 using MAPI connections — required
    • Exchange 2003 and all MAPI-based connections — required

Exchange Version

Connection Method Delegate Full Access Permissions

Exchange ApplicationImpersonation
Role

Exchange 2003, 2007 & 2010

MAPI - Direct TCP Required Not supported
Exchange 2003 MAPI - RPC over HTTP Required Not supported
Exchange
2007 & 2010
MAPI - Outlook Anywhere Required Not supported
Exchange 2007 Exchange Web Service
Exchange WebDAV¹
Recommended Supported

Not Recommended

Exchange 2010 & 2013

Office 365 - Exchange Online

Exchange Web Service Supported Recommended

 ¹ Exchange WebDAV used for Exchange 2007 - Optionally, Riva leverages WebDAV to push user-defined fields and categories to the Master Category List.  Exchange 2010 does not use WebDAV.

MAPI is not supported with Exchange 2013 and Office 365

Prepare the Exchange (On Premise) Connection Account for Riva

Riva makes use of the built-in Exchange "Full Access" security model to allow it to access Exchange mailboxes without having to have each user's password.  This is a standard process that is used by many services, including BlackBerry Enterprise Server, to implement secure user impersonation. 

The Riva connection to the target Exchange CAS must use the credentials of an AD/Exchange account that has full access permissions to the target user(s) mailbox(es).  A best practise is to create a AD/Exchange user account called "RivaCRM" or "Riva_SVC". This connection account must meet the following requirements:

  • must be an AD user account with fully enabled Exchange mailbox.
  • must be visible in the Global Access List (GAL)
  • must NOT be a member of "Domain Admins"
Note:  Exchange automatically places a "deny receive as" and a "deny send as" on any account with "Domain Admin" membership.  It is best that the user selected for the Riva Exchange Connection not be a member of the "Domain Admins" group.

For On-Premise Exchange environments, granting Full Access to a target user mailbox automatically grants "Delegate Access". For Hosted Exchange environments, refer to the service provider documentation on granting "Delegate Access".

See the following sections to configure full access permissions:

Configure Delegate Full Access Permissions - Exchange 2007 & 2010

Grant Full Access Permissions to Individual Target Users:  Full access permissions can be granted to individual users using Exchange Management Console.

Perform this procedure on each target sync user to grant full access permissions to the Riva connection account.:

  1. Start the Exchange Management Console.
  2. In the console tree, click Recipient Configuration.
  3. In the result pane, select the "end-user sync target mailbox" for which you want to grant the Full Access permission.
  4. In the action pane, under the mailbox name, click Manage Full Access Permission. The Manage Full Access Permission wizard opens.
  5. On the Manage Full Access Permission page, click Add.
  6. In Select User or Group, select the user to which you want to grant the Full Access permission, and then click OK.
  7. Click Manage.



  8. On the Completion page, the Summary states whether the Full Access permission was successfully granted. The summary also displays the Exchange Management Shell command that was used to grant the Full Access permission.
  9. Click Finish.

Configure Delegate Full Access Permissions Using Exchange Management Shell - Exchange 2007, 2010 & 2013

Exchange Management Shell a command line utility introduced in Exchange server 2007, which provides an administrator the ability to configure, administer, and manage an Exchange 2007 server environment using text commands instead of solely a graphical user interface (GUI).

Administrators can use scripted commands, called cmdlets to pass instructions to the Exchange system. Administrators can use either the Add-MailboxPermission or Add-AdPermission cmdlet to assign the necessary full access permissions.

Mailbox Permissions

When security policies dictate that full access permissions can only be granted to specific mailboxes, use the Add-MailboxPermission.  This is an Exchange permission that is restricted to mailboxes only.  This permission in not inheritable, so it cannot be assigned to Storage Servers, Storage Groups, or Storage Databases.  A Windows Powershell script can be used in EMS to apply this permission when a mailbox is created, or to bulk assign the permission to multiple mailboxes. 

Note:  Starting with Exchange 2010 SP1, Delegate Full Access implemented automapping by default.  In Microsoft Outlook 2010 and in Microsoft Office Outlook 2007, Autodiscover automatically maps to any mailbox for which a user has full access permissions. Autodiscover automatically loads all mailboxes for which the user has full access permissions.  This is not desired for the Riva connection user so add the parameter - AutoMapping $false to the end of the Add-MailboxPermission line:

Add-MailboxPermission - In the Exchange Management Shell run the following command to grant full access permissions for a single mailbox:

Add-MailboxPermission -Identity "targetmailbox" -User "Riva Connection User" -AccessRights FullAccess -AutoMapping $false

Add-MailboxPermission -Identity “isample” -User “DEV03-EX07\rivacrm” -AccessRights FullAccess -AutoMapping $false

To confirm that what permissions are assigned to a mailbox:

Get-MailboxPermission -Identity "targetmailbox" | Format-List

Get-MailboxPermission -Identity “isample” | Format-List

You can use Get-Mailbox to get mailboxes and pipe them to the Add-MailboxPermission cmdlet.  To get mailboxes in an Organizational Unit or container:

Get-Mailbox -OrganizationalUnit "MyOU" | Add-MailboxPermission -User "Trusted User" -AccessRights FullAccess -AutoMapping $false

get-Mailbox -OrganizationUnit "OU=NewYork,OU=Users" | Add-MailboxPermission -User “DEV03-EX07\rivacrm” -AccessRights FullAccess -AutoMapping $false

AD Permissions

AD permissions can be assigned to objects and those permissions will be inherited by corresponding child objects.  You can use Add-ADPermissions to grant ExtendedRights to an Exchange server or a specific Storage Group database. 

Advantage with using AD Permissions - Since this permission is inheritable, if a new mailbox is added to the target Exchange server or store, it will inherit the EntendedRights assignment.

Ensure Inheritance is Enabled - if the plan is to grant full access permissions on the Exchange server level so those permissions flow down to user mailboxes in Storage Group mailbox store databases, inheritance must be granted.  You can verify/grant inheritance permissions using ADSI Edit. 

  1. Install ADSI Edit and then start ADSI Edit (see Installing ADSI Edit)
  2. Click Start, click Run, type adsiedit.msc, and then click OK.
  3. Locate the object in question, right-click the object, and then click Properties.
  4. On the Security tab, click Advanced.
  5. Click Allow inheritable permissions from the parent to propagate to this object and all child objects to re-enable permissions inheritance.
  6. Click OK two times to apply the change.
  7. Wait for Active Directory replication to propagate the changes, or force Active Directory replication if it is necessary.  For more information about how to force Active Directory replication, see Microsoft Knowledge Base article 232072, Initiating Replication Between Active Directory Direct Replication Partners.

Add-ADPermission - To grant full access to user mailboxes, you need to grant the equivalent of the Add Information Store, Receive-As, and Send-As permissions that were granted for Exchange 2003 systems.

Run the following command to add the permission to the Exchange server:

Get-MailboxServer "<Exchange-server-name>" | Add-ADpermission -user "<Riva-connection-user>" -AccessRights GenericRead, GenericWrite -ExtendedRights Send-As, Receive-As, ms-Exch-Store-Admin

Get-MailboxServer "EX-01" | Add-ADpermission -User "DEV03-EX07\rivacrm" -AccessRights GenericRead, GenericWrite -ExtendedRights Send-As, Receive-As, ms-Exch-Store-Admin

Run the following command to add permissions to an Exchange Store Database (if inheritance is not and will not be enabled):

Get-MailboxDatabase "<Exchange-server-name>"\"First Storage Group\Mailbox Database" | Add-ADpermission -user "<Riva-connection-user>" -AccessRights GenericRead, GenericWrite -ExtendedRights Send-As, Receive-As, ms-Exch-Store-Admin

Get-MailboxDatabase "EX-01"\"First Storage Group\Mailbox Database" | Add-ADpermission -user "DEV03-EX07\rivacrm" -AccessRights GenericRead, GenericWrite -ExtendedRights Send-As, Receive-As, ms-Exch-Store-Admin

To verify that permissions have been added to the Exchange Store Database:

Get-MailboxDatabase "<Exchange-server-name>"\"First Storage Group\Mailbox Database" | Get-ADpermission -user "<Riva-connection-user>" | Format-List

Get-MailboxDatabase "EX-01"\"First Storage Group\Mailbox Database" | Get-ADpermission -user "DEV03-EX07\rivacrm" | Format-List

Information Store Cache - It may take up to 2 hours for the permissions to propogate throughout the Exchange stores.  To effect immediate propogation, stop and start the Exchange Information Store service.

Tip - some Exchange administrators have reported that using the Add-ADPermission appears to work but running the Impersonation test in the Riva EWS connection will fail with some of the modules reporting "False".  This can be the result of the Exchange Information Store cache not refreshing.

References: 

  1. "Understanding Mailbox Permissions" - http://technet.microsoft.com/en-us/library/bb123879(EXCHG.80).aspx
  2. "How to Allow Mailbox Access" - http://technet.microsoft.com/en-us/library/aa996343%28EXCHG.80%29.aspx
  3. "Add-MailboxPermission" - http://technet.microsoft.com/en-us/library/bb124097(EXCHG.80).aspx
  4. "How to remove automapping for a shared mailbox in Office 365" - http://support.microsoft.com/kb/2646504
  5. "Disable Outlook Auto-Mapping with Full Access Mailboxes" - http://technet.microsoft.com/en-us/library/hh529943(v=exchg.141).aspx
  6. "Add-ADPermission" - http://technet.microsoft.com/en-us/library/bb124403(EXCHG.80).aspx
  7. "Exchange Server 2007 recipient management one-liners" - http://blogs.technet.com/b/exchange/archive/2006/09/05/3394830.aspx


Configure Exchange Impersonation Using Exchange Management Shell - Exchange 2010 & 2013

Setting up Exchange Impersonation for Exchange Server 2010/2013 is a lot easier than it is for Exchange Server 2007. The Roll-Based Access Control (RBAC) mechanism allows an administrator to define a ManageScope of a collection of users and assign that ManagementScope to the ApplicationImpersonation role, which enables applications to impersonate users in an Exchange organization to perform tasks on behalf of that user.  Once that is done, any new users that are added into the ManagementScope are automatically subjected to ApplicationImpersonation (Exchange Impersonation).

Option 1) Configure Exchange Impersonation for all users in an organization

In this case, the objective is to assign Exchange Impersonation to a "rivasvc" user.  Riva would use the credentials of the "rivasvc" user to impersonate into any mailbox in the Exchange organization.

  1. Open the Exchange Management Shell.
  2. run the New-ManagementRoleAssignment cmdlet to add the permission to impersonate to the specified user. The following example shows how to configure Exchange Impersonation to enable a service account to impersonate all other users in an organization.

    New-ManagementRoleAssignment –Name ManagementRoleName –Role:ApplicationImpersonation –User cnRivaServiceAccount

    New-ManagementRoleAssignment –Name "RivaCRM Sync Role" –Role:ApplicationImpersonation –User rivasvc

Option 2) Configure Exchange Impersonation for specific users or groups of users

Step 1 - Define Management Scope - The first step is to define a ManagementScope which is a collection of target users.  They key is defining a suitable recipient filter to accurately identify the collection of target users:

New-ManagementScope -Name ManagementScopeName -RecipientRoot (Optional root OU in AD) -RecipientRestrictionFilter { recipient filter }

This example creates a scope for mailboxes within the "Executives" OU in the contoso.com AD domain.

New-ManagementScope -Name "RivaCRM TargetUsersScope" -RecipientRoot "contoso.com/Executives" -RecipientRestrictionFilter { RecipientType -eq "UserMailbox" }

This example creates a scope for membership of an AD group in the contoso.com AD domain.

New-ManagementScope -Name "RivaCRM TargetUsersScope" -RecipientRestrictionFilter {MemberofGroup -eq "CN=Riva Sync Exch Impersonation,OU=Users,OU=Resources,DC=contoso,DC=com"}

This example creates a scope for any recipient where the value of the property City equals the string "Vancouver":

New-ManagementScope -Name "RivaCRM TargetUsersScope" -RecipientRestrictionFilter { City -eq "Vancouver" }

This example shows a complex query used the the filter for any recipient where the City equals "Vancouver and the Department equals "Sales" (must both be true) or the Title is similar to "Manager":

New-ManagementScope -Name "RivaCRM TargetUsersScope" -RecipientRestrictionFilter { ((City -eq "Vancouver") -And (Department -Eq "Sales")) -Or (Title -Like "*Manager*") }

Use the Get-ManagementScope to display the scope of target users to a formatted list:

Get-ManagementScope "RivaCRM TargetUsersScope" | Format-List

Refer to references 1, 2, 3, 4, and 5

Step 2 - Role Assignment - The second step is to assign one or more management roles to the management scope. For Riva, assign an role called  RivaCRM SyncRole role for the rivasvc user to the "RivaCRM TargetUsersScope" management scope that was created in the first step:

New-ManagementRoleAssignment -Name "ManagementRoleName" -Role:ApplicationImpersonation -User "username" -CustomRecipientWriteScope "ManagementScopeName"

New-ManagementRoleAssignment -Name "RivaCRM SyncRole" -Role:ApplicationImpersonation -User "rivasvc" -CustomRecipientWriteScope "RivaCRM TargetUsersScope"

References: 

  1. "Configuring Exchange Impersonation" for Exchange 2010 - http://msdn.microsoft.com/en-us/library/bb204095.aspx
  2. "New-ManagementScope" for Exchange 2010 - http://technet.microsoft.com/en-us/library/dd335137.aspx
  3. "New-ManagementScope" for Exchange 2010 SP2 - http://technet.microsoft.com/en-us/library/dd335137.aspx
  4. "Understanding Management Role Scopes", specifically "Recipient Filter Scopes" - http://technet.microsoft.com/en-us/library/dd335146.aspx#Recipient
  5. "Understanding Management Rols Scope Filters" - http://technet.microsoft.com/en-us/library/dd298043.aspx
  6. "New-ManagementRoleAssignment" for Exchange 2010 - http://technet.microsoft.com/en-us/library/dd335193.aspx

Configure Exchange Impersonation Using Exchange Management Shell - Exchange 2007

Exchange Server 2007 makes use of Access Control Lists (ACL) to apply the permissions. You apply two rights; one that authorizes the Service Account access to Exchange Impersonation rights on the Client Access Server (CAS), and the other that is applied to either an AD account or an entire Mailbox database. This limits impersonation to an account-by-account basis, or to an entire mailbox database.

Information:  Remember that Exchange Impersonation for EWS 2007 is not compatible with WebDAV, which Riva is dependant on for synchronizing "user defined fields" and categories to the Master Category List.  The use of Exchange Impersonation for EWS 2007 is not recommended.

Exchange 2007 requires that you apply two rights to be able to get Exchange Impersonation working:

  • ms-Exch-EPI-Impersonation – This right is applied to the Client Access Server and grants the Service Account permission to function as an Exchange Impersonation account on that CAS.
  • ms-Exch-EPI-May-Impersonate – This right is applied on either a user-by-user basis for each of the users that require impersonation to be enabled, or it can be applied on a mailbox database.

Single CAS - The first step is to make sure we have the right setting for the Client Access Server.  To set the Impersonation permission on your Client Access Server, log on to physical Server machine, and launch the Exchange Management Shell. At the command line, type the following command (replacing CAS-Server-Name with your own CAS server name and Service-Account with the name of your own Service Account):

Add-ADPermission -Identity (Get-ExchangeServer -Identity CAS-Server-Name).DistinguishedName -User (Get-User -Identity "Service-Account").Identity -extendedRight ms-Exch-EPI-Impersonation

Add-ADPermission -Identity (Get-ExchangeServer -Identity MailServerCAS1).DistinguishedName -User (Get-User -Identity "rivacrm").Identity -extendedRight ms-Exch-EPI-Impersonation

Note that those cmdlets are typed on a single line.  The examples above have been word wrapped.

All CAS - If is also possible to set Impersonation permission on all Client Access servers in an Exchange organization.

Get-ExchangeServer | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity "User1" | select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

Get-ExchangeServer | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity "rivacrm" | select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

Impersonation for single user accounts - The next step is to set the permissions on each user for which we want to enable Exchange Impersonation. From the command line, use the Add-ADPermission cmdlet.

Add-ADPermission -Identity (Get-User -Identity "Target-User").DistinguishedName -User (Get-User -Identity "Service-Account").Identity -extendedRight ms-Exch-EPI-May-Impersonate

Add-ADPermission -Identity (Get-User -Identity "Gordon Welling").DistinguishedName -User (Get-User -Identity "rivacrm").Identity -extendedRight ms-Exch-EPI-May-Impersonate

Impersonation for all user accounts in a mailbox database - It is also possible is to set the permissions on all users in a mailbox database for which we want to enable Exchange Impersonation. Again, from the command line, use the Add-ADPermission cmdlet.  This example shows how to configure Exchange Impersonation for a user on all databases in an organization.

Get-MailboxDatabase | ForEach-Object {Add-ADPermission -Identity $_.DistinguishedName -User Service-Account -ExtendedRights ms-Exch-EPI-May-Impersonate}

Get-MailboxDatabase | ForEach-Object {Add-ADPermission -Identity $_.DistinguishedName -User rivacrm -ExtendedRights ms-Exch-EPI-May-Impersonate}

Impersonation on an Exchange server for a user - It is also possible is to set the permissions on all users on a Server for which we want to enable Exchange Impersonation. From the command line, use the Add-ADPermission cmdlet.  This example shows how to set the impersonation permissions on all Client Access servers in an Exchange organization.

Get-ExchangeServer | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity Service-Acount | select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

Get-ExchangeServer | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity rivacrm | select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

References: 

  1. "Configuring Exchange Impersonation (Exchange Web Services)" for Exchange 2007 - http://msdn.microsoft.com/en-us/library/bb204095(v=EXCHG.80).aspx
  2. "Add-ADPermission" for Exchange 2007 - http://technet.microsoft.com/en-us/library/bb124403(EXCHG.80).aspx
  3. "Get-MailboxDatabase" for Exchange 2007 - http://technet.microsoft.com/en-us/library/bb124924(EXCHG.80).aspx
  4. "Get-ExchangeServer" for Exchange 2007- http://technet.microsoft.com/en-us/library/bb123873(EXCHG.80).aspx

 

Configure Full Access Permissions - Exchange 2003

Grant Full Access Permissions to Individual Target Users:  Full access permissions can be granted to individual users using Active Directory Users & Computers MMC (with Exchange Management snap-ins). Perform this procedure on each target user to grant full access permissions to the Riva connection account.:

  1. Start Active Directory Users and Computers.
  2. On the View menu, ensure that the Advanced Features check box is selected.
  3. Double-click the target user whose mailbox you want to give permissions to.
  4. On the Exchange Advanced tab, click Mailbox Rights.
  5. Click Add, click the Riva connection user who you want to have access to this mailbox, and then click OK.

  6. Be sure that the user or group is selected in the Name box. In the Permissions list, click Allow next to Full Access, and then click OK.

Grant Full Access Permissions to all User Mailboxes Located With a Specific Mailbox Store:  Full access can be granted to all user mailboxes in a mailbox store by granting the Add Information Store, Receive-As, and Send-As permissions.  Perform this procedure on each target mailbox store to grant full access permissions to the Riva connection account.:

  1. Start the Exchange System Manager.
  2. Drill down to your server object within the appropriate Administrative Group. Expand the server object and find the required mailbox store within the appropriate Storage Group. Right-click it and choose Properties.
  3. In the Properties window go to the Security tab.
  4. Click Add, click the Riva connection user which will have access to the mailboxes, and then click OK.
  5. Be sure that the Riva connection account is selected in the Name box.
  6. In the Permissions list, click Allow next to the Administer Information Store, Receive-As, and Send-As, and then click OK all the way out.

Note: Make sure there is no Deny check box selected next to the Send As and Receive As permissions.

Grant Full Access Permissions to all User Mailboxes Located on a Specific Server:  Full access can be granted to all user mailboxes on a specific physical server (multiple mailbox stores) by granting the Add Information Store, Receive-As, and Send-As permissions.  Perform this procedure on each target mailbox server to grant mailbox full access permissions to the Riva connection account.:

  1. Start Exchange System Manager.
  2. Drill down to your server object within the appropriate Administrative Group. Right-click it and choose Properties.
  3. In the Properties window go to the Security tab.
  4. Click Add, click the Riva connection account which will have access to the mailboxes, and then click OK.
  5. Be sure that the Riva connection account is selected in the Name box.
  6. In the Permissions list, click Allow next to the Administer Information Store, Receive-As, and Send-As, and then click OK all the way out.

Note: Make sure there is no Deny checkbox selected next to the Send As and Receive As permissions.

Applies to

  • Riva On-Premise Server for Exchange 2013, 2010, 2007 and 2003
  • Riva Cloud Corporate Subscription Accounts


Also read
document Prepare for a Riva server Exchange Web Services Connection
document Prepare for a Riva server Outlook Profile MAPI Exchange Connection
document Prepare for a Riva server Direct MAPI Exchange Connection
document AppRiver: How to request "Delegate Full Access" permissions
document Rackspace: How to add "Delegate Full Access" for User Mailboxes
document IT Solutions Now: How to add "Delegate Full Access" on User Mailboxes

Also listed in
folder Riva On-Premise - CRM Sync -> Riva On-Premise Knowledge Base -> E-Mail Systems -> Mail: Exchange (EWS)
folder Riva Cloud - CRM Sync -> Get Started with Riva Cloud -> Riva Cloud Corporate Guides -> Prepare for Riva Cloud Corporate -> Prepare Exchange for Riva Cloud Corporate

Prev   Next
Prepare for a Riva server Outlook Profile MAPI Exchange...     Testing the Exchange Connection Account