3
votes

On a Dynamics CRM 2011 on-premise installation, I'd like to write some code via the SDK that would register plugin steps (sdkmessageprocessingstep entities) for a plugin that is already installed via a managed solution. However, the plugin is not installed in isolation/sandbox mode.

I know that you cannot register a non-sandboxed plugin unless you're a Deployment Manager, and that you cannot register a sandboxed plugin unless you're in the system admin role. However, the plugin is already registered -- I'm wanting to just register steps.

Is there a way to register steps against an existing non-sandboxes plugin without the user having to be in the Deployment Manager or System Admin role?

Note: I gave the user Create, Update, etc, privileges to the following Entities in the CRM security roles, but that did not help:

  • Plug-in Assembly
  • Plug-in Assembly
  • Plug-in Type
  • List item
  • Sdk Message
  • Sdk Message Processing Step
  • Sdk Message Processing Step Image
  • Sdk Message Processing Step Secure Configuration
  • Service Endpoint

I also tried adding the user to the System Customizer role to no avail.

The goal is to keep from having to add the user as a Sys Admin but still allow them to (via an SDK call) register the plugin steps.

Clarifications: On the CRM server, I have a managed solution which includes a plugin. This plugin is not set to use sandbox/isolation mode. The managed solution does not include any registered steps for the plugin.

On a different (desktop) machine, I have written a Windows application which uses the CRM SDK to create sdkmessageprocessingstep entities in order to configure when the plugin runs. Think of this as an alternative implementation to the plugin registration tool that comes with the SDK, except that it does not register the plugin itself, rather just creates plugin processing steps associated to the plugin that is already installed.

1
What is the exception message and (if applicable) the inner exception message you are getting? This should provide some direction as to what permission(s) are missing. I don't know of any documented limitation on registering a plug-in step within a plug-in.Nicknow
I'm getting a FaultExpection with the following message (My hope is that there is a way around this.): Action failed for assembly 'My.Plugin, Version=1.0.6.0, Culture=neutral, PublicKeyToken=xxx': Assembly must be registered in isolation.John M. Wright
Does the plug-in complete successfully if it is executed by a system administrator? I would hate to try to troubleshoot this problem only to find out it has nothing to do with the roles and permissions.Nicknow
I've added some clarifications to the question. @Nicknow, the plugin itself isn't involved (yet). The code which I'm writing runs from a separate desktop app. If I run the app having authenticated the OrganizationService using a System Administrator user, it works. In my case, the only Sysadmin user I have access to is also a Deployment Admin, so I'm not sure which of those is granting the rights.John M. Wright

1 Answers

2
votes

After many attempts at getting around this and contacting some Dynamics CRM MVPs, I was unable to find a way, so am considering this answered as "no, you must be an admin user".

However, I did find an approach that works for me: I created a custom entity to store the information about which entities and steps the original plugin should be registered against, then created a second plugin that registers/unregisters the steps based on that information when the custom entity records are created, updated or deleted. I then provided a mechanism for the installing user to register the new plugin to run as a Deployment Admin user. Thus, the second plugin, running as a Deployment Admin user, can register the plugin steps and images for the first plugin (so that the first plugin can run under a lower-priority user).