A question that pop ups from time to time is the difference between restarting a Microsoft Dynamics 365 Portal, and resetting it. The concern is typically around losing any of the customizations or configurations you’ve performed if you do either of those two things. Let’s look at the difference between these two options.

Dynamics 365 Portal Architecture

For those of you familiar with Adxstudio Portals, this section will be obvious. However, since the acquisition by Microsoft, and the transformation of the Dynamics 365 Portal product to a Software-as-a-Service (SaaS) offering only, anyone who is new to Portal development may not know the architecture of the product under the hood.

It’s important to keep in mind that the Portal product started as an ISV solution that had no special access to CRM data, and fundamentally that hasn’t changed.

At a high level, the Portal product is just an ASP.NET web application (using some Web Forms technology, and some MVC technology) that uses the CRM SDK to access data from your Dynamics 365 instance (of course, in some places it is a bit more complicated than that, for example using change tracking for cache invalidation, but for this discussion you can think about it as a simple web application with a database).

When you “install a Portal”, you are:

1. Installing a number of Dynamics 365 Solutions that contain the entities required for the website code
2. Importing into those entities the default data associated with the Portal you’ve chosen to install (Customer, Employee, Community, Partner or Custom)
3. Provisioning an ASP.NET website in Azure that uses the standard CRM SDK to get Dynamics 365 data to render the Portal

Again, this is not really any different than what used to happen with Adxstudio Portals, except it was a bit more manual. We used to have to install solutions, import the data, and the spin up a server that contained the website code as provided by Adxstudio (although at one point Adxstudio made this a lot easier for us by introducing the Adxstudio Installer solution, which took care of importing the solutions and data for us).

Restarting a Portal

So let’s deal with the easy one first – Restarting a Portal. This can be achieved by going into the Portal Management area (Dynamics 365 Administration Center -> Applications -> Your Portal -> Manage), going to Portal Actions, and clicking the Restart button.

All this does is reboots the Azure Web Application that is hosting the Portal – nothing more, nothing less. So if you have a problem where the solution is typically to reboot the server (which, if we’re being honest, isn’t that most problems?), this is the button for you.

We used to use this button all the time to deal with caching issues. Not so much anymore, for two main reasons: Microsoft has mostly ironed out the caching issues, and if we do still run into one, we’ve got a button on the /_services/about page that does the job quicker.

Because all you’re doing is rebooting a server, you don’t have to worry about losing any data. Especially since this is a server that you don’t have administrative access to, so there is no way that you could’ve done something to it that wouldn’t survive a reboot.

But that doesn’t mean you should just reboot whenever you want. As mentioned, rebooting clears the cache of the website, and it takes a bit of time for the Portal to rebuild that. After a reboot, your Portal will respond slower than usual until the cache is built up again. So only reboot the portal if you really have to.

Reset Portal

This can be achieved by going into the Portal Management area, going to Portal Actions, and clicking the Reset Portal button. This action deletes the Azure Web App associated with your Portal, and frees up your Portal License. It does not uninstall any of the solutions from your Dynamics 365 instance, or touch any of the data in your Dynamics 365 instance.

If you think of a Portal as a website on a web server that uses Dynamics 365 as the database, resetting a portal deletes the web server, but doesn’t touch the database. And since Microsoft makes it easy for you to redeploy the web server with the exact same website code, pointed at the exact same database, with just a few clicks, resetting a Portal isn’t as drastic as it may sound. That doesn’t mean you should do it just for fun – but you shouldn’t be worried about losing all of your work if you click that button.

What you can lose is any configuration you’ve done in the Portal Management area. So, the rule of thumb is: if you configured it in Dynamics, it will still be there; if you configured it the Portal Management area, assume it will be gone.

A couple things to note:

• After a reset, if you go to either the Manage your solutions area for your instance, or the Applications area in the Dynamics 365 Administration Center, it will still appear as if your Portal exists. However, if you click the Manage button, you’ll get the option to provision another Portal.
• After a reset, you can choose to install a different Portal into the same Dynamics 365 instance. This is helpful if you need features (and solutions) from both the Partner Portal and the Community Portal within the same Portal, for example. If you choose a type of Portal that already exists in your Dynamics 365 instance, it will use that one. (As a side note, I’m not really sure what Microsoft uses to determine the type of Portal already installed. Even if you change the name of the Website entity, it still seems to know what type it is.)