Plug-in not working

One of the most read pages on my blog is the list of reasons why a callout won't work. Since the release of CRM 4.0 we do not have callouts anymore, but we're using plug-ins for extending CRM. This article will contain all the reasons that I find on why a plug-in is not working.

Error:


"Unable to load the plug-in assembly"

There are multiple reasons why this error can occur. These reasons include:

- The plug-in is registered on disk, but the file is not located in the correct location (drive:\crm server folder\server\bin\assembly\). Keep in mind that if you use the registration tool that the plug-in will be registered, but the file will not be placed in the right location. This is a manual step.

- The plug-in is registered on disk and the file is located in the correct location, but the security settings are not correctly set on the assembly file. Once you have copied the file to the \server\bin\assembly folder, make sure that you check the permissions of the file. The user which is used to run the application pool in which CRM is running, should have read & execute rights. You can set this by going to the folder and right click on your plugin its dll file. Then press "Properties". Go to the tab "Security" and add the user which is used for the application pool. This user you can figure out in the IISManager. There look at the properties of the CRM website to find out which application pool is used. Then look in the application pool's properties to find out the identity. Most likely this is "Network Service" but it could be changed in your situation.

After setting the security settings, make sure to perform an IISreset.

- Your environment exists out of multiple servers and the plugin is registered on disk. In this situation make sure that the file is placed in the \server\bin\assembly folder on all servers. Also the security should be set correctly (see other possible reason).

Error:

"The request failed with HTTP status 401 unauthorized"

Possible reasons for this error include
- The code does use a reference to the webservices, but uses credentials which do not have enough privileges in CRM

- The plug-in does is created for the non default instance. In this case, look at the following kb article: http://support.microsoft.com/kb/948746. From there you can request a hotfix for this issue.

Error:


"Not have enough privilege to complete Create operation for an Sdk entity"

This error shows up even though the user is a System Administrator. The cause is that the user is not a member of the Deployment Administrators group in CRM Deployment Manager. Once you have added yourself to that group it will work. Keep in mind that you will need to login as an administrator to be able to open the Deployment Manager.

Error:


"The request failed with http status 400: Bad Request"

This error seems to come from a piece of code in the synchronous plug-in framework which forces the CrmService to use the localhost. George has written a post on the logic behind this.
http://crm.georged.id.au/post/2008/02/22/Synchronous-plugins-want-localhost.aspx
The solution is to either run the plug-in asynchronous or otherwise make the webservice available from the localhost.
Update: There is a hotfix available for this issue now: http://support.microsoft.com/kb/950542

As soon as I run into other issues with plug-ins, I'll definitely add them to this list.

11 comments:

Richard said...

I have the 401 problem when running on a two-server setup. The first server runs the plug-in fine, the second server gives the 401 Unauthorized exception. Have you come across this before?

Ronald Lemmen said...

Richard,
Did you publish this assembly to the database? Since you are using multiple servers, using a database would be the best/easiest bet.

Aman Bhandari said...

Hi, many thanks as was having tbe 400 bad request problem (that I never saw in the last 12 months of plug-in development on v4.0) and the blog pointed me to the right direction. Cheers!!

Mark Kovalcson said...

I just started to get this problem. Everything works fine on my W2003 32bit VPC image. When I deploy to a W2008 64bit production system I run into problems but only on one of the steps in a single assembly with nine other steps and a custom workflow. This appears to have started after Rollup 2, but I'm not sure if they are related yet.

Anonymous said...

Mark, I believe that your assembly may need to be recompiled for the 64-bit platform...should be in the compilation options somewhere. I could be wrong though.

srinivas said...

Hi,
we have a requirement of adding the steps to the registered plulgin using c#. Need your help.

Anonymous said...

I have the 401 problem when running on a two-server setup too. did you find an solution, please?

SaadUmair said...

Hi,
I've registered a "Hello World" (It renames the Account name upon creation)plug-in (provided with CRM 4.0 Sdk) using the Plug-in Registration Tool (provided with CRM 4.0 Sdk). It got registered successfully,but its not working. When i create a new Account, it doesn't rename it. I also registered another plugin (provided with CRM 4.0 sdk) that creates a Task activity upon Account creation, that also didn't work.
I tried registering the Plug-in assemblies in GAC as well as on disk, placed the DLLs manually in server\bin and also gave full rights to the user.

Kindly help me ASAP in this regard. Thanks in advance.

--
Saad

Ronald Lemmen said...

Hi Saad,

Have you enabled the trace of CRM and check the log? This usually contains valuable information.

Ronald

SaadUmair said...

Hi Ronald,
I got the solution myself for my problem i posted earlier.
I was registering my Plug-in using the Plug-in Registration Tool, but was missing a step "Register New Step" for that plug-in. I did that, and now the Plug-in is being triggered upon Account creation successfully.

But still, i have a confusion in mind, if you can help me on that. In the Plug-in CS file (code) i am checking the event, i.e. my code should get executed when a new Account is being created. Then why we need to "Register New Step" (and specify that plug-in should get triggered on Account Creation) when this thing is already being catered in the CS file (code).
Thanks in advance.

--
Saad

Ronald Lemmen said...

Hi Saad,

This has been designed like that to be able to guarantee in your code that a functional administrator does not make a mistake which would break your code. In larger deployments it often happens that the creation is being done by a differnt person. The same is valid for Add-ons.

I can understand your confusion, but this has been done to make sure you do not get blamed for errors which are being made by other people.

Kind regards,
Ronald