Prepare the Exchange Mailbox for the Riva Connection User

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":

• Basic Requirements for the Riva Connection User to Exchange
• How Riva CRM Integration connects to different versions of Exchange
• Riva Impersonation Methods
• Prepare the Exchange Riva "Connection Mailbox"
  • Prepare for Exchange On-Premise
  • Prepare for Office 365 Exchange
    
  • Prepare for Office 365 Exchange 2013
  • Prepare for Hosted Exchange
    • Rackspace
    • IT Solutions Now
    • AppRiver

Procedures in this article apply to:

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

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 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 has changes. If EWS is not available, the Exchange 2003 Extended MAPI connection type is supported.

Exchange 2010 / Office 365

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+ / BPOS

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 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.

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"

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:

• Exchange 2013 - Configure Delegate Full Access Permissions (Using Exchange Web Console) - available soon, or

• Exchange 2010 and 2007 - Configure Delegate Full Access Permissions (Using Exchange Management Console), or

• Exchange 2013, 2010 and 2007 - Configure Delegate Full Access Permissions (Using Exchange Management Shell), or

• Exchange 2013 & 2010 - Configure Exchange Impersonation (Using Exchange Managment Shell), or

• Exchange 2007 - Configure Exchange Impersonation (Using Exchange Managment Shell), or

• Exchange 2003 - Configure Full Access Permissions (Using Microsoft Management Console).

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.

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 "Trusted User" -AccessRights FullAccess

Add-MailboxPermission -Identity “gwelling” -User “DEV03-EX07\rivacrm” -AccessRights FullAccess

To confirm that what permissions are assigned to a mailbox:

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

Get-MailboxPermission -Identity “gwelling” | 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

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

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.

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. "Add-ADPermission" - http://technet.microsoft.com/en-us/library/bb124403(EXCHG.80).aspx
5. "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).

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

Configure Exchange Impersonation for specific users or groups of users

ManagementScope - 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 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

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.

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.

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.

Prepare the Exchange Connection Account for Riva for Office 365 - Exchange Online

Microsoft Office 365 offers a unique set of management considerations.  The use of Delegated Access or Exchange Impersonation depends on the version of Office 365

Office 365 Small Business or Professional - does not support Exchange Impersonation assignment through Windows Powershell.  There are two options:

• For Exchange Online 2013, admin users now have the ability to Set Delegate Access permissions (Full Access).  Access the user list and then double click a specific target user that Riva will sync.  You can then select Delegate Access and assign Full Access permission to the Riva connection user, OR

• For Exchange Online 2010/2013 - Assign Delegated Access using Powershell - use the steps described in "Connect Windows Powershell to the Service" - http://help.outlook.com/en-us/140/cc952755.aspx and use the Add-MailboxPermission cmdlet to assign Delegated Access, OR

• For Exchange Online 2010, get each user to assign Delegated Access to the Riva connection account user from their respective Windows Outlook 2010 client.  Refer to http://office.microsoft.com/en-us/outlook-help/allow-someone-else-to-manage-your-mail-and-calendar-HA010075081.aspx.  When configuring the permissions, ensure that the following are assigned:
  
  

Office 365 Enterprise - supports using Windows Powershell to assign Exchange Impersonation using RBAC steps described previously in Configure Exchange Impersonation Using Exchange Management Shell - Exchange 2010. Some customers have reported difficulties with RBAC roles and Exchange Impersonation.  Office 365 Enterprise also supports assigning Delegated Access using Powershell.

References:

1. "Connect Windows Powershell to the Service" - http://help.outlook.com/en-us/140/cc952755.aspx
2. "Allow someone else to manage your mail and calendar" - http://office.microsoft.com/en-us/outlook-help/allow-someone-else-to-manage-your-mail-and-calendar-HA010075081.aspx
3. "Reference to Available PowerShell Cmdlets in Exchange Online" - http://help.outlook.com/en-us/140/dd575549.aspx
4. "Built-in RBAC Roles for Exchange Online" - http://help.outlook.com/en-us/140/dd207272.aspx
5. Office 365 Technical Support - call 866-865-9408.

Assign Delegate Access (Full Access Permissions) - Office 365 Refresh (Exchange 2013)

You can use the following steps to assign Delegate Access Full Access permissions to the Riva connection user mailbox.

1. Log into Office 365 as an Admin user.  You should be working in a blue & white minimalist theme.

2. From the menu bar, click on the logged in user name and select "Exchange".

3. In the left column navigation pane, select "recipients".

4. In the list of mailboxes, select the "target" user to grant delegate access for and click the pencil icon at the top of the mailbox list (or double-click the mailbox user).
   
   

5. In the "User mailbox" window, select "mailbox delegation".

6. In the "Full Access" section, click "+" above "DISPLAY NAME".

7. In the "Select Full Access" window, select the mailbox to grant access to (the Riva service connection mailbox), click the "add ->" button and the "ok" button.
   
   

8. In the "User mailbox" window, click the "Save" button.

9. Repeats steps 4 to 8 for each target user that Riva will sync data for.

Prepare the Riva Connection Account for Hosted Exchange Services

Commercial hosted Exchange services provide an management panel through which the company admin account can manage mailbox permissions.  Refer to the following KB articles that explain the procedures.  If your service is not listed, follow the similar procedures for your hosted Exchange service:

• Rackspace
• IT Solutions Now
• AppRiver

Applies to

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