Calling all CRM admins – here’s a tip you’ll want to bookmark for your next round of update rollups. Dynamics CRM 2011 Update Rollup executable packages automatically process and update the organization database updates during the installation. If your deployment has several large tenants or just one very large tenant you may prefer to first install the “binary” updates and worry about applying the database updates after the binary installation of the rollup (on an organization by organization basis). This would put the control and timing of when to update organizations from a SQL perspective in the hands of the administrator. Additionally, if your environment is highly operationalized, this feature allows you to separate the installation of the binary updates (DLL’s, executables, etc) from the installation of the database components (updated stored proc’s, udf’s, schema updates, out of box index changes, etc). Both updates still need to be completed as part of the update but you can now separately manage and execute those operations (likewise this allows you to retry database updates if they timeout or do not complete without jeopardizing the installation binary updates).
To accommodate this a new deployment property was added in Dynamics CRM 2011, I’ve been unable to narrow down the exact build in which this feature was applied but I’ve successfully tested it back to Update Rollup 6 (which should cover most). Below you’ll find the instructions for how to enable this helpful feature.
Values for the AutomaticallyInstallDatabaseUpdates Deployment setting: True (default): during the update rollup execution the files will be upgraded on the server and additionally each DB will be updated The update rollup will upgrade the CRM files, the DB updates are staged, then each org DB is updated to the update rollup version you’re installing, once completed you will see a success / finish screen as part of the installation.
False: during the update rollup execution the CRM files are upgraded, the DB updates are staged, once completed you will see a success / finish screen as part of the installation. The DB updates now must be manually applied to each organization, which is done by opening deployment manager, finding the organization you wish to update, right-clicking the organization, then selecting “update”. When you select update all the db updates that would normally be executed in the update rollup are now applied – this could include updates of UDF’s, Stored Procs, underlying schema changes, index updates, etc. This event of applying updates should be considered maintenance as the organization may behave as if it’s “offline” and users updating data could potentially block the update installation.
So, now that we have that out of the way here’s all you need to know on how to check this value and how to update it, if you wish to change it.
PowerShell Script to get the current value (default is true):
Add-PSSnapin Microsoft.Crm.PowerShell (get-CrmAdvancedSetting -ConfigurationEntityName "Deployment" -Setting "AutomaticallyInstallDatabaseUpdates").Attributes
PowerShell Script to postpone DB updates on installation*
Add-PSSnapin Microsoft.Crm.PowerShell$setting= New-Object "Microsoft.Xrm.Sdk.Deployment.ConfigurationEntity"$setting.LogicalName = "Deployment"$setting.Attributes = New-Object "Microsoft.Xrm.Sdk.Deployment.AttributeCollection"$keypair = New-Object "System.Collections.Generic.KeyValuePair[String, Object]" ("AutomaticallyInstallDatabaseUpdates", $false)$setting.Attributes.Add($keypair)Set-CrmAdvancedSetting -Entity $setting
*NOTE: When you defer updates you will have to update the organizations using Deployment Manager.
I hope you find this simple setting change as helpful as our team does, again while it doesn’t change the fact certain updates must be applied as part of update rollups this allows for the separation of the app and the DB updates which can also help make troubleshooting easier. In the worse case scenarios org DB’s could be left at a lower patch level for short periods of time if you need to wait for another maintenance window or stage org DB updates over a succession of nights in the case where you have numerous CRM organizations.
Feel free to reach out with questions, if you would like someone from our team to host a deep dive on this, facilitate a chalk talk about updates in general, or come onsite and work side-by-side with you on this or other topics please reach out to your TAM and ask them to put in a request – we’d be happy to help!
Premier Field Engineer
Just to clarify:
We could apply our updates to our dev / test databases, work out any kinks with custom forms, scripts, 3rd party solutions etc while the users using the production database that wasn't upgraded will see no functional difference. Correct?
Sorry I missed your comment on this, I don't quite follow your question. The purpose of deferring database updates is to segment your update rollup installations and better manage the installation/update process. The binary update will update all the dll's for CRM without touching the DB schema. Then after the binary portion succeeds, you can use a DBA account to follow up the installation and apply the database schema updates. This is dividing the steps up so you can better operationalize the process - additionally if your DB updates take a long time this allows you to run the patches on all your CRM nodes then come back and do the db updates after the fact.