Defer Database Updates Installing CRM 2011 Update Rollups

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)
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!

Sean McNellis

Premier Field Engineer

Comments (10)

  1. wndrbear says:

    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?

  2. wndrbear –

    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.



  3. says:

    I definitely need some help with this and I am reaching out to you for some guidance or help.  I have Microsoft online and a client install EMR program and I have in the past had a Microsoft partner build the updating tool and the custom tables, all the JavaScript and all these pieces and parts that I'm not sure what to do with as I am a physician not a computer coder.  Unfortunately I am no longer in touch with that partner and we got a new server so none of the information from the local database updates into CRM or from the CRM to the local database.  I would really appreciate some help as it's been over nine months since I've been able to have this update occur and the information is becoming worthless due to this serape ration and my market reps are struggling to get info efficiently.

  4. Ray says:

    I keep receiving the error "Set-CrmAdvancedSetting : The underlying connection was closed: An unexpected error occurred on a send." when I run the script.  I can't figure out why and nothing is logged anywhere. Any ideas?

  5. AZEagle says:

    Hi Sean,

    Running the get command returns the following error:

    Get-CrmAdvancedSetting : The remote server returned an error: (404) Not Found.

    At line:1 char:23

    + get-CrmAdvancedSetting <<<<  -ConfigurationEntityName "Deployment" -Setting "AutomaticallyInstallDatabaseUpdates"

       + CategoryInfo          : NotSpecified: (:) [Get-CrmAdvancedSetting], WebException

       + FullyQualifiedErrorId : System.Net.WebException,Microsoft.Crm.PowerShell.GetCrmAdvancedSetting

    Is it possible to not have this attribute?


    Gene Underwood

  6. AZEagle says:

    Hi Sean,

    Update…. the record for AutomaticallyInstallDatabaseUpdates does exist in the DeploymnentProperties table, so it must be something else going on with this error (I'll keep digging at it…)


  7. @Gene & @Ray, the 404 / Connection closed errors are from the CRM Powershell components reporting the webserver address entry it uses (which is set in deployment manager) is incorrect and reporting a 404 – additionally check the webserver URL in the registry under HKLMSoftwareMicrosoftMSCRM.  

    Also, be sure you're running the deployment services worker process under a user identity and not Network Service or you will also have issues using the powershell components.



  8. Gene says:

    Hi Sean,

    Thanks for the quick response!  My deployment is  running on multiple servers with separate roles and the servers are also NLB per role. The deployment server is configured in IIS to deny access all URLs sequences to MSCRMServices and XRMServices. Do you know what CRM services the PowerShell addin uses?



  9. Showkat Mir says:

    HI Sean, First of all i would thank you for this post, i have a query whichi wanted to clarify before i go ahead and implement, here is the scenario in below points

    1, we have CRM 2011 with RU8 farm

    2. we have tow organisations e.g ORGA and ORGB

    3. we are planning to build new CRM servers, Reporting extention and email router servers farm with RU18  and migrate ORGB to this farm.

    4. ORGA will be continuing with same RU8

    5. We want use the same SQL database intance for both old and new farm.

    Since we will be using same database instance we are concerned if it will work or is it a feasable approach, because both ORGS will be sharing the same schema which is  MSCRM_CONFIG databsse as both ORGS will be sharing single database instace.

    Request you please guide us on this andhow to proceed it will be highly appreciated. Thank you again


    Showkat Mir

    1. kc says:

      Microsoft has two pieces to the app, the web UI and the powershell mechanism. During the CRM2011 UR12, they fixed the ssl offloading bug for the web UI, however, while I’ve been fighting with MS to fix the same bug w/in the PS dll’s. Unfortunately, now we are on CRM2016, and the SSL Offloading is still broken.

      If you want to have PS work in a split node, claims based/IFD deployment running a NLB with SSL Offloading, you will not be able to. If you want to make it work, create one deployment server with re-ssl’izing on that physical node. Then you can connect to the unqualified domain name of https://host/ and the underlying connection will work.

      Basically, if you are using ssl offloading, the service endpoints will come back as HTTP on the calll, however, the deployment admin claims config will have HTTPS, and the protocol mismatch is forcing the connection to fail.

Skip to main content