In case you haven’t been able to tell, I’ve been on a bit of a Dynamics 365 Portal performance kick these days. One tool I didn’t include in my post on where to look when things are slow was the Portal Checker, which provides a self-service way to identify potential issues with your Portal, with suggestions on how to solve them.

Portal Checker for Dynamics 365 Portal

Announced as part of the October ’18 release notes, the tool was released earlier this year, and is available via the Portal Administration Center (the same place you can restart your Portal, or change your Portal URL). Simple go to the Diagnose and resolve problems menu item to run the tool.

You can find the official Microsoft documentation here.

What Does it Check?

The full list of items it checks can be found here – I’m not going to regurgitate the documentation. However, at a high level, it covers:

• Basic sanity check to ensure that the Portal is loading without errors – possible solutions including checking that the Dynamics URL hasn’t changed, that the authentication between Dynamics and the Portal is still working, that your Dynamics instance isn’t in Administrative Mode, or that a Website Binding exists.
• Cache invalidation configuration issues like Change Tracking not being enabled at an organization level, or not enabled for specific entities.
• Performance best-practices like ensuring web page, web file and login tracking are disabled (note that these features have been deprecated, but currently are still available), ensuring the output caching is enabled for your header and footer (which I discussed in a recent post), identifying if there are a large number of web files, and identifying if there are static resources such as CSS and JavaScript that are loading asynchronously.

One item I found interesting was the recommendation to reduce the number of web files that are related to the homepage. It makes sense that having a lot of web files in general might cause performance issues (as the Portal needs to generate its sitemap when it first loads, and the more you have in the sitemap, the longer that will take). However, I didn’t realize there was a specific performance hit with having web files associated to the home page (I’m not sure why the home page is special in that it would retrieve all of the associated web files when it is loaded, but if they say so, I believe it). Thankfully, the idea of having a dummy page for holding the web files is something we’ve been doing for years, but not for performance reasons – we just don’t like to clutter up the home page with all of those children.

What’s Next

The Portal Checker is one of those things that will never be done – I expect that Microsoft will continue adding additional checks, and in fact some have already been promised as part of the April ’19 release cycle, including:

• Checking for incorrectly configured site markers
• Checking for entity permission configurations that could impact performance, and other slow running queries
• Checking for Portal solution installation and update issues

It is in everyone’s best interest that Microsoft make this tool as robust as possible – nobody loves having to call Microsoft for support, and Microsoft doesn’t love receiving support tickets for items that can be realistically resolved by a customer or their partner. So I’m excited to see what else Microsoft has up their sleeve for this tool.