Bernado Nguyen-Hoan's Blog – Coding Stories from an IT Mercenary

This is a rehash of several posts by other people.

A user in CRM has a default organisation. This is the first organisation where the user was created. Use the SQL script below to identify the default organisation for a user:

select a.domainname, a.systemuserid, d.DatabaseName, d.uniquename 
from <Org Name>_MSCRM.dbo.systemuserbase a WITH (NOLOCK)
inner join MSCRM_CONFIG.dbo.SystemUserOrganizations b WITH (NOLOCK)
on a.SystemUserId = b.CRMUserId
inner join MSCRM_CONFIG.dbo.SystemUser c WITH (NOLOCK)
on b.UserId = c.id
inner join MSCRM_CONFIG.dbo.Organization d WITH (NOLOCK)
on c.DefaultOrganizationId = d.id
where a.domainname ='DomainUsername'

The script above was posted by Susan in the comment section of this post: https://blogs.msdn.microsoft.com/arpita/2013/01/23/how-to-find-default-organization-for-any-user-in-multiple-organization-crm-deployment/, which describes how the underlying data hang together to determine the default organisation for a user.

When does this might come in handy?

When a user runs a report in CRM, CRM appears to check for the user against their default organisation. The report will not be rendered correctly if this organisation is disabled. I found this information at this post: https://crmbrewer.wordpress.com/2016/05/05/crm-reports-error-error-sys-is-undefined/.

In our particular case, we found the below stack trace in the Event Viewer. My guess is that this is a MS bug that may one day be addressed. This was observed on CRM 2016 on-prem.

Exception type: CrmException

Exception message: The CRM organization you are attempting to access is currently disabled.  Please contact your system administrator

at Microsoft.Crm.BusinessEntities.SecurityLibrary.ValidateOrganizationState(IOrganizationContext context, LocatorServiceContext locatorServiceContext)

at Microsoft.Crm.BusinessEntities.SecurityLibrary.CheckDisabledStatus(IUser user, IOrganizationContext context)

at Microsoft.Crm.BusinessEntities.SecurityLibrary.ValidateUserEnabled(Guid userId, Guid organizationId)

at Microsoft.Crm.Authentication.Claims.AuthenticationProvider.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationStep.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationPipeline.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationEngine.Execute(Object sender, EventArgs e)

at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Ribbon Workbench is a great tool for customising the ribbon in CRM. When you need to customise an OOTB button/command however, it can be a bit difficult to identify the correct button/command to work with. This is particularly true when some of the OOTB buttons appear the same on the Ribbon Workbench’s UI, such as the Add Existing buttons below.

One way to identify the correct button/command is to inspect the HTML on the CRM form.

In the example below, I can see that the ID of the + (add existing record) button on a sub-grid is Mscrm.AddExistingRecordFromSubGridAssociated.

I can then pick the right button to customise in Ribbon Workbench by selecting the button with the same ID for CommandCore:

Hope this helps increase your productivity with Ribbon Workbench.

Our plugin was throwing the error below when creating a new task record:

‘An unexpected error occurred.’

at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Create(Entity entity, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode, Dictionary`2 optionalParameters)
at Microsoft.Crm.Extensibility.InprocessServiceProxy.CreateCore(Entity entity)

…

We were not doing anything fancy that led to this error – except we used early-binding classes:

var task = new Task
{
	Subject = "New task",
	Description = "Some description..."
};

task.Id = _organisationService.Create(task);

Our plugin was deployed to the database, and we used ILMerge to package everything into a single DLL as required by CRM under this deployment type. This was not the cause of our problem.

The strange thing is the plugin only error when running asynchronously. Changing the plugin step to be synchronous and everything works fine.

It turns out that this is because there are different behaviours between the CRM execution context for synchronous versus that for asynchronous.

Let’s take a step back in order to fully understand this. The IOrganizationService instance has a non-public property _proxyTypesAssembly that points to the assembly where the early-binding classes are defined. This must be set for the service instance to be able to work with early-binding classes properly. When things are good, this is what it looks like when you debug:

The error occurs when this property is null.

So how does this property get set? In plugins we typically use an instance of IOrganizationServiceFactory to get access to an instance of IOrganisationService:

serviceFactory = (IOrganizationServiceFactory) serviceProvider.GetService(typeof (IOrganizationServiceFactory));
service = serviceFactory.CreateOrganizationService(userId);

It is at this point that the _proxyTypesAssembly property is set for the IOrganizationService instance by the IOrganizationServiceFactory.

Below is a screenshot of inspecting the IOrganizationServiceFactory when the plugin in running synchronously. Note that the public ProxyTypesAssembly property is automatically set.

Also note that the type of the IOrganizationServiceFactory instance (serviceFactory) is Microsoft.Crm.Extensibility.PipelineExecutionContext.

Below is a screenshot of the same plugin running asynchronously. Note that the public ProxyTypesAssembly property is null, and the type of the IOrganizationServiceFactory is different compare to when running synchronously.

This is why by default plugins that use early-binding work fine in synchronous mode, but fail when running asynchronously.

To fix this issue we need to set the ProxyTypesAssembly property of the IOrganizationServiceFactory instance. While this property is not exposed on this interface, Darko Micic has found that the IOrganizationServiceFactory interface can be casted to IProxyTypesAssemblyProvider, which allows us to set this property.

The code to retrieve an instance of IOrganizationService therefore becomes:

var serviceFactory = (IOrganizationServiceFactory) serviceProvider.GetService(typeof (IOrganizationServiceFactory));
var proxyTypesAssemblyProvider = serviceFactory as IProxyTypesAssemblyProvider;

if (proxyTypesAssemblyProvider != null)
{
	proxyTypesAssemblyProvider.ProxyTypesAssembly = Assembly.GetExecutingAssembly();
}

service = serviceFactory.CreateOrganizationService(userId);

Note that in Darko’s post he mentioned casting the execution context to IProxyTypesAssemblyProvider. In my debugging I have found that IOrganizationServiceFactory and IPluginExecutionContext actually points to the same instance when retrieved from the service provider. I therefore have chosen to cast the IOrganizationServiceFactory instance instead.

This is a rehash of Michaël Hompus’ post https://blog.hompus.nl/2015/05/28/entity-type-code-using-javascript-only/ to help me remember this very useful trick.

Note that the scripts described in this post are unsupported.

In JavaScript, use Mscrm.EntityPropUtil.EntityTypeName2CodeMap to retrieve the entity type code for a given entity type name, e.g.:

Mscrm.EntityPropUtil.EntityTypeName2CodeMap.new_application   //returns 10008

Use Mscrm.EntityPropUtil.EntityLogicalNameToLocalizedNameMap to retrieve the entity display name for a given entity type name, e.g.:

Mscrm.EntityPropUtil.EntityLogicalNameToLocalizedNameMap.new_application   //returns Credit Application

Depending on how your script was loaded, Mscrm may be null, in which case try looking for it under the parent object instead, i.e. parent.Mscrm.EntityPropUtil…

There are many benefits of using early-binding when coding against CRM. There are times however when you need to fall back to late-binding, for example when you need to query relationships, or when you need to call Retrieve to optimise performance (as this service call allows you to load only selected fields of a record).

Rather than using literal string, you can use the nameof operator in C# 6 to get the attributes and relationship names. This works because the properties of the early-binding classes are generated based on the attributes and relationship names in CRM.

For example, to get the AccountNumber field of an Account record:

var client = new CrmServiceClient(ConfigurationManager.ConnectionStrings["CRM"].ConnectionString);

//Remember to convert to lowercase.
var accountNumberAttributeName = nameof(Account.AccountNumber).ToLower();

var entity = client.Retrieve(Account.EntityLogicalName, Guid.NewGuid(), new ColumnSet(accountNumberAttributeName));
var accountNumber = entity.ToEntity<Account>().AccountNumber;

And there you have it: late-binding with all the early-binding zen!