How to Redirect from HTTP to HTTPS with URL Rewrite

I ran into an issue with trying to trick IIS into redirecting using the method that I described in my previous blog post HTTP to HTTPS Redirect in IIS7. I tried to get my rewrite configured manually using the out of the box HTTP Redirect in IIS, but was not having much luck.

I did not have all day, so after looking around for a bit, I found a GUI that works with the HTTP Redirect module to make creating the redirect easier. This demonstration will be using Microsoft URL Rewrite Module 2.0 for IIS 7 (x64) with the update Update for URL Rewrite Module 2.0 (KB2749660) (x64). You will need to be an Administrator on the machine where you install the module. There are not any parameters to set during the installation, they are both Next-Next-Finish installations. However, the Update runs a repair installation module, which is still just an N-N-F install. You also have the option to use the Web Platform Installer to install the URL Rewrite module.
If you do not stop IIS before installing, a server reboot will be required.
After installation is complete, you should see the new module added to the sites in IIS

Objective

Our goal is going to take a standard HTTP request for http://sp2010.contoso.com and redirect it to https://sp2010.contoso.com.

Let's Get Started
Please remember that this is a GUI for writing information into your web.config file. It is always best to make a copy of your web.config file before making any changes (GUI based or manually).

To get started, double click on the URL Rewrite module, and select Add Rule(s)... 

which will open a window to select the type of rule template to use.

Start by naming your rule...  Be descriptive as you never know what else you might add at a later date... Then update the Match URL section to match the image below.

If you press the Test pattern... button, and enter a URL such as http://sp2010.contoso.com/sites/sales, take notice of the Capture groups, as you will see the Back Reference used in an upcoming setting. The important take away is that the values of the Back References are for the exact URL that you entered, meaning that the entire URL is ready for the next step in the Redirect.

After closing out the Test Pattern window, in the Conditions section, click the Add... button to create a condition for the redirect rule and set the parameters as seen in the image below.

The Test Pattern for this condition will always fail as it does not test the URI scheme (HTTP or HTTPS).

There are not any changes or additions required for the Server Variables section.

In the Action section, set the parameters based off the image below.

When you are done entering the parameters, click the Apply link and then click the Back to Rules link.

If you have more questions about URL Rewrite and how it works, the Online Help link is very useful.

After pressing Apply, and Back, your URL Rewrite rule should look something like this:

Let's Clean Things Up

You now have the ability to redirect, but have you set your bindings in IIS? And if you are using SharePoint, have you set your Alternate Access Mappings? Don't forget that you will also need an SSL Certificate (preferably a SAN certificate) so that you can create your port 443 binding. Remember that out of the box, IIS 7 will only allow one (1) port 443 binding per server. Please read my other post on how to host more than one URL with port 443 bindings on the same IP address (coming soon).

Troubleshooting

There are a couple of things that you need to keep in mind when using a redirect. 

• You will still need to have the port 80 binding enabled.
• Under the site's SSL Settings, the Require SSL check box should NOT be selected.

Behind the Scenes

The URL Rewrite module is a nice tool that keeps you physically out of your web.config file. As a second reminder, URL Rewrite is a GUI for writing information into your web.config file. It is always best to make a copy of your web.config file before making any changes (GUI based or manually). 

After you hit the Apply link, this is what has been added to the IIS site's web.config file:

If you wish to add the redirect manually, copy/paste below to your web.config file (after backing it up first).

</handlers>
  <rewrite>
    <rules>
      <rule name="HTTP to HTTPS Redirect" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
          <add input="{HTTPS}" pattern="off" />
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Found" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

Update 10/20/2013: Added the web.config information for copy/paste
Update 01/05/2015: Added the link to reference information to download via Web Platform Installer

SharePoint, IIS, 503 errors and GPOs

One of the great things about my job is that I get to spend a bunch of time solving puzzles and fixing peoples' problems. I get to install SQL Server and SharePoint in existing, well established Federal environments. Incase you are unaware, in a segregated, secured environment, such as a Federal Agency, the left hand does not always talk to the right hand. The DNS team works apart from the Exchange Team, who works apart from the AD team, who is isolated from Network Ops team, who works independently from the firewall team, and so forth. Getting things accomplished in such an arena, can be challenging, and usually involves a vertical assent and decent approach, meaning I talk to my counterpart, they talk to their boss, who talks to, for example the AD Team's boss, and then my service accounts get created.
Scenario
I was working with a group out of Alaska and Seattle, WA, to get a SharePoint 2010 Enterprise environment with SQL Server 2008R2 up and running after the group finished a domain migration.
SQL Issues
As with any SharePoint Farm installation, I installed SQL first. Everything seemed to have installed correctly, however after reboot, the SQL Server instance and the SQL Agent instance would not fire up, as seen in Figure 1.

Figure 1: Showing the stopped SQL Server and SQL Agent accounts.
In the process of troubleshooting, I opened up the service instance for the SQL Server Service and verified that the password was correct. As seen in Figure 2, after entering the account password, I was greeted with a message.

Figure 2: Shows that after entering the account password, that the account has been granted the Log On As A Service right.
This pointed me in the right direction for the first problem in this environment. The service accounts that were created in Active Directory (AD) had a GPO rule that new accounts could not Log On As A Service. The new accounts were put into a new Security Group, ran a gpupdate /force (http://technet.microsoft.com/en-us/library/bb490983.aspx), rebooted the server and SQL was now able to be rebooted successfully and have the service instances come up running!
SharePoint Issues
Unfortunately, placing all the service accounts into the new Security Group did not stop all the issues within the Farm. SharePoint installed correctly, and Central Administration(CA) provisioned and started correctly, however, after rebooting the server, I would receive a 503 error when trying to get to CA. Typically you would receive a 503 error when the Application Pool Account for your site has been stopped. After manually starting the account and clicking on the CA link, I would get a 503 error and my Application Pool Accounts would be stopped again, as seen in Figure 3.

Figure 3: After browsing through the IIS sites, the Application Pools would stop.
Which brought up the following in the error logs:
Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          6/28/2013 7:40:21 AM
Event ID:      5021
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      
Description:
The identity of application pool SharePoint Central Administration v4 is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request.  If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.
Event Xml: (removed)
Pretty nice to actually get a message that means something for once. But which account needs the Batch Login Rights? This is Federal Environment, I just cannot ask for all of my accounts to be put into a different GPO. After reading this article on IIS 6 http://technet.microsoft.com/en-us/library/cc179801.aspx and this article that has the same issue,

http://talesfromitside.wordpress.com/2011/12/06/log-on-as-a-batch-job-permissions-removed/

, I was a little bit closer. Finally I read this KB article from Microsoft that really solved the problem:

http://support.microsoft.com/kb/981949 (see Figure 4)

Figure 4: Shows the default permissions and user rights for IIS 7.0, IIS 7.5, and IIS 8.0
So, after having the security policy modified to allow the IIS_IUSRS to Log On As A Batch Job, we ran a gpupdate /force, rebooted the server and the IIS Application Pool was able to stay up and running after trying to access Central Administration.

Update 12/29/2014
Recently, while working with a customer, I ran into interesting issue with my content service account (eg: spContent). I was able to provision my farm, create all of my service accounts, and create my Web Application and Site Collection. I was able to open Central Administration, however, when I tried to browse to the Site Collection URL, I would receive an error.

It was a bit odd that everything else worked, but the web page would not render.
Now, I was in an environment known for having issues with GPO and had a bunch of devices in the background doing all kinds of packet inspection, so I was a bit hesitant as to what could be the error.
Luckily I did find a very helpful blog post: SharePoint 2013: An exception occurred when trying to establish endpoint for context: Could not load file or assembly...
This article basically asks to make sure that Impersonate a client at authentication has local rights.

Summary

Make sure your Service Accounts can Log On As A Service and that your IIS_IUSRS are allowed to Log On As A Batch Job. You might need to have the Impersonate a client at authentication has local rights as well.
Make sure that you do an iisreset after you push your GPO updates (or reboot the server(s)).

Http to Https Redirect in IIS7

To keep with the subject of error pages, I thought it would be good to touch on how to redirect end users and force them to use port 443 instead of port 80.  There is a very simple way to accomplish this in IIS7, using the same Error Pages Feature that we used in the last posting on creating a SharePoint Custom Login Error (401) Page.
1) Go to IIS and select your web site.

2) If you have not already done so, edit the site bindings to add the port 443
3) Open the Error Pages Feature under the IIS area.  In the right column, click Add.

4) Add a Status Code of 403.4 and select Respond with a 302 redirect.  Put in YOUR https address!

5) Open the SSL Settings in the IIS area for your site.

6) Click the Require SSL check box, and click Apply in the upper right Actions column.

SharePoint Custom Login Error (401) Page

When dealing with lots of people logging into your SharePoint site, you will spend a lot of time answering phone calls from people with login errors. A nice and easy way to preemptively help deal with login failures is to use a custom error page.

1) Go to your IIS and look up where the custom errors are located for the site.

2) Look at the path location for the location of the error files.

3) Go to the file location,, you will want to edit the 401.htm file.

4) The last step is to modify the web.config for your SharePoint site.  You will need to add (modify) the system.webserver.
Download code here

To add custom error pages in different languages, just add the pages to the appropriate local language folder.  You can find the local language folder information here...  http://msdn.microsoft.com/en-us/library/bb266177.aspx

IIS7 and Multiple IP Addresses That Won't Bind

Recently one of my clients asked to put a Tomcat Server on the same box as their SharePoint 2007 WFE. 

1) Add the IP address (Local Area Connections --> Properties --> Advanced --> IP Address Add...)

2) Stop IIS  (cmd --> iisreset -stop)

3) Set binding information in Tomcat
4) Set binding information in IIS

          (IIS Manager --> Right Click Site --> Edit Bindings --> Edit Port Binding --> Select IP from drop down) 

5) By default, IIS7 binds to ALL port 80 IPs, so we have to disable this behavior for the IP in IIS 

      (cmd --> netsh http add iplisten ipaddress=xxx.xxx.xxx.xxx)

6) Restart IIS (cmd -->  iisreset)


Warning!!!
If you have created Custom Web Services, running the Net Shell command will bind your Custom Web Services to the IP address and cause them to stop working.  This will give you an error of:  Not Able To Connect To Remote Server.