CRM 4.0 Workflows don't start

Published 4/1/2008 by Henry in CRM
Tags:

In CRM 4.0 the MS CRM Workflow Service is not available anymore. CRM 4.0 has one Async Service the 'Microsoft CRM Asynchronous Processing Service'. The Microsoft CRM Asynchronous Processing Service takes care of all asynchronous processess that run within CRM like Workflow and Plugins (former Callouts). 

The Microsoft Dynamics CRM system architecture can be divided into 3 major components: the core system, which features the event execution pipeline, the database component, which hosts the asynchronous queue, and the asynchronous service. One benefit of the scalable architecture of Microsoft Dynamics CRM is that the asynchronous service can be hosted on servers other than the Microsoft Dynamics CRM server. This distributed processing capability can result in improved performance of Microsoft Dynamics CRM.

At a client I work on a CRM 4.0 system, my help was asked when updated workflows (from CRM 3.0 to CRM 4.0) that worked in CRM 3.0 did not work.
I soon came to the conclusion that the workflows did not even started. First I tried changing the executing identity on the service, which did not change anything.

After googling I found that lots of people had this problem and that the problem always was related to the MS CRM Website running with a hostheader, or second ip-address.
After trying out several different options my conclusion is that: 

CRM 4.0 needs to run without a hostheader and with the IP-address option 'All unassigned' chosen.
So you cannot use another IP-address and you cannot use hostheaders (if you want the workflow to function)!

I already found out that the CrmDiscoveryService Web service under the hood uses the machinename to connect to the CRMService and the MetadataService, when I tried to register a Plugin using the PluginRegistration Tool.
Which in itself is remarkable IMHO, the reason for a DiscoveryService is, I think, to decouple these services, which is rather hard if you can only connect using the machinename.

Anyway, if you got this issue make sure you use the following settings (the TCP port is not important in this case, you can use 5555 or 80 or another port):

IIS Website settings for MS CRM 4.0 website, assing no ipaddress and do not use hostheader
All unassigned without hostheader

Henry Cordes
My thoughts exactly...


Comments (4) -

Andy | Reply

4/1/2010 3:53:11 PM #

Hi Henry,

Good post. I'm wondering if you can point me to any documentation on how the async process works with the async cue - I've been searching for it and haven't found it yet. Specifically, I want to make sure I understand how two full installations of CRM pointing to the same database, one of which has the asynch service turned off, can share the asynch service on the second installation.

4/2/2010 9:54:31 AM #

Hi Andy,

I am not sure that what you want is supported, have you thought about the enterprise version, and multiple tennants for as a solution for your problem?

6/26/2010 4:17:46 AM #

Hi Henry,

Got official word back - you can do what I described - install a full CRM server and use one of them solely for the asynch service. I thought it was wierd too - but a client is doing it and MS confirmed it - one full professional crm server installed for the web server with the async service OFF, and another professional crm server installed with the async service ON - users could log in to either web server, but the way they use it, they only log into the first server, and the server with the async service is dedicated to that, to improve performance of the webserver and the async server. The DB server (a separate 3rd server, in this instance) will send all async requests in the cue to the server with async turned on.

8/7/2012 9:10:36 PM #

I know this is an old page but your suggestion worked great for me.  Still running through some testing but so far so good.  Any idea on why it is this way?   Thanks for your suggestion it saved me a call to Microsoft!!!

Add comment




  Country flag
biuquote
  • Comment
  • Preview
Loading