Provisioning a Dynamics 365 Portal is usually a pretty painless experience, but every so often something goes wrong. In this post I’ll share a couple of our tricks for when the Portal installation doesn’t go quite as planned.

Guidance from Microsoft

If your having issues with provisioning, Microsoft does provide some guidance here. This is all great advice, but we have found a couple of other things that have helped as well.

Failed Installation

If your provisioning seems to take forever, it’s possible that the installation failed. To check this, go to the Dynamics 365 Admin portal, under Instances, select your instance and click the edit button beside Solutions. There you’ll see a list of solutions, and perhaps one of the Portals installation statuses will read “Failed”. You can try installing again, but it will most likely keep failing.

One possible solution to this problem is to stop your Portal instance before attempting another install. To do this, go to the Portal Admin area, (in Dynamics 365 Admin portal, go to Applications, select your Portal, and click Manage), use the Change Portal State drop down to set the state to Off, and then try installing the failed Portals solution(s) again. Remember to turn the state back to On once you’ve successfully installed the Portals solution.

Missing Website Binding

In one particular case we were provisioning a trial environment for a demo. We started a Dynamics 365 trial without issue, and then tried to install the Partner Portal. Typically the Portal instance is available in less than 15 minutes, but this time it was still in a Provisioning state after an hour. We left it overnight and, still, no luck; the Portal was stuck in the Provisioning state.

When we checked the Manage your solutions area in the Dynamics 365 Administration Center, it listed the status of the Portal solution as Failed. We used the technique above to be the Portal installed, but once we started the Portal again, it displayed Error 403 – This web app is stopped.

It turned out the missing piece was the Website Binding record.

Website Bindings are very similar in concept to site bindings in IIS.

In IIS, site bindings allow you to host multiple websites on the same server, on the same port. You use site bindings to tell IIS which site should be displayed based on the URL of the incoming request. The same goes for Dynamics 365 Portals.

You can host multiple Portals within a single Dynamics 365 instance. The Website Binding records tells the Portal what to display based on the name of the site in IIS.

A typical Website Binding record will have three fields filled in:

• Name: This is used just for descriptive purposes.
• Website: A lookup to the Website record you want to display.
• Site Name: The name of the site in IIS – typically the domain of your portal (ie portalname.microsoftcrmportals.com).

So when a request is made to the Portal application, it checks the name of the IIS site that its running under, and uses that to determine which Website to display.

In our case, there was no Website Binding record. Once we added it, our Portal was up and running.