Today's post was written by Neil Erickson, Development Principal at Sonoma Partners.
As a firm that specializes in CRM consulting, we are proponents of using the technology we sell in our own processes.
When upgrading to Dynamics CRM 2015 we went through the effort of moving to new hardware for both the CRM servers and SQL server. We decided that it was time to implement SQL AlwaysOn for redundancy. A year later when it was time to upgrade one of our systems to CRM 2016, we elected for an in-place upgrade since both Windows and SQL remained up to date.
The upgrade process was going along without issue until the following error occurred:
System.Exception: Action Microsoft.Crm.Tools.Admin.SetReadCommittedSnapshotIsolation failed. ---> System.Data.SqlClient.SqlException: The operation cannot be performed on database "Grapevine_MSCRM" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
Upon reading the exception, my first thought was that we would need to completely undo the availability group and then rebuild it once the upgrade was complete. Due to the size of the database, I expected that this could add an additional two hours to the upgrade process.
Luckily, this process was not as lengthy as I imagined. It was possible to go in and remove it from the Availability Group and have the upgrade process retry the action.
This leaves the database running on what was the Primary Replica, and in the restoring state on the secondary.
Once the upgrade finishes you can add the database back to the availability group. Because the secondary is still in restoring mode, it will simply catch up the changes. This takes considerably less time than a full backup and restore cycle, and it can be accomplished by selecting “Join Only” for your initial data synchronization preference.