Troubleshooting networking issues can be challenging particularly when dealing with intermittent issues. With the transition to CRM Online and other SAAS services, having a performant network and Internet connection becomes even more important. There are some great tools out there for diagnosing network issues including ThousandEyes, Netmon, and others. Generally these tools will give you great insight into network to network connectivity but they become challenging if you are experiencing network slowdowns in a remote site, remote user, or a specific group of users. To deal with these, you can install an application on their computer to monitor network traffic but that can be a painful process as well. Fortunately Dynamics CRM provides a special web page used to provide network statistics from an individual users machine to the CRM server.
Dynamics CRM Diagnostics Page
To access the diagnostics page of CRM, visit the following URL, substituting your hostname into the appropriate spot in the URL.
https://[My CRM Server]/tools/diagnostics/diag.aspx
After clicking the Run button, you’ll get information like the following.
While this page is great if you are an admin and understand the data, what if you are troubleshooting a users machine and connectivity that is not as computer literate? What about your call center agents that may struggle with getting you the information you need to help them with their networking diagnostics?
If the users utilize USD, there is a solution for you as an administrator that allows you to capture this diagnostics information for individual users of your choice on a periodic basis.
Bringing it into USD
In this blog, I plan to demonstrate how you can, without user intervention, capture the information from CRM Diagnostics on a periodic basis for a user, and have it uploaded to an entity in CRM for administrative review and trending. Because it is CRM data, you can also do reporting off the data, if you wish. Here is a screenshot of a record containing the output that you can achieve with this solution.
For simplicity sake, I have uploaded the files that you need to get started. To start with add the following solution to your CRM Solutions area:
Managed Version: Diagnostics_1_0_0_0_managed
Unmanaged Version: Diagnostics_1_0_0_0
NOTE: You will want to go into the solution view and add the DiagData entity to your sitemap. I intentionally left the edited sitemap out of this solution. I typically add it to the Settings area. You may alternatively access the data via the Advanced Find, if you choose.
Next, you’ll want to download the CRM SDK if you don’t already have it. In the tools folder of the SDK, there is a tool called the Configuration Migration Tool. Run that and select import. Login to your CRM instance, and when prompted for the import file, select the following file:
This will import the appropriate CRM entries to make the solution work. I will discuss the entries in more detail later.
When the user starts up USD, it will begin looking for the admin to activate the feature. This is done by adding an entry to the User Settings area of USD. You active the diagnostics by adding an entry titled, “DiagnosticsInterval” and supplying a value containing the number of minutes between each rerun of the application.
NOTE: Do not put 0 for the Value. I do not protect against someone putting 0, which would make it run repeatedly until turned off. This would most certainly affect your machine performance.
Once activated like this, and the record is saved, you must wait for the application to recognize that the setting exists. This interval is controlled by the Action Call, “NETWORK Retry User Settings”. As you can see here, mine is set to retry every 60 seconds. Make sure you set this to a reasonable value for your needs. The application will run a query for user settings every time this interval expires so if you have a large number of users, you will want to consider a longer interval to avoid impacting the network with these queries. On the other hand, if you set it for a long interval, then after you set your DiagnosticsInterval above, you may have to wait longer before you start seeing data from this user.
Once USD picks up the user settings, it can start looping on the DiagnosticsInterval. In my example above, USD will run the diagnostics every minute, capture the data, and write a CRM record containing the data. Generally a less frequent interval for this activity is fine but you can set it depending on your needs.
How it works
There is an all important hosted control that was created called, “NETWORK Diagnostics”. This hosted control is a standard web application. Notice the hosting type is set to IE Process.
VERY IMPORTANT: Because this tool relies on utilizing the same session as the users’ login to CRM, it is very important that the hosting type be set to the same value as you use for your CRM Pages within USD, otherwise the login will always fail.
In my case, I use IE Process for my CRM Page hosted controls so, I will use IE Process for my NETWORK Diagnostics hosted control setting.
Within your DesktopReady event for your Global Manager hosted control, USD will kick off the attempt to load the diagnostics page of CRM. It does this with by calling global managers StartEventTimer action, initially waiting 60 seconds before attempting to connect to the diagnostics page. This action will continuously fire the “NETWORK TimeToNavigateToDiagnostics” event at a 60 second interval. The reason we don’t try immediately is to allow the user time to authenticate properly to the CRM web pages and establish the authenticated session. If the user takes longer than this, that is ok, the application will try again later.
After the 60 seconds has expired, the “NETWORK TimeToNavigateToDiagnostics” event is fired.
This event kicks off the “NETWORK Navigate to Diagnostics” action call.
This will ultimately trigger a browserDocumentComplete event, even if the signin failed. It will then run the attached action calls.
As a subaction to the NETWORK Inject Script Modification, the “NETWORK ReadSettings” action call is executed. This action call reads the User Settings from the USD configuration. Assuming this was successful, it runs it’s subactions.
Once the values are captures off the page, USD then create an audit entry in our imported entity DiagData using the “NETWORK Create Network Audit Entry” action call.
Finally, to wrap it all up, it retries the reading of the user settings immediately to see if the next pass should be scheduled for execution.
By taking advantage of USD presence on the desktop and utilizing it’s flexible configuration system, we can add network diagnostics capture to our application without installing additional tools on the desktop. Perhaps more importantly, we can do this without user intervention and in a way that they are perhaps completely unaware that the diagnostics is occurring. The configuration above is flexible enough to capture data from specific users, perhaps those complaining that their application is slow, and at designated intervals independent of each other. This data can be viewed from the CRM web client by the admin and graphed and reported on an admin’s dashboard, if desired.