Setting up Evoq on Microsoft Azure


The processes for creating an Evoq Content installation on an Azure App Service or moving an existing Evoq install to Azure are almost identical to the processes for the DNN Platform. This article details the considerations you need to take for a DNN installation in 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.

Evoq-specific features

A couple of things to note when comparing Platform to Evoq in the cloud is that Evoq supports web farms 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

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.

Refer to the "Guide to installing DNN on Azure" at the bottom of this article for more information on how to set up iFilters on Azure.

Web farms

Web farms require the Azure Web Request Adapter (attached), used for synchronization between servers.

Setup guide:

  1. Install the attached file like any other module by going to Settings > Extensions > Install Extension.
  2. Confirm your application is running with ARR Affinity enabled. This setting is found in the 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.
  3. 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. 

An error that you may encounter in the DNN logs by not having the Azure Web Request Adapter installed and enabled is:

[ERROR] DotNetNuke.Services.Exceptions.Exceptions - System.InvalidCastException: Unable to cast object of type 'System.Net.FileWebRequest' to type 'System.Net.HttpWebRequest'.
at Evoq.PersonaBar.Pages.Services.ThumbnailsController.GetImageProxy(String url, String callBack)
at lambda_method(Closure , Object , Object[] )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>cDisplayClass10.<GetExecutor>b9(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Tracing.ITraceWriterExtensions.<TraceBeginEndAsyncCore>d__18`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---


License requirements

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 license invalidation issues. Each webhead requires one license.


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.

Please have a look at these additional articles on how to install DNN in Azure:




Please sign in to leave a comment.