System Job error in CRM: Code -2147204346

1) Error Code : -2,147,204,346
To find them you need to convert the code to hexadecimal. You can do this
using the windows calculator (view: scientific). Do include the – and discard
the F’s at the begining.
Code -2147204346 will give you 80044306. Which is an Async network error,
this probably means the async service cann’t be reached.
Locate the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM
Right-click MSCRM, click New, and then click String Value.
In the Name box, type LocalSdkHost.
Right-click LocalSdkHost, and then click Modify.
In the Value box, type the name of the Microsoft Dynamics CRM server or the host header, and then click OK.
 
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart the IISAdmin service.
 
4) Using Advanced Find with Dynamics CRM Workflows
 Why does a workflow get stuck in the “Waiting place“? Here are a couple common reasons I encounter from time to time:
A workflow might have a logical flaw. For example, if a workflow is on a Wait condition and the record the workflow’s running on gets closed, what happens if the workflow doesn’t have built-in logic to cancel itself? In cases like this one, after you identify the records you can select them and select Cancel from the More Actions menu. You will also want to fix the workflow: unpublish it, make the changes, and publish it again. This won’t help any records it was already running on, however, since it’s still the flawed version of the workflow that’s running on them!
Or how about if the workflow’s trying to do assign a record to a user who doesn’t have Read privilege to that record type? That will do it too. This can be confusing, since it’s easy to assume that an automatic workflow written and owned by a System Administrator can “do anything” (since as we know an automatic workflow runs in the security context of the workflow owner). But just because you’re a System Administrator doesn’t mean you can assign a record to a user who can’t own those records! This can be a good place to see how Resume works rather than Cancel. If the problem was insufficient privileges and you modify the user’s security role, you can resume and watch the workflow try again.
There’s a general point we can make here, on this issue of when you can Resume and when you have to Cancel when it comes to Dynamics CRM workflows stuck in the waiting place:
If the problem is caused by something outside the workflow – like a security role problem, or trying to modify a read-only record – you can fix the problem, then Resume the workflow.
But if the problem is with the workflow itself — and you have to unpublish, modify and republish what will be a different version of the workflow – you’ve got to Cancel.
Advertisements

1 Comment (+add yours?)

  1. crmbeginning
    Oct 04, 2013 @ 12:01:56

    Many Many Thanx, Finally this is the only blog which helped me. 🙂 Thanks Once Again

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: