Contents tagged with IIS7
-
You are not authorized to view this page due to invalid authentication headers.
I have been working through an authentication issue and making changes to IIS to debug the problem and then ran into the following IIS error:
HTTP Error 401.2 - Unauthorized
You are not authorized to view this page due to invalid authentication headers.
It took me a while to figure out what the problem was and in the end the cause was already listed in the “Most likely causes” section of this error page:
Most likely causes:
- No authentication protocol (including anonymous) is selected in IIS.
- Only integrated authentication is enabled, and a client browser was used that does not support integrated authentication.
- Integrated authentication is enabled and the request was sent through a proxy that changed the authentication headers before they reach the Web server.
- The Web server is not configured for anonymous access and a required authorization header was not received.
- The "configuration/system.webServer/authorization" configuration section may be explicitly denying the user access.
My issue is that I had been debugging an issue with Windows Authentication and I had disabled Anonymous Authentication and enabled Windows Authentication for this website in IIS (I know you are not supposed to have both Forms Authentication and Windows Authentication enabled at the same time... this was for a test).
When I had finished I thought I had reset everything back but I forgot to enable Anonymous Authentication. Just enabling Anonymous Authentication resolved the issue.
-
Show detailed Classic ASP error messages in IIS7 for both local and remote requests
In IIS7 you have to enable sending the detailed error message for Classic ASP. You can do this by configuring Classic ASP in IIS7:
And then setting the “Send Errors to Browser” setting to true:
Now you will get the detailed Classic ASP error message when an error occurs in your Classic ASP pages. But these will only show for local requests. Remote requests will still display the standard IIS 500 - Internal Server Error:
Not sending detailed error messages for remote requests is the default since it is a good idea for remote requests not to see the full error details (it could expose sensitive data to the Internet). But if you need to see it, such as on an internal testing server, follow these instructions to have IIS send the detailed error message for remote requests too.
In IIS go to the Error Pages:
Then on the right click on the Edit Feature Settings...
In the Edit Error Pages Settings dialog is where you choose to send for both local and remote requests. The second option button is what needs to be selected to have the detailed errors returned for both local and remote requests. The bottom option is what is on by default – where detailed error messages are only sent for local requests.
Keep in mind that it is not recommended to send detailed errors for remote requests since this could expose sensitive information to the Internet. -
The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration
After upgrading an ASP.NET application from .NET Framework 3.5 to .NET Framework 4.0 I ran into the following error message dialog when trying to view any of the modules in IIS on the server.
What happened is during the upgrade, the web.config file was automatically converted for .NET Framework 4.0. This left behind an empty system.web.extensions section:
It was an easy fix to resolve, just remove the unused system.web.extensions section.
ERROR DIALOG TEXT:
---------------------------
ASP
---------------------------
There was an error while performing this operation.
Details:
Filename: \\?\web.config
Line number: 171
Error: The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration
---------------------------
OK
--------------------------- -
VB.NET IF() Coalesce and “Expression Expected” Error
I am trying to use the equivalent of the C# “??” operator in some VB.NET code that I am working in.
This StackOverflow article for “Is there a VB.NET equivalent for C#'s ?? operator?” explains the VB.NET IF() statement syntax which is exactly what I am looking for... and I thought I was going to be done pretty quickly and could move on.
But after implementing the IF() statement in my code I started to receive this error:
Compiler Error Message: BC30201: Expression expected.
And no matter how I tried using the “IF()” statement, whenever I tried to visit the aspx page that I was working on I received the same error.
This other StackOverflow article Using VB.NET If vs. IIf in binding/rendering expression indicated that the VB.NET IF() operator was not available until VS2008 or .NET Framework 3.5. So I checked the Web Application project properties but it was targeting the .NET Framework 3.5:
So I was still not understanding what was going on, but then I noticed the version information in the detailed compiler output of the error page:
This happened to be a C# project, but with an ASPX page with inline VB.NET code (yes, it is strange to have that but that is the project I am working on). So even though the project file was targeting the .NET Framework 3.5, the ASPX page was being compiled using the .NET Framework 2.0. But why? Where does this get set? How does ASP.NET know which version of the compiler to use for the inline code?
For this I turned to the web.config. Here is the system.codedom/compilers section that was in the web.config for this project:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5" />
<providerOption name="WarnAsError" value="false" />
</compiler>
</compilers>
</system.codedom>Keep in mind that this is a C# web application project file but my aspx file has inline VB.NET code. The web.config does not have any information for how to compile for VB.NET so it defaults to .NET 2.0 (instead of 3.5 which is what I need).
So the web.config needed to include the VB.NET compiler option. Here it is with both the C# and VB.NET options (I copied the VB.NET config from a new VB.NET Web Application project file).
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5" />
<providerOption name="WarnAsError" value="false" />
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" warningLevel="4" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
<providerOption name="OptionInfer" value="true"/>
<providerOption name="WarnAsError" value="false"/>
</compiler>
</compilers>
</system.codedom>So the inline VB.NET code on my aspx page was being compiled using the .NET Framework 2.0 when it really needed to be compiled with the .NET Framework 3.5 compiler in order to take advantage of the VB.NET IF() coalesce statement. Without the VB.NET web.config compiler option, the default is to compile using the .NET Framework 2.0 and the VB.NET IF() coalesce statement does not exist (at least in the form that I want it in). FYI, there is an older IF statement in VB.NET 2.0 compiler which is why it is giving me the unusual “Expression Expected” error message – see this article for when VB.NET got the new updated version.
EDIT (2011-06-20): I had made a wrong assumption in the first version of this blog post. After a little more research and investigation I was able to figure out that the issue was in the web.config and not with the IIS App Pool. Thanks to the comment from James which forced me to look into this again.
-
MIME Type for .MP4 files is video/mp4
I almost made a mistake and put the wrong MIME Type into IIS7 for some MP4 videos that I am serving from a web server. A search for “MP4 mime type” returns two different results:
- video/mp4 (correct)
video/mpeg(not correct)
I was not so sure if there was a difference (although most results did lean toward video/mp4, there were a good number of video/mpeg recommendations out there to make me question the correct one).
To resolve the issue I tried both in IIS7 and Chrome.
For video/mp4 Chrome will give you the HTML5 video player (a very nice user experience):
For video/mpeg Chrome will launch QuickTime... blah!
I didn’t test any other browsers... this was proof enough for me that video/mp4 is the correct MIME type of .MP4 files.
-
From IIS6 maxRequestLength to IIS7 maxAllowedContentLengthFile – specifying maximum file upload size
IIS6 uses the maxRequestLength config setting under the system.web section to specify maximum file upload size with a default of 4 MB. IIS7 uses the maxAllowedContentLength config setting under the system.webServer section to specify maximum file upload size with a default of 28.6 MB. This is something to watch out for when migrating your web application from IIS6 to IIS7. Read on for more information how I found out about this new config setting for IIS7….
I have migrated several sites from IIS6 to IIS7 without much problems. One gotcha that I did get caught on is the new IIS7 config settings section (system.webServer) and those settings for specifying the maximum file size to be uploaded to the website. After migrating a certain web application from IIS6 to IIS7 everything appeared fine until a few customers began complaining about issues when uploading files to the website… in particular these were large files around 50MB.
In IIS 6.0 there is a config setting (attribute) called maxRequestLength located under the httpRuntime section in system.web that you can use to specify the maximum allowed request length (in other words the maximum uploaded file size). In IIS 6.0 the default is 4096 which is number of kilobytes allowed… so a 4MB file is the default file upload size under IIS 6.0.
A 4MB is pretty small these days so it is quite common to need to override the default and put in a different value here. For the web application that I was migrating to IIS7, we had increased the maximum file size to 200MB (and told our customers 200MB was the max upload too). This is what the httpRuntime section was set to:
<system.web>
<httpRuntime maxRequestLength="204800" executionTimeout="7200"/>So we migrated the web application to IIS7, tested some large file uploads (we tested with 20MB files… note this for later) and everything seemed great. After rolling the website out to our customers, a couple weeks post release we got a couple complaints about customers not being able to upload files. Their files were about 50MB in size.
At first this was puzzling because we clearly had the config setting in place that indicated 200MB was the new limit (or so we thought) AND files larger than 4MB were allowed (we had tested 20MB files). But we could easily reproduce the customer issue with their 50MB files failing. So what was going on?
Eventually we tracked it down to IIS7 and the new config section called system.webServer. We had known that httpHandlers in IIS7 were now to be specified in the system.webServer/handlers section but what we did not know (and did not find out until our customers ran into it) was that the maximum request length setting for IIS7 is also in a new location. In IIS7 you specify the maximum size of a file to be uploaded to the website by using the maxAllowedContentLength setting (system.webServer/security/requestFiltering/requestLimits >> maxAllowedContentLength).
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="209715200" ></requestLimits>Now why didn’t our tests with 20MB files show this? Because in IIS7 the default value for the maxAllowedContentLength setting is 30000000 and that is in bytes: 30000000 bytes = 28.6 MB. So in IIS7 the default had increased to 28 MB so we did not notice it since we were testing with only 20 MB files (and assuming the default was 4MB). In the end we got this resolved fairly quickly and it showed an issue in our testing (we really should have been testing a 200MB file… the limits of what we tell our customers).
-
Index Server and the Enable 32-Bit Applications Setting
We had a old website that made use of Microsoft Index Server and the Index Server COM objects (ixsso,Query). Everything was working fine on our Windows Server 2003 machines under IIS6. Then when we migrated to Windows Server 2008 and IIS7 our classic asp pages (which we did a straight migration over to classic asp in IIS7) could not instantiate the Index Server objects.
Simply instantiating the object would fail:
Dim objQuery
Set objQuery = Server.CreateObject("ixsso.Query")After a call to Microsoft PSS we were finally able to track down the problem to the Application Pool running in 32-bit mode. IIS7 allows you to run the application mode in 32-bit or 64-bit by configuring this setting of the application pool:
False is the default but it was overridden to true in the Application Pool where the Index Server object was being instantiated. And the Index Server dlls are 64-bit only. So while a 32-bit dll can load in a 64-bit process the reverse is not possible. There was no reason that the application pool was set to 32-bit so we switched it to 64-bit (changed the “Enable 32-bit Applications setting to false) and everything worked.
-
Windows Server 2008 IIS7 SMTP properties
In Windows Server 2003 IIS6 you were able to change SMTP properties from within Internet Information Services (IIS) Manager. In Windows Server 2008 the IIS7 Manager does not handle SMTP anymore... but you can modify it by using the old IIS6 Manager which is provided as part of the Windows Server 2008 Administrative Tools.
Under Administration Tools you will now find two different IIS Manager entries. One for IIS7 and one for IIS6. Choose the IIS6 Manager to change the SMTP properties.
The IIS6 Manager will only have an item for the SMTP Virtual Server. Right-click on the SMTP Virtual Server and select properties.
This will display the familiar SMTP Properties dialog that you are used to from Windows Server 2003. Now you will be able to change things such as the size limit of the messages, the number of messages per connection, outbound delivery delay notifications, etc.
