Approval URL in Nintex 2010 on SharePoint 2010 Multi Web Farm environment

The Background

We were developing the Workflows around SharePoint 2010 with some custom forms for the workflow running on a list with Nintex 2010, a 3rd party workflow designing/developing tool for developing the workflow.

The Issue

We developed the system on a standalone SharePoint installation and UAT was also done on the same, but when it came to deploying it live, we had a web farm environment set up there. We had one application server, 2 web servers and 1 database server. All this went on fine until we setup the live environment and tested the workflow. The notification email for the task consisted of a workflow variable i.e. a builtin feature of Nintex saying “Approval URL” It contained the link to the URL that will show the Task. On clicking on it, one of two tasks were showing the right URL but the last one was giving a URL that was the server URL and it did not show the Alternate Access Mapping set in the Central Admin of SharePoint 2010.

For e.g. the URL should have been http://abc/pages/edittask.aspx?id=123, instead of which it was creating a link like http://webserver1:1111/pages/edittask.aspx?id=123 which was showing the web server name instead of the alternate URL set through Central Admin.

The Solution

I did some research on this issue and found out that this happens in Nintex in cases where we have a server farm. The only useful help that I could find on this issue on Nintex forums was on Nintex Connect.

As we had alternate access mapping configured on live, Nintex used the default zone to create the Approval URL for a workflow at runtime. So in order to create the link with respect to the access mapping declared in central admin, we need to configure nintex to the zone on which the URLs are to be created. Going through the NWAdmin Operations Manual, we were able to solve this problem using the configuration script provided by Nintex.

For this purpose we had to

- Run the NWAdmin.exe tool (Nintex Admin tool). It is located in the folder where Nintex is installed.

- For setting up the “Intranet” zone for the Approval URL, from the above example let us suppose we have defined the public URL for zone is “http://abc” which maps to an internal site url of “webserver1:1111”. For this purpose we need to run the script as:

nwadmin.exe -o AddZoneSetting -type WebApplication -url http://imach21:80 -zone Intranet

where parameters –type defines scope of the zone, -url is the URL for which the zone settings it to be added, -zone defines the zone which is to be used. For more details you can consult the NWAdmin Operations Manual of Nintex under the heading AddZoneSetting.

Encrypting Sections of Web.config of a SharePoint Site for Multi-Server environments

This is my first blog on technology, so sorry about me not being so much clear on things. I’m sure it will get better as I go along and share my experiences on various topics related to the technology

The Back Ground

It is always a Best Practice to encrypt sections of web.config that hold sensitive information like connectionstrings, appsettings and others. ASP.NET provides easy way to encrypt such sections of a web.config which does not need any code level changes where accessing the data of those encrypted sections.  You can find detailed articles on encrypting the sections on MSDN links below:

http://msdn.microsoft.com/en-us/library/yxw286t2.aspx

http://msdn.microsoft.com/en-us/library/ms998283.aspx

On this post, I would be discussing the encryption of the web.config that I had to do for a multi-server environment of a SharePoint 2010 project which had two web servers and one application server.

The Issue

It is relatively a simple task or configuration when it comes to encrypting the web.config sections on a single server environment where you can use the default protection providers without any hassle but when it involves more than one server, normal encryption operation have to be slightly modified to incorporate consistency of the encryption across all the servers.

The Protection provider that has to be used for a Multi-Server such as a Web Farm environment is RsaProtectedConfigurationProvider.

The Solution

Now cutting things short, for solving this dilemma all you need to do is, open the Visual Studio command prompt and do the following:

1. Create Key Container which will contain the key to be used for encrypting/decrypting the sections. This can be done using:

aspnet_regiis -pc "MyKey" -exp

Make sure that you use –exp switch, If you do not use the -exp switch which indicates that the keys are exportable, then you wouldn’t be able to export the keys later.

2. You would need to give the network service account access to key container we just created. Do this by:

aspnet_regiis -pa "MyKey" "NT AUTHORITY\NETWORK SERVICE"

3. Add the following section to the web.config specifying the Key Container and other related information that asp.net needs to know.

<configProtectedData>

      <providers>

         <add name="MyKeyProtectionProvider"             type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"

              keyContainerName="MyKey"

              useMachineContainer="true" />

      </providers>

</configProtectedData>

4. Now all you need to do is encrypt the section of web.config file, here I am encrypting the appSettings section of a website by:

aspnet_regiis -pef "appSettings" "C:\inetpub\wwwroot\wss\VirtualDirectories\MyKeyWebsite"

5. Export the key to a file that will be needed to be imported across all the web servers where the website resides. This can be done by:

aspnet_regiis -px "MyKey" C:\MyKey.xml -pri

6. Copy this file to the other web servers where you would need to replicate the change and Import the key on those web servers by:

aspnet_regiis -pi "MyKey" C:\MyKey.xml

7. Now copy the web.config on the web servers that would make use of the configuration protection technique. In my case it was on the two servers where the sites were residing. Other operations like deletion of the key container and default providers for stand-alone is available on MSDN links I provided above and also on various other blogs. 

Happy Protection!!! ;)