WorkflowManager could not deserialize XOML definition

[JayVDZ]

In an environment that has used MIMWAL before, but had it's custom workflows removed: when creating a new dead basic Update Resources workflow, upon execution, it fails with the following Event Log entries:

Unable to create new WorkflowInstance for WorkflowDefinition...

WorkflowValidationFailedException: The workflow failed validation

WorkflowManager could not deserialize XOML definition: ...

347 : : Invalid data found while deserializing an object of type 'Microsoft.ResourceManagement.Workflow.Activities.SequentialWorkflow'.

The workflow is:

DisplayName: Step One
Value Expression: "DummyValue"
Target: [//Target/Description]
Allow Null: True

Have also tried using a standard Function Evaluator activity instead, and that works, so it appears just be related to MIMWAL activities.

Environment:

• MIM Version 4.6.540.0
• MIMWAL 2.20.723.0
• Windows Server 2012 R2
• SharePoint 2016
• Single node active. Others turned off

Diagnostics Performed:

• Tried creating a MIMWAL Add Delay workflow as well, this also fails as above
• MIMWAL upgraded to version 2.20.723.0 on all nodes
• Old MIMWAL dlls uninstalled from the GAC
• Service config file checked for correct binding redirects and public key tokens
• Tried editing XOML and replacing 4.0.0.0 version references with 3.5.0.0 as one article suggested
• Rebooted server
• Threw hands up in the air and swore a few times

Any ideas? :)

[sylvainclb]

Hello Jay,

Any custom activities are registered in MIM by creating an object of type ActivityInformationConfiguration. You can review them under "Administration > All resources > Activity Information Configuration"

As you use an upgrade version of MIMWAL, you should update version on all related MIM WAL activities.

You can use the Register.ps1 script provided under the Scripts folder solution to do that. And then use the UpdateWorkflowXoml.ps1 script to update any old workflow that use a MIMWAL activities.

Kind Regards,
Sylvain

[JayVDZ]

I know :) Thank you though.
It doesn't matter if the workflows are old or new from after the upgrade, they still fails to deserialize.

[sylvainclb]

Maybe, you can past the XOML of your failed WF definition?
I can try to compare it with one dummy in my env :)

[NileshGhodekar]

Enable the .NET fusion logs. It may tell you what ref assembly or binding redirect for it is missing

[JayVDZ]

I've got some Fusion logs (using Fusion++) and the only logs during the execution window are for powershell.exe, which doesn't seem right. I'm not using a MIMWAL PowerShell activity. There's no binary references to MIMWAL namespaces. I think this is a red herring. It also only occurs once, not the second time I repeat the test in MIM, so I think it's coincidental.

There are a few Error items (getting logs off the server is difficult):
powershell.exe | System.Management.Automation.resources, Version=3.0.0.0, Culture=en-US, PublicKeyToken=...
Using machine configuration file from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config
Attempting to download files from file:///C:/WINDOWS/system32/WIndowsPowerShell/v1.0/en-US/ to do with System.Management.Automation.resources << Have checked, there's no such files in this location. The folder exists and has a few .mui and a .txt files.

Same for Microsoft.PowerShell.ConsoleHost.resources
Same for Microsoft.PowerShell.Security
Same for Microsoft.InternationalSettings.Commands

I also wrote a test HelloWorld app that has dependencies on something else and that showed up fine in Fusion, so it doesn't seem to be a logging issue. It's like MIM is not getting as far as trying to invoke the MIMWAL binaries.

[JayVDZ]

Tried a different scenario: log whilst restarting FIMService. This has produced a lot of errors. All to do with MIM binaries, not MIMWAL (the WorkflowActivityLibrary dll is loading fine). Analysing this...

[NileshGhodekar]

Believe MIMWAL is compiled with reference to System.Management.Automation\1.0.0.0. You may not have correct version of PowerShell. Not sure if you can build with 3.0.0.0 version of System.Management.Automation and that can run in .NET 3.5

[JayVDZ]

Mmmm, there was a PowerShell upgrade on the server recently, so you might be on to something there. Thanks Nilesh.

[JayVDZ]

Happens in another environment with the same customer. This has had no PowerShell upgrades. Hrm.

[zamojo]

I hope JayVDZ was able to fix the problem last year. I stumbled upon this Github issue when I encountered the same error. I was able to fix it relatively quickly because I retraced my steps and remembered that I had added a diagnostic source for tracing, with switchValue="Verbose" (which worked). However, when I tried to just set the switch to match the other sources, switchValue="AllSwitch", that's when I got the WorkflowManager could not deserialize XOML definition error. I fixed it by just commenting the entire source.

Hope this helps someone.

<!--
<source name="MicrosoftServices.IdentityManagement.WorkflowActivityLibrary" switchValue="Verbose">
    <listeners>
        <add initializeData="MicrosoftServices.IdentityManagement.WorkflowActivityLibrary" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="WALEventLogListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack">
            <filter type="" />
        </add>
    </listeners>
</source>
-->