IIS 7.5 Issues

Steve Ellwood
3 min readAug 17, 2020

--

This is a strange one. I have an IIS 7.5 server that has been working for years. All of a sudden, it started returning a 404 on all sites. Obviously this was something that wasn’t a minor issue that could be resolved by the usual app pool recycle. As it happened it wasn’t resolved by a Site restart nor a server reboot.

While I was troubleshooting this I came across a couple of things that I hadn’t known about IIS, hence this blog.

As you can see from the message above, one of the first things I tried was a static html website but this gave the same error, this confirmed the issue was IIS wide on this box.

Applicationhost.config

If you admin IIS you will know about this file, it normally sits in Windows/System32/inetsrv/config and it holds some of the server config. What I hadn’t realised was that for IIS 7.5 (and possibly higher), that changes to this file are stored in a history folder which normally lives in C:\inetpub alongside the wwwroot and other folders.

In my case the folders contents looked like this

Each of these contains Applicationhost.config and other files and so in combination with a diff application it’s a very useful backup. Unfortunately for me this didn’t resolve my issue. What you do need to bear in mind is that it only keeps a fixed number of folders so if you’re making a lot of changes its easy to lose history that’s too old.

Unrecognized element: ‘providerOption’

While looking through the server logs I spotted the error Unrecognized element: ‘providerOption’ repeatedly showing. This led me to a Serverfault page which seemed to precisely fit with my issue. As a result I added the file FX_schema.patch.xml in my schema folder,C:\Windows\System32\inetsrv\config\schema with the following contents

<!--

IIS 7.0 and IIS 7.5 contain incorrect system.codedom sections in their FX_schema.xml files.
This version was taken from IIS 8.5 and contains the correct validations for the default web.config
in the CLR 4.0 folder. This file is only required on Windows Vista, 7, Server 2008 and Server 2008 R2.

-->
<configSchema>
<sectionSchema name="system.codedom">
<element name="compilers">
<collection addElement="compiler" removeElement="remove" clearElement="clear">
<attribute name="language" type="string" isCombinedKey="true" />
<attribute name="extension" type="string" isCombinedKey="true" />
<attribute name="type" type="string" />
<attribute name="warningLevel" type="int" />
<attribute name="compilerOptions" type="string" />
<collection addElement="providerOption" >
<attribute name="name" type="string" isCombinedKey="true" />
<attribute name="value" type="string" isCombinedKey="true" />
</collection>
</collection>
</element>
</sectionSchema>
</configSchema>

Unfortunately for me this didn’t resolve the issue.

Rewrites

In my particular case the issue turned out to be caused by a rewrite rule. Someone suggested I look at them but as I haven’t used them for some time I didn’t initially look in the correct place. After trying to look at the rewrite rules for my static html site and getting an error. I eventually realised that there are global rewrite rules and that’s where the issue turned out to be, everything on the server was being redirected by a single rule. Disabling that rule turned everything back on.

I’ve since discovered that there is a configuration audit available which would have saved me a lot of time.

--

--

Steve Ellwood
Steve Ellwood

Written by Steve Ellwood

Senior Integrations Officer at Doncaster Council Any views expressed are entirely my own.

No responses yet