Portal development has been quiet from Microsoft for the last couple of months so its great to see a new release from the Microsoft portals team. The new release, 220.127.116.115 is now available and rolling out to environments. If you have had the “Early Upgrade” option in your administrative interface then you may have seen this release a little earlier. There are some major fixes within this release as well as new features. The new features disabling custom errors, diagnostic logging and plugin errors will make portal developers lives a lot easier allowing them to see the detailed error messages when a portal encounters an issue themselves rather than having to file a support request. This should really help to improve the development process and time when debugging issues.
First let’s look at how you can know if you have the new version of the portal as well as how you can access the administrative actions to configure custom errors. To check your portal version you can navigate to the services about endpoint
/_services/about. Full portal address would look like:
https://exampleportalname.microsoftcrmportals.com/_services/about. From here you should see regardless of if you are logged into the portal or not the portal version.
If you have the version
8.4.x.x then you will have the fixes and new features in this release. The next item to check is that your administrative console for the portal also has its update. You can do this by navigating to the Dynamics Administration Center, going to Applications and then selecting Manage on your portal add-on. Within the portal administrative management, select Portal Actions on the left navigation. If you have the updated administrative interface you should see new tiles for Disable Custom errors and Enable diagnostic logging.
The 3 new features, Custom Errors, Diagnostic Logging and Plugin Errors, provide a self-service way to now get error and debugging details from the portal. This is hugely helpful to have these as self-service functions as the time to get error details is dramatically cut. The Disable Custom errors will take the We’re Sorry “friendly” error message and change it to the full ASP.NET error details. See the following example when we don’t have an ASPX page for the defined page template.
Custom Errors Enabled:
Custom Errors Disabled:
For your developer portals it would be suggested to just disable custom errors at all times so that developers can immediately see the debug information and correct the issue. For test and production environments so that the direct error message is not revealed you can use the diagnostic logging feature and have all the error details written to an Azure Storage Blob while showing the end user the “friendly” We’re sorry… message.
To enable diagnostic logging you will first need an Azure subscription setup and create a storage account. You can follow the Microsoft Docs quick start guide for specific directions on how to create a storage account.
Once you have your storage account, in the Azure Management Portal, navigate in your storage account to Access Keys, and copy the connection string.
Now from the portal administrative management, in Portal Actions, select, Enable diagnostic logging. Within the dialog paste in your Azure Storage Account connection string, and select the time period to keep logs for, if you do pick Always be aware that your storage account will continuously grow in size and that cost will be past on to you.
Once you have configured the logging, go create some traffic on your site, or reproduce an error then navigate in the Azure Portal to the storage account, select Blobs, Containers. Within Blobs there should now be a container called
telemetry-logs, this is your portals diagnostic logs within this container.
Navigating into the container will show you usually 2 sites. This is because your site has a replicate within another Azure data center for performance and redundancy.
Within each site you will then have folders of the year/month/day/hour (all in GMT) and then finally the actual log file itself as a CSV.
You can download these CSV files by selecting them then selecting download. Within the file you will find various rows for each request and if there are error details such as a stack trace then they would be available from the message column. Below is an example of the same error shown in the custom errors of a ASPX page not found.
Having the diagnostic logs of previous events will help the portal development team go back and investigate errors that are reported from testing or live use and get insight into the issues directly from the logs.
Both of these features once enabled can also be turned off. The Portal Actions tiles will update to the disable or re-configuration once either feature is enabled.
Finally Plugin Errors is a simple site setting
Site/EnableCustomPluginError which takes a boolean (true or false) value. This will allow your plugin exceptions to now be shown in the portal, but not the full stack trace. You can use this for debugging more easily or actually providing a more targeted error message to end users if you do have custom business logic that the portal also needs to follow and direct the user on the boundaries or parameters.
For the full change log of fixes available in this release please checkout the Microsoft Support article for 18.104.22.1685.
You can also view the full documentation on the new features for error logging on the Microsoft Docs site. If you aren’t seeing your portal upgraded to 8.4.x.x then you might need to wait for the roll-out to be available in your region and server, this process is usually staggered to help mitigate issues or major problems in the release.