As many of my co-workers know, one of the messaging technologies that is near and dear to my heart is our beloved workflow components that are available to developers in Exchange 2000 and 2003.  Over time and after working with numerous developers on various Exchange workflow related issues, I've attempted to compile a list of commonly used troubleshooting steps.  I'm hoping that these may help a workflow developer resolve some of the more common roadblocks that they he/she can encounter while developing a project with the workflow components.

My goal with this post is to try to provide as many steps, tricks, and information as possible here to to knock out some of the low hanging fruit of workflow issues.

Here's the common list of basic steps to check off:

General troubleshooting:

  • Make good use of "Exchange Explorer" form the Exchange SDK tools.  With Exchange Explorer you can view the items that have been posted into a workflow enabled folder and determine all kinds of things about the state of the workflow on that item.

Creating/Registering workflow processes in a public folder:

  • Can you connect to the same public folder with OWA & Outlook?  If not, why?
  • Verify the person trying to register the workflow process has the appropriate permissions to properly register a workflow project in that public folder.  Specifically "Can Register Workflow", and if needed "Privileged Workflow authors" roles in the COM+ application.
  • Get and review Event Logs, System & Application specifically from the Exchange server that the workflow process is attempted to be registered on.
  • Make sure that you are connecting to the server that has an instance of the public folder where we are trying to create the workflow process.  Also make sure that for each of the public folder servers that has/will have an instance of the public folder hosting the workflow process also has the workflow COM+ component installed and is configured correctly on each one of those servers.
  • Make sure the person registering the Workflow has a mailbox.
  • Make sure the person registering the Workflow is the owner of the Public Folder, or at least has enough permissions to create and modify items created in the folder.
  • Make sure Basic Authentication is checked on the Public Folder Virtual Root.
  • Make sure "Execute Permissions" for scripts is checked on the Public Folder Virtual Root.
  • Get and review network traces of the traffic from the machine registering the workflow process to the Exchange server for errors.
  • On the Exchange server, take a look at the IIS logs for any errors related to WebDAV verbs being performed on the workflow public folder. 

Workflow COM+ component:

  • Confirm NT System/Authority account is listed in the "Privileged Authors" Role.
  • Make sure the workflow account that is set as the account for the Workflow package is part of Exchange Domains Servers group.
  • Make sure the account NTAuthority/System is the member of Privileged Workflow Authors Role.
  • If, for some reason you need to recreate the Workflow COM+ application, run regsvr32 on the CDOWFEVT.DLL.  This will recreate the COM+ application for the workflow event sink.  If COM+ application is already present, another one will be created, so I suggest that none exist before doing this suggestion.  After the new application and component is created, you would need to reconfigure the COM+ settings and roles manually or use the following scripts from the Exchange SDK: (addwfrole.vbs or wfsetup.vbs) to configure these roles in the COM + application.

Workflow Events not firing:

  • Try creating a synchronous OnSyncSave sink in the folder and post a new message to that folder.  What this will help you determine is if any events are getting fired for the store.  This can be useful information since that's the same thing that the Workflow engine is using to do all of its magic.  Generally you'll see that if the workflow events are failing to fire so do normal synchronous sinks.  If you find that the sinks are not firing the next item below is a good bet to investigate here.
  • You can also check for duplicated StoreEvents{GUID} system folders on your exchange server.  From experience, this has accounted for quite a few issues where the workflow engine is not doing its job correctly.  This article show how to check for this:

924171 Error event ID 116 is logged in the Application log every time that you start a server that is running Exchange 2000 Server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;924171

Troubleshooting specific Workflow errors:

EventID 4098 appears while posting message to a workflow-enabled folder
http://support.microsoft.com/kb/297508

Cannot Register Workflow Events After You Change Permissions for the Exchange Domain Servers Group
http://support.microsoft.com/kb/315526

You cannot synchronize offline changes with a workflow-enabled public folder in Exchange 2000 Server
http://support.microsoft.com/kb/810018

INFO: Workflow Behavior When Folders Are Replicated
http://support.microsoft.com/kb/309469

Other interesting bits of information:

Description of how to obtain Microsoft Workflow Designer for Exchange
http://support.microsoft.com/kb/318895

Support policy for Microsoft Exchange APIs with the .NET Framework applications
http://support.microsoft.com/kb/813349/en-us

Understanding Exoledb’s default folders
http://blogs.technet.com/exchange/archive/2005/05/11/404826.aspx

Understanding Public Folders and System Folders
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3AdminGuide/c9040a64-ee66-445f-92b7-825db0da732f.mspx

If you know of any other tips that you have used to get through a sticky Exchange workflow issue, comment this post and we'll see about getting it added to the list above.