Support Portal ContactGet in touch

RetrieveMetadataChangesRequest Error in Dynamics following Upgrade

   Words by Paul McQuillan

   on 31/12/2018 10:00:00

This article concerns a pretty obscure error that you may see after performing an Upgrade of Dynamics CRM – and so is very much a particular fix for a very particular error.

If you are seeing this error in these circumstances, then this is the article you need!

However, hopefully this article also gives information on the trouble-shooting process for solving this error.

This process may also be useful for solving similar types of problems at the heart of the Dynamics CRM SQL Database, and be useful to Technical Consultants experiencing problems with Dynamics following installations or upgrades.

Now – onto the problem.

Problem Symptoms

We encountered this problem after upgrading to Dynamics 2016 and could see this in two main areas:

1. Whenever we attempted to edit the SiteMap in Dynamics, we would see the following error


2. When our custom code attempted to invoke the RetrieveMetadataChangesRequest operation, this would fail with a ‘unexpected error has occurred’


This was a recently upgraded Test & Train Environment, and we observed that both problems did not occur in a similarly upgraded Development Environment for the same Project.

But.. what was causing the problem?


Our first port of call was to review the Event Log of the offending Dynamics Server and review the Stack Trace of the Error – as we are going to need more information over ‘unexpected error’ to solve this one.


Reading the Stack Trace is quite difficult as it is effectively unpicking someone’s else code to try and figure out what is going on.

But we can also observe that each time we click in the SiteMap Editor, this error is being logged.

What happens when we click into Subarea in the SiteMap Editor?  Dynamics offers us the option to select which Entity we want to show for that Subarea.

What does this mean?  Well Dynamics must be querying the Metadata List of Entities to show us this drop-down – and so must be invoking a similar message to our Custom Code above, and so hitting the same error, this is how we tell that the Errors could well be connected.


From this information, we can start taking a detailed look at the Stack Trace to determine why the RetrieveMetadataChangesRequest is going wrong somewhere.

The Web Service plug-in failed in OrganizationId: 977e35c4-5074-e211-9aa0-00155d05151c; SdkMessageProcessingStepId: 0be4fe20-6cad-4b33-8dcd-118352d18559; EntityName: none; Stage: 30; MessageName: RetrieveMetadataChanges; AssemblyName: Microsoft.Crm.Extensibility.InternalOperationPlugin, Microsoft.Crm.ObjectModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35; ClassName: Microsoft.Crm.Extensibility.InternalOperationPlugin; Exception: Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
    at System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values)
   at Microsoft.Crm.Extensibility.InternalOperationPlugin.Execute(IServiceProvider serviceProvider)
   at Microsoft.Crm.Extensibility.V5PluginProxyStep.ExecuteInternal(PipelineExecutionContext context)
   at Microsoft.Crm.Extensibility.VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context)
Inner Exception: System.NullReferenceException: Object reference not set to an instance of an object.

   at Microsoft.Crm.ServerLocatorService.GetDeploymentSetting[T](String settingName, T defaultIfNotFound)
   at Microsoft.Crm.Metadata.Query.SelectFromMetadataCacheStrategy.get_MaxDepthOfNestedFilters()
   at Microsoft.Crm.Metadata.Query.SelectFromMetadataCacheStrategy.ValidateConditionAndFilterNesting(String metadataEntityName, MetadataFilterExpression filter)
   at Microsoft.Crm.Metadata.Query.SelectFromMetadataCacheStrategy.GetFilterExpression[TSource,TDestination](String metadataEntityName, MetadataFilterExpression filters)
   at Microsoft.Crm.Metadata.Query.SelectFromMetadataCacheStrategy.SetMetadataFilters(String metadataEntityName, MetadataFilterExpression filters)
   at Microsoft.Crm.Metadata.Query.MetadataQuerySelectVisitor.UpdateStrategyWithQuery(String metadataEntityName, MetadataQueryExpression query)
   at Microsoft.Crm.Metadata.Query.MetadataQuerySelectVisitor.Visit(EntityQueryExpression query)
   at Microsoft.Crm.Sdk.Metadata.MetadataServiceProvider.RetrieveMetadataChanges(EntityQueryExpression queryExpression, Nullable`1 filters, String clientVersionStamp, ExecutionContext context, String& serverVersionStamp, DeletedMetadataCollection& deletedMetadata)

We can see the RetrieveMetadataChanges Operation being invoked – we can then see the Error happening several calls up.

The point that jumped out to me was that the last real operation was Dynamics trying to retrieve the MaxDepthOfNestedFilters from the Deployment Settings Table at the SQL Level.

This appears to be trying to retrieve this Setting and then erroring when the Object returned is not as expected.

This Setting in the Deployment Settings Table was not an area I was immediately familiar with – but from working with Dynamics over the years, am familiar with the general Deployment Settings Table and so know this exists in the MSCRM_CONFIG SQL Database behind any Deployment of Dynamics. (shared between all the Organisations hosted by that Deployment)

So our next step is to run a SQL Query on the Table and take a look first hand:

SELECT TOP 1000 [Id]
  FROM [MSCRM_CONFIG].[dbo].[DeploymentProperties]
  WHERE ColumnName LIKE '%DepthOfNestedFilters'

This returns the following:


Now – is this setting right or wrong?  Is difficult to say.

But if we compare this Setting to a known working environment of Dynamics, we can compare and potentially see what the problem is.

NOTE: You may see here that the Stack Trace reported this setting as MaxDepthOfNestedFilters but the actual setting is called MetadataQueryMaxDepthOfNestedFilters – such is the way between how Code Settings might be reported in an Error Log vs the Actual Names, so some reading between the lines is usually required.

The MetadataQueryMaxDepthOfNestedFilters Setting for a build of Dynamics 2016 where the RetrieveMetadataChangesRequest Operation to the Metadata Service works correctly:


The same Setting in the build of Dynamics 2016 where the RetrieveMetadataChangesRequest Operation failed with the above error:


We can sort of see what is going on here.

Our working build of Dynamics is using an Integer Value of 25 for this setting, but our broken deployment has a ‘false’ boolean value.

This is likely meaning that the code in Dynamics is reading this setting and then assuming this is coming back as an Integer – but our environment is reading back as a Boolean as that is indicated at the SQL Level.

(code wise, the fact that a FALSE Boolean is represented by a 0 is likely none the wiser, as the code will be reading from the ‘BitColumn’, casting into a Boolean, and then returning the Boolean up to the Business Logic layer – where the Business Logic layer assumes incorrectly the Boolean Object is an Integer, and then fails with the error)

That’s our problem, now how do we fix it?

For errors this deep in the Dynamics sub-systems following an upgrade or other big system change we are unfortunately left with SQL Hacking.

This sounds scary but is infact running a Manual SQL Script to change the value of the Deployment Setting from our current broken value to the value we think it should be based on our working Environment.

As the SQL Databases here are managed by the Microsoft Platform Layer for Dynamics, this is Unsupported and a form of Hacking the Database to fix the issue. (particularly as we are essentially guessing that this is the source of the issue, we cannot prove it by going through Dynamics with a Debugger to be sure)

As such, we should consider this option carefully before implementing:

  • Are we in a safe DEV or TEST Environment where disruption is not an issue.
  • Do we have a Rollback Backup available should the ‘hack’ break CRM
  • We have a precise idea of what the SQL Script we are running is aiming for.

Once we feel safe in these points, we can make our change.

In my case, this was running the following SQL Update Script to set the Deployment Property to the same values as the working Development Environment:

UPDATE [MSCRM_CONFIG].[dbo].[DeploymentProperties] SET [IntColumn]=25,[BitColumn]=NULL WHERE ColumnName = 'MetadataQueryMaxDepthOfNestedFilters'


With this done – does it fix our problem?

Usually with any changes to the Deployment Properties Table, we will need an IISRESET to refresh the Dynamics Web Application, so we need to run this first. (as most of the Properties read from the MSCRM_CONFIG Database will be cached for better performance)

We can then refresh our SiteMap Editing Page and see if the problem still appears

NOTE: and well, check that Dynamics still works at all, as any change like this runs the risk.


And… we’re back!

This then fixes the problem and gets our Test & Train Environment back on track after the upgrade to Dynamics 2016.

In my experience, problems post upgrade do fall into this camp of a SQL DB Setting being missing or incorrect and so this trouble shooting process can be applied to other similar problems – just unfortunately the SQL Table and Root Cause will be different each time.

Hope that might help anyone who has the same or similar problem with Dynamics in the future.

If you do have a hard to discern problem with Dynamics following an Upgrade or Hotfix, then please don’t hesitate to get in touch at – as based from a variety of Dynamics Upgrades that we have done in recent years, there is a good chance we may have seen your problem before.


All good now – the SDK is back to behaving as expected

Share this Article

Search Articles

Filter Articles

CRM Tech Projects

Prefer to go old-school?

Write to us using the below addresses.

Head Office
CRM Consultancy
61 Oxford Street
M1 6EQ

London Office
CRM Consultancy London
Grosvenor Avenue

Content © CRM Consultancy.