Import a Dynamics Organisation v8 to a v9 Installation

You may also like...

5 Responses

  1. rik Helsen says:

    I am just leaving this here for others. According to my microsoft support case, they no longer support direct upgrades from CRM 8.2.x to 9.0.10 and higher .

    I’ve tested with with

    8.2.3 to 9.0.10
    8.2.3 to 9.0.11
    8.2.13.21 to 9.0.11
    without succes. All importing failes (tried with multiple organisations)

    All imports of databases fail with the error “‘Attribute’ metadata entity doesn’t contain metadata attribute with Name = ‘autonumberformat'”

    Any/all workarounds are welcome, as we are not getting any solutions from microsoft at this time.

    Their last update:

    “As we discussed in order to do the upgrade from 8.2.3 you will have to upgrade to version 9.0.9 and then to version 9.0.10.

    This is due to difference in the code that is applied after version 9.0.9.

    Unfortunately there is no official documentation on that because Microsoft is recommending its customers to update their systems regularly with the newest version available when it comes out.”

  2. Stephen W. says:

    Thanks for this, very helpful solved my problem right away without DB restore! @rik I always import before updating CRM so going from 8.2.2 to 9.0.2 went without problem. Thanks for the heads up!

  3. James Horsley says:

    Interesting info Rik H – I have been having that issue and thought I might be able to add the attribute myself to the [MetadataSchema].[Attribute] table in the org db – but DB’s already at new 9.0.8.9 level didn’t have the attribute. The upgrade seems to go through a series of actual upgrades for cummulative updates (look at what it does to table [dbo].[DatabaseUpdateTransition]) for info) – so I think the attribute was one that was added thenlater removed. I am looking at an upgrade path to bring in a live database (on a long path that was CRM 2011 now live at CRM 2013) and this really helps – I will need to re-install D365 and leave at Update 3 before bringing in the CRM 2013 db that will have gone through CRM 2015 and CRM 2016. Your info is very helpful in pointing me to a path that should (hopefully) work.

  4. James Horsley says:

    Because this is a valuable resource for people struggling with on-premise upgrades (you almost feel Microsoft are trying to make the on-premise option hard!) I have some other info people may find useful. Much like the “Marketing Solution Error” in the post (which did help me diagnose this).

    If you try to “import” an organisation database into D365v9 (at least true at v9.0.8.9) you will get solution path upgrde errors for pretty much all the solutions that you find under “C:\Program Files\Dynamics 365\Setup\Serviceability\Latest\Actions_Org\Install\Packages\CRMApps\PkgCache_9_0_0008_0009”. It appears this is because when an oganisation db is imported it tries to upgraade the database to v9.0.8.9 even though it is already at v9.0.8.9. For info you can see the version of an org db using SELECT * FROM BuildVersion and see it’s upgrade history in SELECT * FROM DatabaseUpdateTransition.

    Anyway – the result is the update code tries to apply patches to all the solutions provided by Microsoft – and each gets an error a bit like:

    01:37:41| Info| Failed to install package msdynce_MarketingService on attempt 1.
    01:37:41| Info| Failed to install msdynce_MarketingServiceException: Microsoft.Crm.PackageDeployment.PackageDeployerException: Package msdynce_MarketingService failed to install on attempt 1.
    System.AggregateException: One or more errors occurred. —> Microsoft.Crm.MultiTenantPackageDeployment.PackageDeployerImportException: PackageDeployerWrapper: Import Failed status encountered. Details: Failed to load solution Patch For Marketing Service, version: 9.0.4.3603. See the log file.
    at Microsoft.Crm.MultiTenantPackageDeployment.PdExecutor.Process(PackageDeploymentInputArgs input, JobOutput`1 output, CancellationToken ct)
    at System.Threading.Tasks.Task.Execute()
    — End of inner exception stack trace —
    —> (Inner Exception #0) Microsoft.Crm.MultiTenantPackageDeployment.PackageDeployerImportException: PackageDeployerWrapper: Import Failed status encountered. Details: Failed to load solution Patch For Marketing Service, version: 9.0.4.3603. See the log file.
    at Microsoft.Crm.MultiTenantPackageDeployment.PdExecutor.Process(PackageDeploymentInputArgs input, JobOutput`1 output, CancellationToken ct)
    at System.Threading.Tasks.Task.Execute()<—

    a bit further in the log you will see what it was trying to apply – it always seems to fail on the "Patch" solutions – so you get something like:

    [11/03/2020 01:37:38]: Reading the solutions. Please wait.
    [11/03/2020 01:37:38]: Found the solution: Marketing Service, version: 9.0.4.29 (Managed)
    [11/03/2020 01:37:38]: Found the solution: Patch For Marketing Service, version: 9.0.4.3603 (Managed)
    [11/03/2020 01:37:38]: PackageDeployerWrapper: PackageDeployer successfully finished configuration parsing.
    [11/03/2020 01:37:38]: PackageDeployerWrapper: Starting PackageDeployer import operation.
    [11/03/2020 01:37:38]: PackageDeployerWrapper: Waiting for PackageDeployer completion…
    [11/03/2020 01:37:41]: PackageDeployerWrapper: PackageDeployer reported status [Failed] during import: Failed to load solution Patch For Marketing Service, version: 9.0.4.3603. See the log file.

    and further down will see:

    Exception details:
    ErrorCode: 0x80048539
    Message: Cannot change base solution for patch.

    What is basically happening is the patch is unable to apply because the version is already the same. Rather than (properly) just skipping because it is there it baulks. So the "comment out" in the ImportConfig.xml as per the blog post is the solution to get it past – but it is a slow process going one by one – so you can use:

    SELECT * FROM Solution WHERE UniqueName LIKE '%Patch%'

    To point you to the solutions that need the xml tweak – and then find the appropriate one and comment out the patch – you can double check version numbers in the query results to make sure you really do have the patch already if you want too.

  5. James Horsley says:

    Sorry for so many comments but another thing of interest in the upgrade path is that in the DatabaseUpdateTransition table for a “brand new” organisation created with install of D365 v9 (using the Update 0.2 installer that fixes some of the earlier install issues – and seems to be the most up to date full installer available) the database looks like it has gone through these transitions:
    7.0.0.3027 -> 9.0.0.770 (transition date 29 July 2017 – so this was applied to the temaplte org DB D365 insatlled before it got here)
    9.0.0.770 -> 9.0.2.3034
    9.0.2.3034 -> 9.0.2.3034
    Above two rows were dated same time as the install so D365 actually does not ship with a template org DB at the same level as the installer but upgrades it on create.
    Finally because I had then updated to Update 0.8 I also had a later row for
    9.0.2.3034 -> 9.0.8.9

    What is interesting about this is upgrade docs (for what they are worth) say you need to go from CRM2013->CRM2015 apply latest path then CRM2016 the CRM2016 SP1 (aka v8.2) then on to v9. But those version numbers seem to indicate that it actually went:
    CRM2015 RTM -> D365 v9 RTM (I think – can’t find 9.0.0.770 number listed anywhere)
    And then directly to the current version (Update 0.2 here)

    I am going to experiment with this upgrade path because it may be that in fact CRM2016 can be skipped over if coming from CRM2015 or below. I am making the assumption here that if you can follow the same path as Microsoft’s template org db followed then the upgrades will work.

Leave a Reply

%d bloggers like this: