We have been using Microsoft Azure for a number of years to host this website, our company website, and countless customer websites. As DNN Platform has grown, we have recently encountered a few errors that have impacted our installations & upgrades that might be worth considering if you are attempting an upgrade of a DNN Platform or EVOQ installation on Windows Azure.
When working within an Azure App Service your application is limited to a request timeout of 230 Seconds, regardless of any value that you try to re-configure within your web.config file. Given that we trigger installation & upgrade of DNN using a web request, this can create havoc on our installations.
When an installation times out, the actual behavior will be hard to tell. Depending on how far into the installation the site gets, DNN may be able to restart where it left off, in other situations, it can be something where you need to start back at square one.
But! I've Never Had a Problem
Well, you aren't the only one. We have been hosting DNN in Azure and other cloud environments for years. This issue has only cropped up since the incorporation of the Persona Bar edit interface into DNN Platform, which started with version 9.0.0; for EVOQ it started with version 8.0.0 due to its earlier inclusion of the Persona Bar.
This appears to be the root cause because if you remove the Persona Bar extensions (there are many) from an installation or upgrade you will not encounter any issues, and the performance will be great. This is a behavior that is being investigated and will be improved in a later version as soon as practical.
Configurations Known to Have Issues
The exact configurations that will have errors can vary based on the size of the site, the version of the upgrade, and other external factors. However, it is known that the use of an S1 App Service or S0 Azure SQL Database is an almost guaranteed recipe for disaster.
Mitigating The Risk
Although a big issue, the solution is straightforward. One of the joys of using a cloud environment such as Azure is that with a few clicks you can scale-up your resources. It seems that scaling an App Service to an S2 or P1V2 and scaling the database to an S1 or greater provides enough resources to allow the installation or upgrade to complete successfully.
From a cost management perspective, the additional expense is negligible as you can scale it up, do the upgrade, and scale it back and pay for less than 1 hour of resource utilization at the higher tier. This is much cheaper than the alternative of not being able to complete the upgrade successfully.
Over time the installation experience will continue to be improved, but for now, a simple preventative scaling up can improve the experience when installing or upgrading DNN/EVOQ.