Portal Troubleshooting, Part One: Stale Data and Bad Requests

Issue: I am attempting to expose data from a custom entity on the portal, but changes made to any of the custom entity records are not being reflected on the portal.

Portals store the entirety of their data within Dynamics CRM / Dynamics 365, so a caching mechanism is used to ensure that information stored within web templates, web page copy, content snippets, and other records does not have to be retrieved every time a user requests access to it.  In a version 8.x or higher portal, this cache is updated only when specific messages are received through Dynamics 365’s change notification infrastructure.  Version 7.x portals are handled differently, and this architecture is described in much greater detail in Part Four of this series.

For version 8.x or higher portals, the change notification infrastructure is comprised of a system plugin inside the Dynamics 365 code that listens for all changes happening within the application.  If a change occurs on an entity enabled for "Change Tracking", a message is forwarded to an Azure Event Hub for telemetry, reporting, and functionality purposes.  By subscribing to these messages, a portal’s cache can be refreshed whenever a change is detected that would impact the portal’s contents.

To reduce the sheer number of notifications being sent to the Azure Event Hub, the "Change Tracking" option is only enabled on out-of-the-box Dynamics 365 and Portal Add-on entities.  Any custom entities that have been created within Dynamics 365 are not part of this scope unless the "Change Tracking" option is deliberately enabled on the entity within its customizations page.  If this option is unchecked, related messages will not be sent to the Event Hub, and therefore any associated data rendered on the portal will remain stale.

Note that entities that are installed as part of the portal packages (such as Content Snippets) have "Change Tracking" enabled by default, but this value can technically be unchecked/disabled after portal deployment if an administrator chooses to do so.  As such, this issue can affect both default and custom entities, but it’s more common with the latter.

Resolution: To fix this, a Dynamics 365 administrator can navigate to Settings -> Customizations -> Customize the System.  From the customizations window, the administrator can then click Entities, select the appropriate custom entity, and then enable the "Change Tracking" option toward the bottom of the page by placing a check in the checkbox.

Issue: A "Sorry, but we’re having trouble signing you in.  We received a bad request." error along with a "This application requires application permissions to another application." message appears when attempting to sign into the portal using the "Azure AD" external authentication option.

In addition to supporting local user authentication, portals can be configured such that users can sign-in via a variety of external authentication providers.  As version 8.x or higher portals are deployed within the Dynamics 365 Administration Center and are associated to the hosting Office 365 tenant, they are designed to support Azure AD authentication by default so that users within that tenant can immediately log into the portal and create a user account using their existing Office 365 credentials.

However, to support Azure AD authentication (and server-to-server authentication with Dynamics 365), an App Registration must be created within the Azure subscription associated to that Office 365 tenant with the appropriate permissions granted when the portal is provisioned, otherwise the error highlighted above will occur.  Let’s step through the provisioning process to better understand how and why the highlighted error message above occurs.

When a portal’s name, URL, language, and other variables are selected and the "Submit" button is clicked, the user is presented with a Terms of Service screen that requires them to click "Accept".  Once this is done, there are a few provisioning steps that begin taking place in the background to successfully complete the deployment process:

1. To support the externally-facing portal website itself, two redundant Web Apps are deployed in a Microsoft-managed Azure subscription (only one Web App is deployed for trials)
2. To support the chosen portal type’s features and functionality, a varying number of solutions are imported into the associated Dynamics 365 organization
3. To support Azure AD authentication, a "Microsoft CRM Portals" application is registered in the Azure subscription associated with the Office 365 tenant

While the first two steps take place without any further user action after the deployment is started, the third step requires that the user performing the deployment click "Accept" when prompted with the "Microsoft CRM Portals needs permission to…" message.  If this message is ignored or the "Cancel" button is clicked instead, the portal will still be provisioned, but the Azure AD authentication option will not function as the App Registration does not have the proper permissions configured.

Resolution: To fix this, a Global Administrator in the associated Office 365 tenant must sign into the portal using the "Azure AD" external authentication option.  At that point, they will once again be prompted with the "Microsoft CRM Portals needs permission to…" message.  By clicking "Accept" to this prompt, the App Registration permissions will be configured properly and the error message will no longer appear for other users.

Alternatively, a Global Administrator can access the Dynamics 365 Administration Center, navigate to the Applications tab, highlight the portal in question, and click the Manage button.  From the Portal Administration Center screen, the "Portal Details" tab can be selected and a "Click here to provide consent to your Dynamics 365 portals." message will appear near the Update button.

Interested in more troubleshooting tips for Dynamics 365 portals? Check out the first installment for an overview of all topics covered throughout this series.