How to Reconfigure Riva After Exchange Server Crash

  • Updated

Before reconfiguring the Riva server after a major Exchange system crash, there are several different circumstances to consider:

  1. Was the Exchange system restored to the same version using normal system restore procedures from system backups? 
    If the answer is yes and the EntryIDs of the individual mailbox items did not change, then there are no changes required for Riva.

  2. Was this an Exchange 2003 system that was restored but upgraded to Exchange 2007 or 2010?
    If the answer is yes, then the Riva Exchange connection and sync policy or policies need to be replaced.  See Planning for Exchange System Changes: Impact on Riva CRM Integration Server and Migrating Between Exchange Systems or Services: How to Reconfigure Riva.

  3. Was restoration of the Exchange System not possible so a new Exchange system was built or users were moved to a hosted Exchange service?
    If the answer is yes, then the Riva server needs to be reconfigured.

If your situation does not match any of the above situations, contact Riva Support for assistance.

This article covers the circumstance that an Exchange on-premise system was compromised and could not be restored, even from backups.  A decision is made to move users to a hosted Exchange service.  The steps in this article can also be used if a replacement on-premise Exchange system is built.

How Riva Syncs Exchange Data

CRMs and Email systems save items (like messages, appointments, and emails) into databases as unique records.  Each of those records is assigned a unique ID that is normally a long character string that is not visible to users.  Those IDs are referred to by different titles (GlobalID, itemID, crmID, folderID, etc).  Riva uses those IDs to locate items that need to be created, modified, or deleted.

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 item 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; and
  • record the date-time stamp when the item was last created/updated/deleted and synced by Riva.

Any significant Exchange system change can impact the Riva transaction records and how Riva will behave.  Each of the above scenarios presents unique Riva challenges that should be planned to ensure minimal disruption of the 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.

Restoration of Riva Sync

The key is to determine if the unique Exchange IDs were modified when user mailboxes were restored:

  • If the unique Exchange IDs did not change:  Riva can be started, and data sync should resume from the last successful sync poll for each user.

  • If the unique Exchange IDs changed:  Riva needs to be reconfigured with a "Line in the Sand" procedure.  Contact the Riva Success Team to schedule an appointment with a member of the Riva Professional Services Team.

  • If effects to the unique Exchange IDs cannot be determined:  Riva can be configured to run a "DryRun Mode" sync poll that will confirm if Riva experiences data sync issues and if assistance from the Riva Success team is required.

Was this article helpful?

/