CRM Imports & Workflows “Stuck” in Submitted State
Posted April 9th, 2009 / 2 Comments
PART I
I recently encountered a situation where imports and workflows in CRM could not be completed. The initial problem was recognized when data imports were being defined as “Submitted”, but not “Completed” in the CRM interface. I initially thought that the system was running slow, but after it took a full day to import two lead entities with no more than eight fields, I realized this wasn’t the case! At this point I made sure that the appropriate MS Rollups were applied and the CRM server was rebooted, in the hopes that these actions would somehow solve the problem. They didn’t. After confirming that the data import maps were correct, I noticed that workflows weren’t working either. I then checked the MS CRM Async Processing Service on the CRM server. For those of you who might not remember, the Async Process handles the processing of queued Asynchronous Events; i.e. data imports, workflows, system jobs etc in CRM(below). I checked to see if the Async Service was running, and of course it was. I checked that the “Log On” was set to Local, it was, and then I stopped and restarted the service. I tested a data import, and… nothing. Still stuck. At this point, I enlisted the help of those at MS, and here as what we found.
At first (to recap) all system jobs were in a waiting state and nothing was being processed. We looked into IIS and noticed that the CRM website was set to an IP address. (For instance, the CRM web IP) Since this was true, the Async service was not able to communicate to the CRM website. Since the AsyncSdkRootDomain was blank, it was trying to communicate to CRM by using the OTB loopback address of 127.0.01. Since the website was set to an IP address, it was not able to communicate to the loopback address. To define whether or not the AsyncSdkRootDomain has the correct value, or in our case ‘a’ value, run the following SQL query against the MSCRM database:
Select NVarCharColumn, * from DeploymentProperties
From this query, we are specifically looking for the value of the NVarCharColumn for the ADSdkRootDomain and ADWebApplicationRootDomain in comparison with the AsyncSdkRootDomain. When we realized there was no value for the AsyncSdkRootDomain, we went through the following to correct the issue. This is documented by MS in KB article 950416, which can be found here: http://support.microsoft.com/kb/950416
1. Downloaded the Deployment Configuration tool found in KB article 949079 (http://support.microsoft.com/kb/949079/).
2. Extract the Deployment Configuration tool, and put it in the location on the CRM server.
3. Back up the MSCRM_Config and OrgName_MSCRM databases*. �
4. At command prompt, path out to the directory that contains the microsoft.crm.deploymentconfigtool.exe file, and then run the following commands to correct this setting:
microsoft.crm.deploymentconfigtool asyncsettings update -sdkrootdomain:Peakcltnts32:5555
5. Reset IIS. To do this, click Start, click Run, type iisreset, and then click OK. �
After doing this, we were able to get the System Jobs running. Success!!!
Part II coming soon!
*This solution involves making changes to 1 or more databases. It is not suggested that changes made to a database without first making a backup of the database. If possible, alternatives such as a MS Hotfix or MS rollup should be used to try to solve the issue, before modifying a database. If you do decide to modify the database, it is suggested that the modifications are made by an IT Director, Technical Specialist or MIS department. Serious problems might occur if you modify the database incorrectly. Be sure to backup the database before making changes. Any problems might require that you rollback your databases and even result in the loss of data records. I.B.I.S,. Inc. cannot guarantee that these problems can be solved. Modify the database at your own risk.
