When working with CRM extensively across multiple environments, you do start to get into a fairly regular rhythm when it comes to completing key tasks again…and again…and again. One of these tasks is the process of rolling out a Solution update. To briefly summarise, this is where you export an updated version of your solution from your development environment and then import the solution file on top of a previous version in a different instance. CRM will then go through the solution import file, detect and then apply any changes which have been made. The original solution will be overwritten as part of this and you will be informed at the end of the import on any warnings or errors that were encountered during import. Warnings will generally not cause the solution import to fail, whereas errors will stop the import completely.

Like with anything, Solution updates can sometimes fall-over for a whole host of different reasons. They can fail altogether, or sometimes just hang and become unresponsive. If you are running On-Premise CRM, then you can interrogate the SQL database on the instance to see how your solution import is (or is not) progressing. Ben Hosking (whose blog is mandatory reading for anyone who works closely with CRM) has written a really useful post which contains the SQL query you need to use on your organization database in order to identify any problematic job imports.  The good thing with this approach is, if the import has errored, the Data column contains the raw XML file that you are able to download via the CRM GUI using the ‘Download Log File’ button below when a solution import proceeds as you would expect normally:

You can therefore very quickly drill-down to see if the solution import has failed due to a customisation issue. A common reason for failure may be due to duplicate logical name(s) for attributes, relationships etc.

If you are using CRM Online, then the first assumption (which I admittedly made) may be that there is no way in which to access the above information. Fortunately, there is an entity called ‘importjob’ that is made available for access via FetchXML

So, for example, to return all solution imports that have gone through your CRM, you would use the following FetchXML query:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="importjob" >
    <attribute name="completedon" />
    <attribute name="solutionname" />
    <attribute name="progress" />
    <attribute name="startedon" />
    <attribute name="completedon" />
    <attribute name="createdby" />
    <attribute name="data" />
    <attribute name="organizationid" />
    <attribute name="createdon" />
  </entity>
</fetch>

If you wanted to just return solution imports that are either stuck at 0% or have not yet successfully completed:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false" >
  <entity name="importjob" >
    <attribute name="completedon" />
    <attribute name="solutionname" />
    <attribute name="progress" />
    <attribute name="startedon" />
    <attribute name="completedon" />
    <attribute name="createdby" />
    <attribute name="data" />
    <attribute name="organizationid" />
    <attribute name="createdon" />
    <filter type="or" >
      <condition attribute="progress" operator="eq" value="0" />
      <condition attribute="completedon" operator="null" />
    </filter>
  </entity>
</fetch>

Sometimes your import may fail due to a problem with CRM itself. In these instances, the best course of action depends, once again, on your CRM deployment:

• For On-Premise users, then the old IT adage applies here: try restarting the CRM and SQL Database Server instance. You may first need to locate the active process on SQL Management Studio that is performing the solution import and kill the process first. A database instance reset should automatically cancel this and prevent it from running again on instance startup, but its better to be safe than sorry.
• The only recourse for Online users is to log a support request with Microsoft via the Office 365 portal. It is best to provide as much evidence as possible up-front and be advised that the Microsoft support engineer may ask you to demonstrate the problem again, which might prove difficult to perform during normal working hours if the problem is happening on your Production instance.

I was glad to discover that there is half way method of being able to interrogate possible platform issues yourself on CRM Online, but this particular example illustrates one of the drawbacks of CRM Online: little or no direct access to the organization database and/or instance level services. I would hope that in time Microsoft may develop the platform further in order to start exposing these elements to organization administrators. I would imagine that the vast majority of support queries that go through on the Office 365 portal would relate to requests that could be safely performed by CRM Administrators or Partners, leading to a cost and efficiency saving for Microsoft should this be implemented.