Dynamics 365 Portal: Self-service Diagnostics with the Portal Checker

Posted on May 8, 2019 by Nicholas Hayduk

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.

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.

For the webfile thing, performance hit comes during client side rendering of the page. Basically when u add a webfile to a page, it will get added in the html body of the page and will be loaded as soon as the page is hit. So if u will have large number of webfiles on home, it means that your home page will try to load everything.
It affects performance in two ways
a) first by increasing critical request chain length https://developers.google.com/web/tools/lighthouse/audits/critical-request-chains?utm_source=lighthouse&utm_medium=unknown
b) Second by bringing in render blocking elements like js or CSS (which should be loaded asynchronously wherever possible

About The Blog

Nicholas Hayduk is a licensed Professional Engineer, and the owner of Engineered Code Consulting Inc, a Regina, SK, Canada-based firm that specializes in helping companies solve business challenges with web-based solutions.

Engineered Code builds on a variety of different platforms, but some of our favorites include Microsoft Dynamics® 365/CRM, Adobe® Business Catalyst and WordPress.

Contact

Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.