ReadyXRM

Summary

• By default, there is only one Portal provided per Dynamics 365 Subscription with 5 plan 1 users.
• It is possible to configure multiple “portals” across different instances within a tenant (sandbox and production) but only one of these portal configurations can be connected to one “active” portal URL at any time.
• Portal solutions and portal configuration data can be added to multiple instances (at no extra charge).
• Best practice would be to invest in extra portal instances but not always feasible.
• Switching the “active” Portal to different instances is easily done, but often misunderstood.

Microsoft Docs

There are brief steps provided here on the Microsoft Docs site.  This post expands and provides context on how to repoint a portal to a different Dynamics 365 instance.

One “free” Portal

After the acquisition of Adxstudio in 2015, Microsoft soon after released the Dynamics 365 Online Portal.  For around $500US per month, you could add a portal to your instance of Dynamics 365 Online.  In the fall of 2016, Microsoft announced that the portal add-on would be available to Dynamics 365 Online subscribers by default at no additional fees if there was at least 1 full plan 1 user license.  This later increased to having 5 plan 1 users.

Production and Sandbox Instances

While having access to a portal as part of a Dynamics 365 Online tenant is great, it leaves a gap in best practices of having separate development, test and production environments.  Currently* for Dynamics 365 tenants, there is a production and one sandbox instance as part of a subscription.  The sandbox instance is meant for development, testing, etc.  Ideally, once testing/development is complete, then the solutions are exported/imported to the production system.

For portals, included is only “one” active portal, so by default that sometimes leaves portal “development” to occur on the same environment that will effectively become the “production” environment.

“Better” practice would be to add an additional portal to the subscription that would allow two distinct environments between development and production.   “Best” practice would be to have a full distinct development, testing and production environments, both for the actual Dynamics 365 instance and for the portals.  However, at $500 per month for an extra portal, this can add extra cost for organizations building out simple portals.

Sandbox Portal Suggestion

It has been requested to Microsoft on the Ideas site to provide a “sandbox” portal as part of a subscription to be in alignment with how there are a production and sandbox Dynamics 365 instances.  At this time, no action has been taken, but feel free to vote this idea up and provide your own comments as to why this is important!

Vote Now!

*The licensing is changing.  At this time I have not fully digested the upcoming licensing changes and how they affect the portal.  Suffice to say there is a lot of confusion between PowerApps Plan 1, Dynamics “premium” features and Team Member licenses.

Review of Dynamics 365 Portal Components

If you have worked with portals you will know that a portal is comprised of 3 main components.  There are the portal solutions that are loaded on Dynamics 365 instances that contain the framework of how the portal configuration is stored.  You can freely install these portal solutions in as many instances in your tenant as you require.  There is the actual Portal configuration data, that is stored in Dynamics 365 as data.  This data represents the web pages, entity forms, content snippets, etc.  Again, this can be added to multiple tenants (or copied between tenants).  Finally, there is the actual “Portal” technology itself which is a web application that displays the portal to the outside world via a specific URL.  As per above, you only get one “Portal” included in your Dynamics 365 subscription.  

I blogged about this structure 2 years ago and essentially hasn’t changed much since then, except for the fact that the “Master Portal” that was deployed from Visual Studio is now fully managed via the Dynamics 365 Administration.

Switching Portals between Dynamics 365 Instances

One approach to building/configuring a portal is to setup solutions and configure a portal on the Dynamics 365 sandbox instance, and when you satisfied then transfer it to the production instance.  You will need to copy the portal configuration data (click here for a method using the XrmToolBox) and also repoint the Portal from the sandbox to the production instance, explained in this post.

It is also assumed that you have fully installed the portal solutions on the instance that you repointing the portal to.

In my scenario, I have installed the “custom” portal solutions on both my sandbox and production instances.  Using the XrmToolBox, I have copied the portal data from my sandbox to my production.  I have made a minor tweak to the home page to designate the difference between data coming from the sandbox and from production.

If I navigate to my portal, I can see the that the content of the home page aligns to the Dynamics 365 sandbox instance.

You will need to navigate to the Dynamics 365 Administration Center (you will need to be an Office 365 Global Administrator).  Go to Applications and locate your portal application (it will be identified by what you named it when it was first installed).  Click on “Manage”.  Note that if you have multiple portals (via subscription add-ons) you will need to select the portal you want to repoint.

The next step is to click on the “Manage Dynamics 365 Instance” link, you will see the current Dynamics 365 instance that your portal is connected to.  Click on Update Dynamics 365 Instance to change it.

The next step is to select the instance you want the portal to connect to.  You should see all the instances in your tenant.

The next step is to choose the portal configuration on the destination instance that aligns to the portal you want to connect to.  Note that if you choose a different portal or no portals are installed on that instance, the process will also install the solutions and install the basic portal data for that portal.  If the portal already exists (e.g. custom portal) it will NOT overwrite the portal solutions or data.  This is the part that some folks find unclear, and the messaging isn’t great at clarifying this, e.g. “Select Portal to be deployed” might suggest that a fresh portal will be installed over the existing one.

You will get the message after the fact that portal won’t be overwritten.  Note that the logging will need to be reconfigured if you want to shut off custom errors and diagnostic logging.

The process will kick off and take 10-15 minutes to complete.

If you refresh the page, you will get a message that the request is processing.

If you or anyone navigates to the admin center, you will see that configuration is not allowed during this process.

You may notice that you get a message with multiple website bindings.  This isn’t noted in the docs site.  All this means is that a new website binding record was created.  It is just a duplicate of what was configured earlier.

This is easily fixed by deleting the extra binding record directly in Dynamics 354 Portal Admin section.

Refresh the portal, since by default there is only one portal per instance, it will have the same URL.  Notice that my portal now points to the production system.

Summary

Ideally, for a major portal project getting a sandbox portal add-on would be the best practice to keep development and production fully separate.  However, if you just experimenting or tight on budget, this method does allow you to configure your portal in a sandbox system, test it, and then repoint it to a production system.  You would need to consider a strategy for further updates (switching back, using the “unpublished” state, etc.)

I hope you found this posting informative and maybe a better understanding of how portals work.  Hopefully, Microsoft will eventually provide a sandbox portal instance to allow better portal ALM practices.

Nick Doelman is Microsoft Business Applications MVP, Blogger, Speaker and now officially a Podcaster!  Join Nick and fellow MVPs Colin Vermander and Shawn Tabor on CRM Audio Network in a new podcast, “Refresh the Cache” dedicated to working with Dynamics 365 Portals!  Coming soon!