One of the most important aspects of the CRM 4.0 upgrade is what will happen to your plugins.
The first question to ask yourself is: Do I have any plugins installed?
That may seem like a strange question but what if CRM was installed 4 years ago and you are the fifth administrator to work on it?
Believe me, I’ve seen situations where plugins were installed and we:
1) Didn’t know what they did.
2) Didn’t know who wrote them.
3) Didn’t know where the source code was.
Locating your installed plugins
There are several methods for locating the plugins you have installed.
Using the Plugin Registration Tool
The Plugin Registration Tool is part of the CRM 4.0 SDK and is included in source-code form. This means you’ll need to have Visual Studio to compile it into an executable.
Note: I’ve uploaded a package containing the Plugin Registration Tool here in case you do not have a developer who can compile and run the tool for you.
Instructions on how to use the tool can be found here.
Using SQL Management Studio
If you happen to be fluent in SQL, you can run the following SQL script to get a list of Plugins and their location:
SELECT Name, CASE SourceType WHEN 0 THEN 'Database' WHEN 1 THEN 'Disk' WHEN 2 THEN 'GAC' END AS 'Location' FROM PluginAssembly WHERE Name NOT LIKE 'CompiledWorkflow%'
Extract Plugins Utility
I released a free utility that will extract CRM plugins that are found in the database and write them to disk. You may download that utility here:
Free Utility Released- Export CRM 4.0 Plugins
You have a list, now what?
Believe it or not, you need to make sure that each plugin is performing a required function. If it is not, then you can discard it. If it is, then you’ll need to document what it does, and when it’s activated. The idea is to go into the upgrade process with a list of clearly-defined and documented plugins so that you know what will happen when the upgrade occurs.
Why this is important
CRM 2011 only runs on a 64-bit server which can lead to issues is your plugins have been compiled to be specifically for 32-bit. This means you need to verify that they will function correctly in a 64-bit environment. If not, then they will need to be recompiled correct the issue.
Note: I’ll get in to more developer-specifics about that process in another article.
If you don’t have the source code to the plugin, then you need to work with a developer to either extract the source from the DLL or to recreate the plugin altogether. Either way, you really need to get a firm handle on your plugins prior to the upgrade process itself.
Other Resources
Read Ben Hosk’s article about:
