I’ve spent quite some time now banging my head off the desk to figure out what was causing an issue with one of our PowerObjects solutions after we’d attempted to migrate to CRM 2016 from CRM 2013 and have finally found the cause.
Quite a few solutions in the market use custom parameters on the end of address’s to pass data which if you look at a network trace in any browser will display similar to this –
However, after you’ve migrated you may find you start seeing the ever useful generic 500 error when attempting to do lookups of any kind which I’ll show you how to fix.
Fixing the 500 error
This error is most likely caused by a feature in CRM called the ‘Parameter Filter’ which we’ll at least temporarily disable just to make sure we’re right.
Disabling the Parameter Filter
- Access the CRM Server.
- Go to start or run and type ‘regedit’.
- Navigate to ‘HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/MSCRM’.
- Right-Click the folder and select ‘New’ then ‘DWORD (32-bit) Value’
- Give it the name ‘DisableParameterFilter’ and a value of ‘1’.
Once done refresh the page and attempt the action that caused the issue, all going well it should now work.
2 thoughts on “How to Resolve 500 Internal Server Errors Caused by Custom Parameters in Dynamics CRM”
Sometimes the 500 error is indeed the appropriate status to receive. what does the key you provide actually do to the app call? It doesn’t necessarily fix the error, rather it is doing some sort of masking, however, do you know for sure what is occurring on the backend?
Good question. From what i can see by default CRM doesn’t allow solutions to pass custom parameters, this change disables that check which admittedly could mean a less secure system however as we have no control over the solution we’re using this was chosen as the best option. This seems to be backed up by this blog post by Jonathan Nachman – http://www.nachman-consulting.com/passing-extra-parameters-to-standard-crm-forms/ otherwise I’ve not found a lot of information on this setting.
I would assume (but can’t guarantee) that if this solution was under our control we could likely get around this without disabling this check.