The processes for creating an Evoq Content installation on Azure or moving an existing Evoq install to Azure are almost identical to the processes for DNN Platform, found here:
- Creating a DNN Installation on Windows Azure Websites
- Moving a DNN Install to Microsoft Azure Websites
Please note the following recommendations for Evoq on Azure:
Hosts and bindings
Azure Applications will provide you with an interface where you can set up custom domains in a similar way to IIS bindings. However, before being able to add a custom domain to the list, you need to make sure that the CNAME or A Record is pointing to the Azure instance, since Azure needs to validate the DNS details.
The process above will have to be repeated for each new binding/domain you want to add to your Application. Once the custom domains are added to Azure and also added as a DNN Alias for your sites, you should be able to browse your websites.
A couple of things to note when comparing Platform to Evoq in the cloud is that Evoq supports webfarms and has the File Crawler task to index PDF and Office files. These two features are highlighted because they require custom implementation in order to fully work in the cloud which is part of our OnDemand environment.
File Crawler requires an external service to deep crawl files, since Azure does not allow one to install iFilters in App Services, and without those, DNN is unable to deep index PDF or Office files.
Webfarms require the Azure Web Request Adapter (attached), used for synchronization between servers.
- Install the attached file like any other module by going to Settings > Extensions > Install Extension.
- Confirm your application is running with ARR Affinity enabled. This setting is found in Azure portal, and is usually turned ON by default. If this setting is disabled, then it means that your application is running in stateless mode, and synchronization of cache requests will not work.
- Once the application is installed and the ARR Affinity setting is enabled, go to Settings > Servers > Server Settings > Web Servers and select the DotNetNuke.Azure.WebRequestAdapter.ServerWebRequestAdapter, DotNetNuke.Azure.WebRequestAdapter adapter.
Evoq is also a licensed product, and it requires a valid Cloud license in order to be set up as an App Service since regular On Premise licenses will generate errors.
Note on App Services
In case you want to use a different application/website to serve each different Portal, then you would need to have several App Services which would load the site from within the same File Server. This is a more complex implementation, and DNN Support recommends reaching out to Azure support to discuss that matter.
The current setup for some instances is to make use of the scaling feature, which will only use one instance of the Application Service by default and then, based on demand, might spawn new instances. This way, you can host all of your Portals under the same App Service and have more than one instance serving all those Portals.
Content author: Manuel Gonzales