Planning For Exchange System Changes: How to Reconfigure The Riva On-Premise Server

  • Updated

Several types of Exchange system changes can affect how the Riva On-Premise server needs to be reconfigured:

What Is All the Fuss About

Riva maintains transaction records for data that has been synchronized for each user. Those transaction records

  • record a relationship between the Object ID of the Exchange item (contact, appointment, task, or email) and the Object ID of the corresponding CRM item.
  • record the GlobalID of each Exchange calendar items Riva synced.
  • record the FolderID of the Exchange folder in the user's mailbox where items are stored, specifically the Contact folder, primary calendar folder, task folder, Inbox, Sent Items folder, and the entire Riva created folder structure used for manual email sync.
  • record the GUID of the user mailboxes that Riva is syncing.
  • record the date-time stamp when the item was last created, updated, or deleted and then synced by Riva

Any significant Exchange system change can impact the Riva transaction records and how Riva behaves. Because each of the above scenarios presents unique Riva challenges, the change must be well planned to ensure minimal disruption of Riva sync service for users. If Riva cannot find the applicable item or folder ID when attempting to sync, Riva normally reports an error and stops syncing the user.

Upgrading Exchange 2010 or 2007 Mailboxes to Newer Versions of Exchange

During Exchange upgrades, the Global Object IDs for Exchange items should not change when mailboxes are upgraded. If Riva is configured to use EWS connections to Exchange, Riva includes a procedure to assist with testing mailbox upgrades to ensure that Exchange Object IDs have not changed and that mailboxes can be upgraded with minimal reconfiguration of the Riva server. For detailed instructions, see Upgrade Exchange mailboxes to newer version: How to configure Riva.

Exchange 2003 Upgrade to Exchange 2007+

When a user's mailbox is properly upgraded (migrated) from Exchange 2003 to Exchange 2007+ systems, the Global Object IDs do not change. MAPI and EWS read the Global Object ID numbers by using a different format. To Riva transaction records, those different formats appear as different ID values.

Recommended best practice: Convert to using Riva EWS connections

For customers who decide to reconfigure Riva to use EWS connections, there is a method available to remap the Global Object ID values from the MAPI format to the EWS format in the Riva transaction records for each user. This is a complex procedure that requires assistance from the Riva Professional Services team.  Customers can choose to continue to use MAPI (if upgrading to Exchange 2007 or 2010) and use this procedure after mailboxes are upgraded. If mailboxes are being upgraded to Exchange 2013, this process must be scheduled into the mailbox migration project. To discuss and schedule this activity, contact the Riva Success Team.

Optional: Continue to use Riva MAPI connections (Exchange 2010 and 2007 only)

To minimize the effects of upgrading Exchange 2003 mailboxes, continue to use MAPI connections for Riva. You may need to modify Outlook profiles and Riva connection objects to connect to a newer Exchange CAS. This option is not supported for Exchange 2013, which does not support the MAPI protocol.

Optional: Reconfigure Riva sync for "Line in the Sand"

If the user mailboxes have already been migrated to Exchange 2013 or if mailboxes have been migrated by using PST files, this is the only option available. In effect, the transaction records are no longer valid. As a result, the transaction records would be removed and the Riva sync policy would be configured to minimize the duplicate sync effects for calendar items. To discuss and schedule this activity, contact the Riva Success Team.

Mailboxes Are Migrated Between Exchange Systems (Including Company Merges)

Riva supports the following user mailbox migration scenarios between Exchange systems:

  • From an on-premise Exchange system to a hosted Exchange service
  • Between hosted Exchange service providers
  • Between On-Premise Exchange systems in different locations (data centers) or different company sites
  • From a hosted Exchange service to an on-premise Exchange system

The key factor is whether an Active Directory integrated migration procedure is used to migrate user mailboxes:

  • If migrations use an AD integrated procedure that preserves the Exchange IDs (item, folder, global and mailbox GUIDs), there is a minimal effect on the Riva server. All that is usually required is reconfiguring the Exchange connection and confirming that the Riva license will continue to support the target users. To discuss the steps for this procedure, contact the Riva Success Team.

  • If migrations use a non-AD integrated procedure but use a migration wizard that supports extended Exchange schema attributes, Riva can be configured to use a PrepScan and PostScan procedure to remap Exchange IDs in the Riva transaction records. The PrepScan must be completed before mailboxes are migrated, and the PostScan procedure is run after mailboxes are migrated. This is a complex procedure that requires assistance from the Riva Professional Services team. To discuss and schedule this activity, contact the Riva Success Team.

  • If mailbox migrations will be done using PST files, Riva must be configured to use the "Line in the Sand" approach (see above). To discuss and schedule this activity, contact the Riva Success Team.

The Primary Email Domain Name Changes

Changes to the primary email domain name for the Exchange system affect

  • the Riva connection to Exchange,
  • the email addresses for the target users used for synchronization, and
  • the Riva license.

If the primary email domain name is the only change to the Exchange system, refer to the detailed instructions in Exchange primary email domain name changes: How to reconfigure Riva.

Was this article helpful?




Article is closed for comments.