WWF and Sql Server 2000 on a remote machine
A few weeks ago I was trying to run a workflow on my local machine using a remote Sql Server 2000 for the tracking & persistence services.
“Windows Workflow Foundation provides an implementation of it through the SqlWorkflowPersistenceService. This class saves workflow data to a SQL Server 2000 or SQL Server 2005 database with a well-known schema.”
While the official documentation is referring Sql Server 2005 & Sql Server 2000 the same - reality proved me otherwise:
To summarize things all I got was jammed workflow instances without any exceptions, log records or crashes not on the workflow runtime or on the Sql Server side. The instances simply looked as if they were lost, not terminated nor completed.
The tracking tables (UserEvent for example) were all empty and it seemed like something / someone is keeping my tracking requests away from the db without letting the source (workflow runtime) know about it.
I have to mention that my remote machine was on a different, not trusted domain on our network. Accessing the database with the same connection string from other applications did work fine.
At first I thought the problem might be related to the fact that the domains were not trusted and / or because I wasn’t using integrated security with in my connection. After installing a fresh Sql Server instance on another computer on the same domain which resulted the same not-working result I went searching other directions.
While searching some examples at thecodeproject I came across an example which used the system.diagnostics switches from the app.config in order to track the wf lifecycle.
Turning it on inside my application finally allowed me to witness a solid hint for my problem:
System.Workflow.Runtime.Hosting Error: 0 : DefaultWorkflowCommitWorkBatchService caught exception from commitWorkBatchCallback: System.Transactions.TransactionException: The partner transaction manager has disabled its support for remote/network transactions. (Exception from HRESULT: 0x8004D025) ---> System.Runtime.InteropServices.COMException (0x8004D025): The partner transaction manager has disabled its support for remote/network transactions. (Exception from HRESULT: 0x8004D025)
at System.Transactions.Oletx.ITransactionShim.Export(UInt32 whereaboutsSize, Byte[] whereabouts, Int32& cookieIndex, UInt32& cookieSize, CoTaskMemHandle& cookieBuffer)
at System.Transactions.TransactionInterop.GetExportCookie(Transaction transaction, Byte[] whereabouts)
A clue – at last! (and another one)
The Solution:
- Update the host file on the server so it will recognize the client by it’s name
- Update the DTC security configurations on both servers
- Reboot both machines
While implementing the solution I came across the following exception which I failed to fully resolve so far:
System.Workflow.Runtime.Hosting Error: 0 : DefaultWorkflowCommitWorkBatchService caught exception from commitWorkBatchCallback: System.Workflow.Runtime.WorkflowOwnershipException: This workflow is not owned by the WorkflowRuntime. The WorkflowRuntime's ownership has expired, or another WorkflowRuntime owns the workflow.
This happens when I start the persistence service from the code – however, this doesn’t happen when I’m starting it from the configuration section.