NOTE: This article applies to on-premises deployments of Dynamics CRM/365 only. In certain conditions, a plugin may cause the following error:
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=21ag3836ed358e35]]: Error in <PLUGIN_NAME> plugin, Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.Message:Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
Background
ClickDimensions plugins are registered to the sandbox service so that the ClickDimensions solution will work in CRM Online which only allows sandboxed plugins. In on-premise deployments of Dynamics CRM/365, it is not necessary to run the plugins in the sandboxed (isolated) mode. The Sandbox Processing Service is part of the CRM deployment and is responsible for executing plugins that are registered in isolation mode. The Sandbox Processing Service must be correctly configured or isolated plugins will cause errors such as the one above. The main reason for errors when plugins are in the sandbox mode is that the sandbox service is misconfigured. The vast majority of the time with on-premise deployments, the sandbox processing service has never been used for anything before installing a solution like ClickDimensions which is distributed to both on-premise and online customers, so it is often the case that no errors with plugins would have been previously observed since none were using the sandbox processing service prior to installing the solution. This error does not indicate a problem with the plugin code.
Resolution
The CRM administrator or partner should confirm that the sandbox service’s privileges and AD memberships are set up correctly per Microsoft’s documentation: https://technet.microsoft.com/en-us/library/hh699825.aspx#BKMK_sandbox_perm The list of privileges and setting in the article linked to above is pretty easy to check, but what can be harder to track down is if there is either a missing or a duplicate SPN. An SPN (Service Principal Name) is a unique identifier on a network for a given service. In a multi-server environment, the SPN for the sandbox service must be precise and it must be unique. What the SPN format should be depends on a variety of factors, and it can be hard to know if it is set correctly. Microsoft's field engineering team has posted a helpful Excel workbook that can be used to identify the SPNs for a given deployment scenario here: https://blogs.msdn.microsoft.com/crminthefield/2012/12/03/crm-2011-service-principal-names-spn-generation-and-usage/ Getting the SPN set correctly in some multi-server deployments can require trial and error unless done by a knowledgeable network administrator. The SPN should be set automatically when a server is joined to a domain or when a service is installed, but due to a variety of factors (including the order of installation, whether IIS is using kernel authentication mode, or if the environment has certain security measures in place) the SPNs can often be set incorrectly and you would never know unless you get an error in some specific scenario (such as running a plugin that needs to post a message out to the internet from the sandbox service).
Workaround
Due to the above factors, another viable option is to simply change the plugin isolation mode to ‘none’ by using the Plugin Registration Tool from Microsoft.