Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Today's post was written by Neil Erickson, Development Principal at Sonoma Partners.
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.
Business Applications communities