If there is software, there have to be a bug. FIM 2010 as nice platform for identity management projects is not free from bugs of course, we have to live with them, wait for fixes to come and sometimes get to know how to handle them. This one is the latter case.
One of nice features of FIM is possibility to use approval activity to construct approval processes for user actions in FIM service. As every consultant working with FIM I can easily come with few things I would improve in approval activity, but this doesn’t change the fact, that this is easy to use and fast way to build approval workflows. If you will combine it with a little of custom activities it can be used even in a cases as dynamically calculated approvers based on conditions or conditional approval based on result some condition check (just two examples how we use it).
While working on rather simple case of approval for user actions I came across a problem that my approval activity stopped to work and on every instance of request I’ve got “Access Denied” because my workflow failed with exception “Object reference not set to an instance of an object“.
On FIM Service in Event Log I’ve found Event ID 3 which was caused by this exception, but with not a lot more details.
Error message from Event ID 3:
Microsoft.ResourceManagement.Service: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.ActivateHost(ResourceManagementWorkflowDefinition workflowDefinition, Boolean suspendWorkflowStartupAndTimerOperations)
at Microsoft.ResourceManagement.Workflow.Hosting.WorkflowManager.StartWorkflowInstance(Guid workflowInstanceIdentifier, KeyValuePair`2 additionalParameters)
Getting to the source …
Troubleshooting of built-in activities is a bit troublesome, if not say that there is no option for that. Custom activities are rather easy to troubleshoot with debugger however here out options are limited. Only option was to try to narrow down possible causes for this error.
This particular workflow has used mix of custom and built-in activities, as first step for troubleshooting I’ve started to troubleshoot and finally remove from workflow custom activities to exclude possible bug in my code.
Troubleshooting Tip Of the Day
It is generally good idea to start to narrow down the area you are troubleshooting if you are experiencing problem in your solution, code, network. Removing elements of a solution and then adding them again will greatly improve ability to find element which is causing a problem. This might be custom activity, network load balancer or load balancing in general etc.
Quickly I’ve found out that this workflow is failing even with only single, built-in activity. So my code was OK. What was wrong then?
At Predica we are using scripts to deploy our FIM solution and this was not a different case. This solution was deployed from the script including this workflow definition. However as this was development environment, later I was testing some change introduced manually to this workflow. And this was it. After re-deploying this workflow from the script and later editing workflow definition in FIM portal problem occurred again.
Quick XOML comparison showed a problem – there was single difference between original versions:
And version altered in FIM portal:
It looks like this behaviour happens only when FIM portal is deployed together with Sharepoint 2013
And now … workaround.
Workaround for this behaviour is simple but not very convinient to use if you want to do this through portal. In order to fix this situation you need to edit XOML definition of workflow (XOML is actually description of your workflow) and find following piece of definition:
Now you have to replace version of .NET in this reference to 126.96.36.199
In order to get to XOML you can open your workflow definition and click “Advanced view” button. XOML workflow definition can be found on “Extended attributes” page. You can safely copy it out of there to your text editor of choice (try SublimeText – my editor of choice for such things).
What is less fortunate is that you will have to do this every time your authorization workflow will be edited through FIM portal. One more reason why to script all configuration tasks in FIM – PowerShell really helps with this task.