401.1 error on Windows 2008 when you deploy a Web Site that uses Integrated Authentication

If you deploy an ASP.NET website on Windows 2008 that uses Integrated Authentication AND you are using host headers – then when you try to browse on the server itself you will be given a 401.1 error.  

This often leads users to go looking at the local access rights etc on the server as it’s as if the user just can’t read the directory.

In fact this is caused by a ‘loopback’ check that Windows 2008 (and 2003 + SP1) has in order to prevent reflection attacks on your server.

If you access the site remotely it works fine – however this can be a real pain whilst debugging!  It can also cause problems if (for example) you have a second site on the same server that exposes a service the first site requires and you are also accessing it via a FQDN.

The answer to this issue can be found here: 


In brief, the fix is:

  1. Set the

    registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:

    281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key:
  4. Right-click MSV1_0, point to New, and then click Multi-String Value.
  5. Type BackConnectionHostNames, and then press ENTER.
  6. Right-click BackConnectionHostNames, and then click Modify.
  7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then clickOK.
  8. Quit Registry Editor, and then restart the IISAdmin service.

A quick fix, that can stop hours of scratching your head!

MVC4 / ASP.NET 4.5 on Windows 2008 gives 403.14 – Forbidden

If you manually deploy and ASP.NET MVC application to a windows 2008 Server that has the .NET Framework installed but NOT the actual MVC Tools the server won’t know how to handle and route incoming requests.

There are a number of issues, depending on the version of Visual Studio and patch level you are using.

Older versions of VS simply were not putting all the required DLLs in the bin folder – specifically System.Web.Razor, System.Web.WebPages, System.Web.MVC etc.

So the quick fix (or part of the fix) is the manually add these files to the deployed application.  Later Visual Studio SPs actually addressed this issue.

The next problem is that even with these files the server still didn’t know what to do, and therefore the final piece of the puzzle is a web.config change to tell it what to do.

A lot of posts suggest adding the following under <system.webServer>

<modules runAllManagedModulesForAllRequests=”true” />

This will work, however is not really recommended as it handles ALL requests (e.g. html, css, jpg) as apposed to just the cshtml files.

Therefore a better solution is as follows:


      <remove name=”UrlRoutingModule-4.0″ />

      <add name=”UrlRoutingModule-4.0″ type=”System.Web.Routing.UrlRoutingModule” preCondition=”” />

      <!– any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. –>



This is generally considered a far better fix.

Now you just have the usual rights issues to deal with….