Recently, we deployed a large project for a multinational corporation and an interesting situation arose during the process.  The SharePoint portal for this particular client was accessible externally (outside of their corporate network).  This allowed users to access the sites worldwide without having to use a VPN to connect to the corporate network.  This is not uncommon in the SharePoint world, and we have implemented and configured a fair number of Extranet portals over the years.

This particular project was very document-centric (as are many in SharePoint), with multiple workflows for approval, updating, publishing, etc.  Because of this, the Microsoft Word client was heavily used in the application, and seamless client integration was a critical important requirement. 

 During beta testing, we discovered two strange occurrences:

1) Emails generated by the automated task creation (for document approval) had a mixture of URLs with http and https.

2) When opening a document for editing/approval, the user sometimes received an error that he/she could not approve or edit the task associated with the document.

These were both very strange, and after some extensive testing and troubleshooting by our team, we were able to isolate the problems and we determined that the root cause was due to the fact that users were accessing the SharePoint site in different ways; http and https.

Issue #1:

As I mentioned above, users do not need a VPN connection for accessing the portal, but they do need a VPN connection for many other tasks.  Ultimately, it was because of this “dual access” to SharePoint that users were seeing inconsistent behaviors.  When a user was connected via the VPN, all URLs were http.  However, when accessing the site externally, all URLs were https.  What’s important to note is that the workflows and tasks generate emails links, etc. using relative paths.  What this means is that the protocol (http or https) will be prefixed based on how the user is connected.  When a user was connected via VPN, all links were generated as http and when not on the VPN, all links were https.  When a user not on the VPN clicked on an approval link that had been generated while the submitting user was on the VPN, the document and site would be unreachable (http does not work outside of the network).

Issue #2:

In addition to the links, we noticed that when a document was opened in Microsoft Word, there were inconsistencies as to whether or not the document would allow you to edit the associated task.  Take a look at the two screenshots below.  The first is from our development server (where everything always works) and the second is from the live, production server.

Development:

Production: 

To make a long story short, we ultimately concluded that this too was caused by the mixed http and https issues, and this was further supported by a new message that we had yet to see in a SharePoint environment.

The Solution:

The solution to this can be handled in a few different ways.  One such way is by using ISA Server, which can force all http requests to be https before they are sent to SharePoint.  In our case, the client did not have ISA, so we were forced to look elsewhere for solutions.  Thankfully, with the concept of Alternate Access Mappings and IIS redirects, we were able to provide a workable solution for our client. 

There are basically four (4) high-level steps to make this happen:

1. Configure Alternate Access Mappings so SharePoint is aware of the https URL.
2. Change the port of the existing SharePoint site in IIS and require https access to the site.
3. Create a new IIS site for http—>https redirection.
4. Configure the new IIS “redirector” site to be a permanent redirection to the https site.

** Note: If you are using IIS 7, in addition to the directions regarding Permanent Redirection you should open the Error Pages icon for the redirector site, and edit the 401 error.  Select the radio button for “Respond with a 302 redirect” and enter your SSL site in the Absolute URL box.

You may be asking yourself, why this was not found until later in the process, specifically beta testing.  Since the development environment did not have SSL (http), all development was consistently performed using http.  It wasn’t until we deployed the beta version of the solution that users were able to quickly let us know the issues they were running into.  This also goes to show how important multi-stage deployment can be before the masses begin using the product.

The following article served to be a great resource in helping us find a solution to these issues and led us in the right direction.  You can find more information on each of the four steps above at OS.com.