The curse of the deleted workflows

When you’re following a development process including at least a development and production environment, then you might end up in a scenario where you have deleted a workflow from the production environment and then want to import a solution containing the very same workflow.

In some scenario’s you will find that this results in the error message:


0x80041103: Workflow' entity doesn't contain attribute with Name = 'Workflowid'.

Though the error message isn’t valid at all, the workflow entity definitely has the attribute Workflowid, there is an explanation for the error.

What happens when you enable a workflow, is that a copy of the workflow is created in the database, called a ‘Workflow activation’. It is this copy of the workflow that is being used when a workflow is executed. This is useful for when the workflow is being changed, the current workflows will then continue running against this copy of the workflow. Michael B. Scott describes this pretty well in a response on this forum: https://social.microsoft.com/Forums/en-US/b717ae4a-1e5d-48d2-880e-c961ff9a776d/crm-2011-workflows-being-duplicated?forum=crm

He also describes that it takes a while (max 24 hours), before the workflow activation records get deleted when they’re not used anymore. And it is exactly the existence of this workflow activation that causes the error message. This means that in a happy scenario the error should magically disappear within 24 hours.

But, sometime it doesn’t.

In that case there are still references to the workflow activation record. You can find these when searching for system jobs carrying the same name as the name of the workflow. Most likely these are the instances of the workflow that didn’t end with a success state, such as cancelled or failed workflow executions. After deleting these, then another 24 hours later, the workflow activation record should get removed.

But, how to delete these? You are lucky if this works through the CRM UI, but this can throw error messages as well as the related workflow doesn't exist anymore. In that case a bulk delete can give you the answer. Note: I would always strongly favor the CRM UI approach as this handles as much cleaning as possible for you.

But if that doesnt'work and you do have access to the database, then I have some SQL queries that can help identify the records or even clean them server-side.


-- select all records having a non existing parent (most likely only workflow activation records)
Select name, workflowid, parentworkflowid, * from Workflowbase w
where parentworkflowid not in (select workflowid from Workflowbase)
order by 1

-- select all system jobs related to the selected workflow activation records
select asyncoperationid, WorkflowActivationId, WorkflowActivationIdName, CorrelationId, statecode, CreatedOn, completedon, regardingobjectid, regardingobjectidname, regardingobjecttypecode
from AsyncOperation
where WorkflowActivationId IN
       (Select workflowid from Workflow w
       where parentworkflowid not in (select workflowid from Workflow))
order by workflowactivationid, CompletedOn

-- find out how many workflowlog records (basically steps in a workflow) are related to the workflow instances
select count(*) from workflowlog
where AsyncOperationId IN
       (select asyncoperationid from AsyncOperation
       where WorkflowActivationId IN
             (Select workflowid from Workflow w
             where parentworkflowid not in (select workflowid from Workflow)
             )
       )

Enjoy



Unlimited redirects or popups to https://www.crmdynint.com

Hi guys,

We've recently seen a situation where users of Dynamics365 (a.k.a. CRM Online) are getting popups or redirects to an url such as:

 
With the support of Microsoft support we have been able to solve this issue by adding the following sites to the trusted sites of Internet Explorer:
 
And to remove the temporary files from Internet Explorer as well as the folder "%temp%".
 
Keith Cockerham has identified the guided learning path as the cause of this issue. Turning off this feature using another browser is another workaround for this issue, but keep in mind that obviously you cannot use the guided learning path feature in this scenario.



A managed solution cannot overwrite the AttributeMap component with Id=[guid] which has an unmanaged base instance

Facing this message?

A managed solution cannot overwrite the AttributeMap component with Id=b648bf03-102f-e611-80d3-e1543fac8121 which has an unmanaged base instance. The most likely scenario for this error is that an unmanaged solution has installed a new unmanaged AttributeMap component on the target system, and now a managed solution from the same publisher is trying to install that same AttributeMap component as managed. This will cause an invalid layering of solutions on the target system and is not allowed.

Then you can quickly find the problematic mapping using the following query:

select SourceEntityName, SourceAttributeName, TargetEntityName, TargetAttributeName from AttributeMap am
left outer join entitymap em on em.entitymapid = am.EntityMapId
where am.AttributeMapId='b648bf03-102f-e611-80d3-e1543fac8121'

Just remove the mapping from the target system and reimport the solution and you're ready to go.



Should be exactly 1 MessageProcessingStep registered for workflow

Having duplicate processes (usually business rules) can cause issues during import of a solution containing the same process. One of the error messages is:

Should be exactly 1 MessageProcessingStep registered for workflow

If you face this situation, then it's easiest to identify the duplicate processes by using the advanced find. Search for the processes and remove the default filter. Then add "Category equals Business Rule" and view the results ordered by name. If you see any duplicate, then you can remove the oldest Business Rule(s).

If you've got too many processes to visually identify the duplicates, then you can always export to Excel and use the duplicate features there.

In some cases the duplicates exist due to the holding solution approach. In this case, removing the Business Rules will eventually give you other error messages such as:

- Crm Exception: Message: processtrigger With Id = 3922b595-8637-e511-80d3-b13ac3e6ed07 Does Not Exist, ErrorCode: -2147220969
- 0x80040203 Could not retrieve parent object id for label with id 1f26a158-cf40-e511-80d6-f0b8a7508109 and label type code 19
- Cannot find a top solution for ProcessTrigger:3922b595-8637-e511-80d3-b13ac3e6ed07

If this is the case, then the next post will help:
http://ronaldlemmen.blogspot.nl/2015/10/processtrigger-error-messages-and.html



Generic errors while importing solution in Dynamics CRM 2016

While importing an update for a solution or a new solution that is building on top of another solution, then you might face generic error messages. This blog post provides a possible solution for the scenario when the CRM solution import dialog mentions a "Generic SQL error" while downloading the log file serves you the message "0x80044150: Object reference not set to an instance of an object.".

I have found that for some reason it is possible that the Description attribute of an entity is not included in the customizations file when exporting from Dynamics CRM 2015. If this is the case, then the system will crash during import when it tries to determined if the LabelDescriptionHasChanged.

You can confirm that this is the issue by running the following SQL script:
SELECT objectcolumnname, s.FriendlyName 'Solution FriendlyName', label, objectid, LanguageId
FROM [LocalizedLabelAsIfPublishedView] l
LEFT OUTER JOIN solution s ON l.solutionid = s.solutionid
LEFT OUTER JOIN entity e ON l.ObjectId = e.EntityId
WHERE e.name = 'new_entity'

Of course you'll need to change the new_entity to the schemaname of your entity. If this query results only the LocalizedName and LocalizedCollectionName but no "Description", then this is could very well be the cause of the error messages. Another way to confirm is to check the customizations file, search for the entity and determine if the tag <Descriptions> is present.

The way to solve this is quite easy. In your source system, go to the correct entity, add a description and export the solution again. You will need to remove the previous solution from the target environment though.



Workflow With Id = fe31a1bb-949e-e511-80c3-0050569c18ec Does Not Exist

Similar to some of my previous blog articles, there can be some leftovers which limit you in removing a solution from your organization. This article helps you in determining the cause of the error when you face the following error.

ErrorCode: -2147220969
Message: Workflow With Id = fe31a1bb-949e-e511-80c3-0050569c18ec Does Not Exist.

Most likely there is a process, not necessarily a workflow, which hasn't been removed completely. The following query will help you identify which process is causing the error:

select label from LocalizedLabel where objectid = 'fe31a1bb-949e-e511-80c3-0050569c18ec'

Obviously you'll need to replace the objected with the guid from the error message.

Once you have found the culprit, then you can try to remove the process by using the CRM UI:

- Go to advanced find
- Select the entity 'processes'
- Remove the default query
- Select 'name equals' and paste the name that you retrieved from SQL
- Remove the returned records from CRM

You will want to avoid removing records from the database as much as possible as this generally causes more errors instead of solving them.

Note: I have found this problem to occur in CRM 2015 update 0.1, this might be fixed in CRM 2016.



Solution With Id = 86ac16ec-41d7-4685-a330-0b1c31411260 Does Not Exist

In some rare scenario's you might get the error message "solution With Id = 86ac16ec-41d7-4685-a330-0b1c31411260 Does Not Exist" while deleting a solution. In our scenario this seems to happen after using the holding solution approach. Luckily this can be solved as long as you have access to the SQL database. Note: Direct SQL updates are unsupported, so only perform this action if you're aware of the risks.

The error appears due to some remaining AttributeMap records for virtual attributes. In more detail, when you create an attribute map between two entities for a lookup attribute, it not only creating an attribute map for the id of the entity, but also for the name of that particular lookup. So in case of an account mapping, it creates an attribute map for accountid as well as accountidname. After moving around with solutions, CRM occacionally forgets to update the owning solution id for the 'name' attribute mappings.

You can visualize the relevant attributes using the following query:

SELECT
 a.SolutionId,
 a.SourceAttributeName,
 a.TargetAttributeName,
 pa.SolutionId,
 pa.SourceAttributeName,
 pa.TargetAttributeName
FROM attributemapbase a
LEFT OUTER JOIN attributemapbase pa
 ON a.parentattributemapid=pa.attributemapid
WHERE a.solutionid='86ac16ec-41d7-4685-a330-0b1c31411260'

You'll see the virtual attributes with their parent attributes and the corresponding solutionid according to the attribute map. The mismatch between the solutionid of the attributemap and the solutionid of the parent attribute map is what causes the error while deleting the solution. Updating the solutionid will solve the issue for you. Here's the query to help you perform this action. Obviously you'll need to change the solutionid to the solutionid as presented to you when downloading the error log file:

UPDATE AttributeMapBase
 SET SolutionId = pa.solutionid
 FROM AttributeMapBase
LEFT OUTER JOIN AttributeMapBase AS pa
 ON AttributeMapBase.ParentAttributeMapId = pa.AttributeMapId
WHERE AttributeMapBase.SolutionId = '86ac16ec-41d7-4685-a330-0b1c31411260'

I'm sure Microsoft will fix this issue sooner or later, but for now I hope this post will help you anyway.


Update:
Apparently there are other scenario's when this error occurs as well. When you create a businessrule, then on the database a record will be created in the "WorkflowBase" will be created, as well as one or more records in the "ProcessTriggerBase". For some reason it is possible that the records in the ProcessTriggerBase are not updated to the new solution ID, resulting in an incorrect record. While deleting a managed solution the deletion process recorgnized the non existing SolutionID and causes the delete to stop.

The way to identify the business rule that is causing the issue, you can run the following query:

select ptb.ProcessId, wb.Name, ptb.solutionid, wb.solutionid
from
 
 
ProcessTriggerBase ptb
 
left join WorkflowBase wb on ptb.ProcessId = wb.WorkflowId
where
ptb.solutionid='86ac16ec-41d7-4685-a330-0b1c31411260'

You then can delete this business rule by hand using the advanced find (search for all processes with category=business rule). Once this rule is removed, then the solution can be uninstalled.