Tip #943: Upgrading development environment to Dynamics 365 On-premises

Today’s contribution is “an old school on-prem tip” from Brian Illand.

Despite the marketing hype around Dynamics 365 being a whole new product, remember that it is a ‘minor’ upgrade from Dynamics 2016 to Dynamics 365 On-Premise. Dynamics 2016 is v8.0/8.1 and Dynamics 365 is Version 8.2. So, ‘theoretically’, there is a lower than usual risk of things breaking than when you are upgrading between minor versions. Additionally, you shouldn’t need to upgrade any hardware or other dependencies like SQL. Consider the advantages that you could get from Dynamics 365 On-Premise features such as apps and editable grids for this relatively simple installer. It’s a no-brainer.

In practice, a slight hiccup however. Today, we decided to bite the bullet and see how this theory played out, upgrading a relatively new CRM 2016 environment to Dynamics 365. The first step was to test it on a Development environment. When we ran the installer, it took over THREE HOURS to complete (much of the time it was stuck at ‘Microsoft.Crm.UpdateWrapper.HotfixMspInstaller – File: C:\Config.Msi\579f832e.rbf’ in case you’re interested). This is something we attributed to our less than optimal Dev Environment and Dev SQL Server Specs.

So what’s the tip? Here’s 3 :

  1. If the installer looks like it has hung when upgrading don’t panic – check the logs at C:\Users\AppData\Roaming\Microsoft\MSCRM\Logs. If they are getting updated regularly, don’t worry.
  2. You can also check the upgrade status by looking in the UpgradeActionTracker on each database – i.e.
    SELECT * from UpgradeActionTracker order by createdonutc desc
  3. When specifying hardware, to keep costs down, people often specify a beefy production environment, perhaps a broadly equivalent pre-production environment, a slightly less equivalent test environment and a development box that runs like a dog. Think twice about cheap dev kit. This is probably where you will be doing the bulk of your work, publishing and republishing solutions, data loads and such like. If it’s an Azure VM, spec it high initially and scale back when you are not using it. If it’s on-premise, don’t use that server that was destined for the bin, it will cost you more in the long run in waiting around.

Leave a Reply

Your email address will not be published. Required fields are marked *