That's by design. The <modules>
section of system.webServer essentially defines IIS itself. If you <clear />
, you won't be left with anything. In applicationHost.config, you should have something like this:
<modules>
<add name="HttpCacheModule" lockItem="true" />
<add name="DynamicCompressionModule" lockItem="true" />
<add name="StaticCompressionModule" lockItem="true" />
<add name="DefaultDocumentModule" lockItem="true" />
<add name="DirectoryListingModule" lockItem="true" />
<add name="IsapiFilterModule" lockItem="true" />
<add name="ProtocolSupportModule" lockItem="true" />
<add name="HttpRedirectionModule" lockItem="true" />
<add name="StaticFileModule" lockItem="true" />
...
Notice the lockItem properties. Because there are 1 or more lock items, will throw a lock violation.
So, you either need to specifically remove just the items that you don't want from web.config, or if you really need to clear them all and add back your own, then in applicationHost.config remove the lockItem="true" on each of those elements, and make sure to add enough of them back so that your web server will actually work.
Edit
(Appended further information from Daniel, per his request. (Scott))
Here is what I did based on what Scott said:
Opened applicationHost.config in %windir%\system32\inetsrv\config. Note that in 64 bit Windows Server 2008, you'll need to edit the file with a 64 bit editor (the native Notepad will do, but Notepad++ won't be able to find the file). See here for more information about this.
In the <system.webServer>
element, change the lockItem attribute on all modules to false.
In my web application's web.config file, was then able to do the following:
<system.webServer>
<modules>
<clear />
</modules>
</system.webServer>
Of course, as Scott points out, this means there's no web server left, so here is the minimum set of modules I needed to get my stuff running again (YMMV):
<add name="HttpRedirectionModule" lockItem="false" />
<add name="StaticFileModule" lockItem="false" />
<add name="CustomLoggingModule" lockItem="false" />
<add name="CustomErrorModule" lockItem="false" />
<add name="IsapiModule" lockItem="false" />
<add name="AnonymousAuthenticationModule" lockItem="false" />
Also, for anyone interested, here's the backstory as to why I'm doing this.
You can host an unlimited number of sites and set the bindings that work for you.
If you have a dedicated IP, which I assume you do, just make sure that the Host Header field is blank. Then it will catch all traffic for that IP.
There are 3 binding choices for each IIS binding: a) IP address, b) port, c) host header. The port is the only required binding. If you set the host header, then it will only work for that specific host header. That's why if you want to use host headers, you'll usually need 2 for every domain. One for www and one without the www. However, for an IP test, just leave it off all together.
Virtual directories were common with WinXP which it only allows 1 site. You don't need to worry about vdirs for multiple sites unless you have specific needs for vdirs, or if you want a single site and domain name with subfolders. (i.e. http://something.yourdomain.com would be a new site, while http://yourdomain.com/something would be a new folder or vdir).
Best Answer
After searching for more combinations of IIS and plus, it appears that IIS7[.5] is set up to reject URLs with a plus sign by default out of some fear of the use of that character; that symbol is still allowed in the querystring, though. The solution is to alter the requestFiltering attribute default on
<system><webServer><security><requestFiltering>
to allow doubly-encoded characters with a command line call (ultimately modifying your ASP.NET web.config):This may be a bit more dangerous than one prefers to be with their web site, but there didn't appear to be a way to be more specific than a blanket allow. The warnings were regarding the mismatching that could occur between using a plus in a URL and its typical translation as a space. It looks like the only other alternative is to stop using plus characters in your URLs at all.