ReadyXRM

For some reason solution imports have not been my friend the last few months.

Usually when a solution doesn’t import, 99% of the time it comes down to dependency issues or a corrupt solution file.  For on-premise deployments, if the log file doesn’t provide good information, setting up server side traces or SQL profiler traces usually gives you the info you need.

However, despite these approaches, sometimes a bit more digging and creativity are required to resolve the issue (or at least find a workaround).

Last week I was attempting to import an unmanaged solution and got an error while importing.  Looking at the import log I see the following error:

Cannot add a Root Component caa19d4f-4eed-e611-8109-480fcff4b5b1 of type 60 because it is not in the target system.

In all cases, Google is your friend and found some folks with similar issues and a few helpful blog posts.

Similar issues indicated to resolve the issue by searching the customization file for the offending component and removing it.  I wasn’t too keen on that since it only fixes the immediate issue and its something I don’t want to do each time I export and import a solution.

What was surprising is that when I searched the customization file, I could not even locate that component!

From this posting I learned that component type “60” is a system form.  I thought it would be good to identify what form that was.  In another community thread, a poster said they were able to locate the offending form by replacing the GUID in the form editor URL.

The resulting URL would be something like this:

https://<<orgname>>.crm3.dynamics.com/main.aspx?appSolutionId=%7bFD140AAF-4DF4-11DD-BD17-0019B9312238%7d&etc=1&extraqs=formtype%3dmain%26formId%3dcaa19d4f-4eed-e611-8109-480fcff4b5b1%26action%3d-1&pagetype=formeditor#696777448

So I opened the form editor, copied the URL, and then modified it to show my form with the GUID of “caa19d4f-4eed-e611-8109-480fcff4b5b1″

I was able to view the form, but I couldn’t see what entity the form belonged to and it also looked a bit strange.  Further inspection showed that it was an “Interactive Service Hub” form, but I still needed to locate the entity.

Since this is Dynamics 365 Online, I can’t query the database directly and also System Forms are not easily accessible from Advanced Find.

Once again the XrmToolBox to the rescue!

I used FetchXml Builder, a XrmToolBox utility created by fellow MVP Jonas Rapp.

I setup a query on system forms to find my offending form component.

I was able to find the entity, and the form type (10) which (I believe) is an Interactive Service Hub form.

However, when I looked at the customization in source Dynamics 365 system, the form was not listed!  Whaaaaat?

And the entity was not enabled for Interactive experience!

I spoke with the business analyst that set up the entity.  She had mentioned that she had at one time enabled the entity for Interactive Service Hub, but after testing and evaluating, decided to shut it off.

It would appear that the process did not remove the Interactive Service Hub forms.

I re-enabled the entity for interactive experience.

Now the offending forms appeared (same GUID!)

So I published and re-exported the solution and this time imported just fine.

So the workaround is to enable the entity for Interactive Service Hub.  A better solution would be to only enable the entity of Interactive Service Hub if absolutely required.

I tried to recreate the issue on a clean test system and I was not able to (disabling interactive experience) and exporting/imported worked.  So this appears to be an intermittent issue but hopefully this blog posting will help someone down the road (likely me).

The other solution import issue I don’t have a permanent fix for (yet) but I do have a workaround.  That will be the topic of my next post.

Nick Doelman is a Microsoft Business Solutions MVP and despite working with Dynamics CRM since version 1.0, still runs into brand new issues which sometimes drives him nuts.