Gareth Tucker: Cannot Delete Plug-ins in CRM 2011

[Blog bot]

Источник: http://garethtuckercrm.com/2013/04/2...s-in-crm-2011/
==============

I recently had the less than enjoyable experience of hitting a new issue during a late night Production deployment.   This was perhaps the 6th deployment to this environment but the first time I had seen this problem.   The problem surfaced as an error during the deletion of the SDK Message Processing Steps of an existing Plug-in solution.  I typically delete all existing Steps and then delete the Plug-in Assembly before importing the new Solution zip file to ensure no retired Steps remain in the destination environment.   The CRM UI gave little information, just “an error has occurred”.  The CRM trace gave more details, but these didn’t immediately suggest the root cause:

“Error while normalizing non-case sensitive AD credentials for use on a case sensitive SQL installation”

“Unable to obtain DNS hostname of Active Directory domain controller with ntdsa object name”

“Action failed for assembly ‘XXXX.WMCRM.Plugins, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4f1f52667a84f9b5′: Assembly must be registered in isolation., ErrorCode: –2147220906”

“MessageProcessor fail to process message ‘Delete’ for ‘sdkmessageprocessingstep’.”

I started to wonder whether my deployment user account had been demoted from being a Deployment Administrator so I tried to launch the CRM Deployment Manager application.  It failed to launch.  It repeated the error from the trace:

“Unable to obtain DNS hostname of Active Directory domain controller with ntdsa object name”

My googling efforts landing me on this post:  http://social.microsoft.com/Forums/e...-809e4a9dc3b8/  which didn’t match my scenario but one of the solution steps resonated with the error message I was seeing:

Add the Preferred Domain Controller  value to MS CRM registry entries: HKLM\Software\Microsoft\MSCRM

Step 1. Right Click and click on NewString value as "PreferredDc"

Step 2. Add the value to PreferredDc is YourDomainControllerName you can find this in your AD by typing the command in your cmd prompt echo %logonserver%

And those steps worked for me.  I ran echo %logonserver% to determine the Domain Controller my server was connected to and added a registry key to tell CRM that was my Preferred Domain Controller.  Immediately (no reboot required) Deployment Manager was working again and I was able to delete my SDK Message Processing Steps.

So it seems like the CRM Deployment Service caches a Domain Controller and the one cached was no longer working correctly.  I was able to ping it, so it was up, but it wasn’t able to perform the function requested of it. 

We removed the registry key when finished.  I don’t think we want to tie the CRM deployment service to a particular DC.  I am hoping to learn more about this from Microsoft to determine steps to avoid these steps in the future.   Caching a Domain Controller in an Enterprise setting where Domain Controllers come and go seems like a product deficiency.   Neither an IISReset or a server reboot helped us.



Hope this helps someone out there.




Источник: http://garethtuckercrm.com/2013/04/2...s-in-crm-2011/