I recently ran into a unique issue while working on a Microsoft Dynamics CRM 2013 upgrade. Our client had a Microsoft Dynamics CRM 2011 on-premises implementation utilizing New Relic for application monitoring. Due to some criteria and requirements from our client, we determined our best course of action was an in-place upgrade. When I installed CRM 2013 it automatically upgraded my organization database, and after about four hours I had what I thought was a working CRM environment. I was able to log in using my Active Directory credentials, view dashboards, and retrieve data. Once I tried opening an entity or even creating a new one, I got a spinning wheel as shown in Figure 1.
Figure 1: Never ending loading .gif on entity form load/create.
Figure 2: Error shown in IE Developer Tools.
I began looking at the calls immediately before the error. I noticed that the $$t_9.DisplayText variable had an error message assigned to it. I looked at the contents of the error and wondered what could be causing a JSON parsing error. I looked at the string it was trying to parse and copied it into a JSON parser online and found that in fact there was an issue with the JSON. Unsure why this was happening, I decided to get a second opinion using Fiddler. Figure 3 shows the same http request as the $v_3 variable in Figure 2. Figure 4 shows the same response from the request as $v_3.responseText shown in the console in Figure 2.
Figure 3: Fiddler trace of the session causing our issue.
Figure 4: Text view of the response.
After looking at the request I found that the issue is the response is clearly JSON even though the request is marked as “text/html” content type. If you try to view the response in JSON the window is blank because it’s unable to parse the response text. Confident there was an issue in the response, I found a JSON parser that would show me where in the JSON the error was. Figure 5 shows the issue with the JSON was from the lack of an escape character from the script tag injected by New Relic.
Figure 5: Parsed JSON response.
I reached out to their support team and we discussed the best way to handle this scenario. Since the content type was incorrect it was going to be challenging for their developers to fix it, and frankly my project’s timeline pushed us to a different solution. One of their support team members directed me toward an answer that would allow me to continue using their product without making unsupported changes to CRM or waiting for a hot fix from their developers. I was able to replace the browserMonitoring node with the XML node in Figure 6 to my newrelic.config (located at C:Program FilesNew Relic.NET Agentnewrelic.config). This disables browser monitoring for requests to this path, but still allows for monitoring the rest of the requests.
Figure 6: Xml to add to the newrelic.Config.
I won’t mention how long I spent banging my head against a wall before finding this solution, but I hope this helps save you some time in the future! Feel free to post your questions and comments below, or find us on Twitter at @CrederaMSFT.
Personalize marketing campaigns and increase revenue with Microsoft Dynamics