I'm trying to deploy web pages on IIS. When I try to browse site I got such mistake:
This configuration section cannot be used at this path. This happens
when the section is locked at a parent level. Locking is either by
default (overrideModeDefault="Deny"), or set explicitly by a location
tag with overrideMode="Deny" or the legacy allowOverride="false".
Section in my config file:
<security>
<authentication>
<basicAuthentication enabled="false" />
</authentication>
</security>
May anybody help me to "unlock" parent section (as far as I understand).
You may need to allow feature delegation.
IIS Manager -> Feature Delegation
Select "Authentication - Basic" and change it to Read/Write.
By default it is ReadOnly.
I had the same kind of problem when I tried to deploy ASP.NET pages on IIS. (To be honest don´t know if exactly the same - I am using Windows 10 now, but got same kind of message).
At first it seamed complicated to fix but found out that had a really easy solution.
I Just needed to reinstal IIS at the Control Painel - but with ASP option enabled (I enabled all of the resources for development of applications).
And at the Website (basic) configuration had to select .NET v4.5 Classic.
Error 500.19 and file execution issues and locked on IIS 8
To resolve it I had to execute in cmd:
%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/handlers
%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/modules
I have a strange problem when trying to get the application pools on the current machine. It seems that when IISExpress is installed, the Microsoft code wants to check IISExpress in addition to the full IIS. IISExpress uses separate applicationHost files per user. I'm not sure whether this call will require it to check all of those, or just those for the current user. Regardless, it's not finding the one it's looking for in the 'C:\Windows\system32\config\systemprofile\' directory. It should be going to %userprofile% or 'C:\Users\Administrator\' for the user that the application pool that this code is executing under is running as.
Does anyone perhaps know how this systemprofile directory might be coming from?
Exception:-
System.IO.DirectoryNotFoundException: Filename: \\?\C:\Windows\system32\config\systemprofile\Documents\IISExpress\config\applicationHost.config
Error: Cannot read configuration file
at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
at Microsoft.Web.Administration.ServerManager.get_ApplicationPoolsSection()
at Microsoft.Web.Administration.ServerManager.get_ApplicationPools()
at CustomCode.Classes.IIsApplicationPool.GetApplicationPool(String iisWebSitePath, String poolName)
I highly recommend to stop using the local reference to Microsoft.Web.Administration that gets shipped with IIS (even if it's in the GAC). This is because it has a very specific version number (i.e. 7.0.0.0) and this version might change in a future version of Windows and it will hurt.
Instead, checkout the nuget package: Microsoft.Web.Administration (https://www.nuget.org/packages/Microsoft.Web.Administration). This basically makes it so you can have a private deployment of your IIS dependencies.
If the application, in which you are using Microsoft.Web.Administration to check for app-pools, is running on IISExpress, it will always fallback to Microsoft.Web.Administration version 7.9.0.0 due to an assemblyredirect in the aspnet.config in the IIS express.
See C:\Program Files (x86)\IIS Express\config\templates\PersonalWebServer\aspnet.config
Here is the problem in the config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Web.Administration"
publicKeyToken="31bf3856ad364e35"
culture="neutral" />
<bindingRedirect oldVersion="7.0.0.0"
newVersion="7.9.0.0" />
<codeBase version="7.9.0.0"
href="FILE://%FalconBin%/Microsoft.Web.Administration.dll" />
</dependentAssembly>
Make sure you are running the application in either the full IIS or on the Visual Studio Development Server.
Alternativly you could try and remove the assembly redirect, but i have not tried this, and this might cause problems in other places. We must assume that the IIS Express team made the redirect for some reason (other than convenience) :-)
I already know the answer is old but
have you tried specifying a different version of the dll?
A picture is worth in thousand words:
How are you trying to get the application pools? Are you using MWH (Microsoft.Web.Administration) APIs?
Full IIS ships with Microsoft.Web.Administration.dll (version 7.0.0.0).
IIS Express ships with a different version of Microsoft.Web.Administration.dll (version 7.9.0.0).
It seems full IIS is trying to use IIS Express specific assembly. I am not sure how you ended up in this state, but you can un-install IIS Express and see if this problem still occurs.
Edit:
Why do you want to use Microsoft.Web.Administration (MWA) version 7.9.0.0 in your web application? It is shipped with IIS Express 7.5 to work with per user applicationhost.config file ONLY and this does not use/work with inbox/full IIS configuration file that is located at \windows\system32\inetsrv\config\appliationhost.config.
In your case, web application running under full IIS is running with system identity and therefore MWA 7.9.0.0 is trying to load config file from 'C:\Windows\system32\config\systemprofile' directory.
I've just recently ran into this issue. After reading quite a few posts, this was the closest one at giving me any idea as to what was going on. While I don't necessarily have a solution to the conflict between the two versions (7.0.0.0 and 7.9.0.0) when running within the VS IDE, after a few hours struggling with it, I did find a of quirky trick you can do to work around the IDE's auto-redirection.
In the example of:
Developing an application that's referencing Microsoft.Web.Administration.dll (7.0.0.0) from the inetsrv directory and attempting to do any of the following and trying to connect properly access the application pool definitions of the real IIS, not IIS Express, with not installed. When running the compiled code outside the IDE, it always works correctly regardless of how it's specified.
ServerManager sm = new ServerManager();
sm.OpenRemote("localhost");
sm.OpenRemote("MYPC"); // Presuming you local machine's name is MYPC
These all trigger VS to redirect the reference from the 7.0.0.0 DLL to the 7.9.0.0, which causes the retrieval of incorrect sites or COM exceptions to occurs.
The quirk I found was to always use the OpenRemote(), even though trying to open the local IIS and specify "localhost" or "MYPC" as either "LocalHost" or "MyPc" (i.e. any combination of mixed case so that it is not an exact case-sensitive match to "localhost" (all lower case) or the local machine name.
This quirk may not be specific to all VS versions. I'm currently using VS Professional 2017 (15.9.11).
As I stated, it does fix the redirect, but it definitely help while debugging.
I found mapping the "TeamConfig folder" locally to my development machine helped resolved this issue for me.
I've encountered an error deploying a site to a server. When trying to load the home page, or access authentication on the new site in IIS, I get the error:
Config Error: This configuration section cannot be used at this path.
This happens when the section is locked at a parent level. Locking is
either by default (overrideModeDefault="Deny"), or set explicitly by a
location tag with overrideMode="Deny" or the legacy
allowOverride="false".
More detail can be found here, in Scenario 7 matches my hex error code.
The solution given on the linked site above is to set Allow for overrideModeDefault in the section mentioned in my error, in the applicationHost.config file. In my case, under Security in system.webServer. But if I look at the applicationHost.config on my local computer, where the site is properly deployed already, that section is set to Deny.
If this solution is correct, how is my local instance running just fine with the same web.config? According to my applicationHost.config, that section should be locked, but it's not. I'd prefer to not change the applicationHost.config file, because there are many other sites running on that server. Is there another solution?
I had the same problem. Don't remember where I found it on the web, but here is what I did:
Click "Start button"
in the search box, enter "Turn windows features on or off"
in the features window, Click: "Internet Information Services"
Click: "World Wide Web Services"
Click: "Application Development Features"
Check (enable) the features. I checked all but CGI.
btw, I'm using Windows 7. Many comments over the years have certified this works all the way up to Windows 10 and Server 2019, as well.
You could also use the IIS Manager to edit those settings.
Care of this Learn IIS article:
Using the Feature Delegation from the root of IIS:
You can then control each of machine-level read/write permissions, which will otherwise give you the overrideMode="Deny" errors.
For Windows Server 2012 and IIS 8, the procedure is similar.
The Web Server (IIS) and Application Server should be installed, and you should also have the optional Web Server (IIS) Support under Application Server.
Browse to “C:\Windows\System32\inetsrv\config” (you will need administrator rights here)
Open applicationHost.config
Note: In IISExpress and Visual Studio 2015 the applicationHost.config is stored in $(solutionDir).vs\config\applicationhost.config
Find the section that showed up in the “config source” part of the error message page. For me this has typically been “modules” or “handlers”
Change the overrideModeDefault attribute to be Allow
So the whole line now looks like:
<section name="modules" allowDefinition="MachineToApplication" overrideModeDefault="Allow" />
After saving the file, the page loaded up fine in my browser.
Warning:
Editing applicationHost.config on 64-bit Windows
You need to unlock handlers. This can be done using following cmd command:
%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/handlers
Maybe another info for people that are getting this error on IIS 8, in my case was on Microsoft Server 2012 platform. I had spend couple of hours battling with other errors that bubbled up after executing appcmd. In the end I was able to fix it by removing Web Server Role and installing it again.
1. Open "Turn windows features on or off" by: WinKey+ R => "optionalfeatures" => OK
Enable those features under "Application Development Features"
Tested on Win 10 - But probably will work on other windows versions as well.
I ran these two commands from an elevated command prompt:
%windir%/system32/inetsrv/appcmd unlock config /section:anonymousAuthentication
%windir%/system32/inetsrv/appcmd unlock config /section:windowsAuthentication
As per my answer to this similar issue;
Try unlocking the relevant IIS configuration settings at server level, as follows:
Open IIS Manager
Select the server in the Connections pane
Open Configuration Editor in the main pane
In the Sections drop down, select the section to unlock, e.g. system.webServer > defaultPath
Click Unlock Attribute in the right pane
Repeat for any other settings which you need to unlock
Restart IIS (optional) - Select the server in the Conncetions pane, click Restart in the Actions pane
This Did the trick for me, for IIS 8 Windows server 2012 R2
Go to "Turn on Features"
Then go to all default setting , Next, Next, Next etc..
Then, select as shown below,
Then reset IIS (optional) but do it safer side.
This is an additional solution as its a generic problem everyone have different of problem and thus different solution. Cheers!
The best option is to Change Application Settings from the Custom Site Delegation
Open IIS and from the root select Feature Delegation and then select Application Settings and from the right sidebar select Read/Write
On Windows Server 2012 with IIS 8 I have solved this by enabling ASP.NET 4.5 feature:
and then following ken's answer.
To fix this open up the IIS Express applicationhost.config. This file is stored at C:\Users[your user name]\Documents\IISExpress\config\applicationhost.config
Update for VS2015+: config file location is $(solutionDir).vs\config\applicationhost.config
Look for the following lines
<section name="windowsAuthentication" overrideModeDefault="Deny" />
<section name="anonymousAuthentication" overrideModeDefault="Deny" />
<add name="WindowsAuthenticationModule" lockItem="true" />
<add name="AnonymousAuthenticationModule" lockItem="true" />
Change those lines to
<section name="windowsAuthentication" overrideModeDefault="Allow" />
<section name="anonymousAuthentication" overrideModeDefault="Allow" />
<add name="WindowsAuthenticationModule" lockItem="false" />
<add name="AnonymousAuthenticationModule" lockItem="false" />
Save it and refresh Asp.net Page.
In our case on IIS 8 we found the error was produced when attempting to view Authentication" for a site, when:
The server Feature Delegation marked as "Authentication - Windows" = "Read Only"
The site had a web.config that explicitly referenced windows authentication; e.g.,
Marking the site Feature Delegation "Authentication - Windows" = "Read/Write", the error went away. It appears that, with the feature marked "Read Only", the web.config is not allowed to reference it at all even to disable it, as this apparently constitutes a write.
Seems that with IIS Express and VS 2015, there's a copy of the applicationHost.config file at $(solutionDir).vs\config\applicationhost.config so you'll need to make changes there. See this link: http://digitaldrummerj.me/iis-express-windows-authentication/
Make sure these lines are changed per below:
<section name="windowsAuthentication" overrideModeDefault="Allow" />
<section name="anonymousAuthentication" overrideModeDefault="Allow" />
<add name="WindowsAuthenticationModule" lockItem="false" />
<add name="AnonymousAuthenticationModule" lockItem="false" />
In my case it was that on server was not enabled "HTTP Activation" under .NET Framework Features. So for Windows Server 2012 the solution which worked for me was:
Server Manager -> Add roles and features -> Features -> make sure that under .NET Framework of version you want to use is checked "HTTP Activation"
The Powershell way of enabling the features (Windows Server 2012 +) - trim as needed:
Install-WindowsFeature NET-Framework-Core
Install-WindowsFeature Web-Server -IncludeAllSubFeature
Install-WindowsFeature NET-Framework-Features -IncludeAllSubFeature
Install-WindowsFeature NET-Framework-45-ASPNET -IncludeAllSubFeature
Install-WindowsFeature Application-Server -IncludeAllSubFeature
Install-WindowsFeature MSMQ -IncludeAllSubFeature
Install-WindowsFeature WAS -IncludeAllSubFeature
The error says that the configuration section is locked at the parent level.
So it will not be directly 1 config file which will resolve the issue,
we need to go through the hierarchy of the config files to see the inheritance
Check the below link to go through the File hierarchy and inheritance in IIS
https://msdn.microsoft.com/en-us/library/ms178685.aspx
So you need to check for the app config settings in the below order
ApplicationHost.config in C:windows\system32\inetsrv\config. Change the overrideModeDefault attribute to be Allow.
ApplicationName.config or web.config in the applications directory
Web.config in the root directory.
Web.config in the specific website (My issue was found at this place).
Web.config of the root web (server's configuration)
machine.config of the machine (Root's web.config and machine.config can be found at - systemroot\MicrosoftNET\Framework\versionNumber\CONFIG\Machine.config)
Go carefully through all these configs in the order of 1 to 6 and you should find it.
I noticed one answer that was similar, but in my case I used the IIS Configured Editor to find the section I wanted to "unlock".
Then I copied the path and used it in my automation to unlock it prior to changing the sections I wanted to edit.
. "$($env:windir)\system32\inetsrv\appcmd" unlock config -section:system.webServer/security/authentication/windowsAuthentication
. "$($env:windir)\system32\inetsrv\appcmd" unlock config -section:system.webServer/security/authentication/anonymousAuthentication
I needed to change the SSL settings on a subfolder when i got this nice message. In my case following action helped me out.
Opened C:\Windows\System32\inetsrv\config\applicationHost.config
And changed the value from overrideModeDefault="Deny" to "Allow"
<sectionGroup name="system.webServer">
...
<sectionGroup name="security">
<section name="access" overrideModeDefault="Allow" />
</sectionGroup>
In my case, I got this error because I was operating on the wrong configuration file.
I was doing this:
Configuration config = serverManager.GetWebConfiguration(websiteName);
ConfigurationSection serverRuntimeSection = config.GetSection("system.webServer/serverRuntime");
serverRuntimeSection["alternateHostName"] = hostname;
instead of the correct code:
Configuration config = serverManager.GetApplicationHostConfiguration();
ConfigurationSection serverRuntimeSection = configApp.GetSection("system.webServer/serverRuntime", websiteName);
serverRuntimeSection["alternateHostName"] = hostname;
in other words, I was trying to operate on the website's web.config instead of the global file C:\Windows\System32\inetsrv\config\applicationHost.config, which has a section (or can have a section) for the website. The setting I was trying to change exists only in the applicationHost.config file.
In my case, it was something else.
When I loaded the solution in a new version of Visual Studio, VS apparently created a new project-specific applicationhost.config file:
MySolutionDir\.vs\config\applicationhost.config
It started using the settings from the new config, instead of my already customized global IIS Express settings.
(\Users\%USER%\Documents\IISExpress\config\applicationhost.config)
In my case this was the setting that needed to be set. Of course it could be something else for you:
<section name="ipSecurity" overrideModeDefault="Allow" />
Received this same issue after installing IIS 7 on Vista Home Premium. To correct error I changed the following values located in the applicationHost.config file located in Windows\system32\inetsrv.
Change all of the following values located in section -->
<div mce_keep="true"><section name="handlers" overrideModeDefault="Deny" /> change this value from "Deny" to "Allow"</div>
<div mce_keep="true"><section name="modules" allowDefinition="MachineToApplication" overrideModeDefault="Deny" /> change this value from "Deny" to "Allow"</div>
Can You try this:
Go to application path where you're getting deny error, right click
Properties->Security tab
In that, change the permissions and check the checkbox read and write. Then it will work without any error hopefully.
For Windows Server 2008 and IIS 7, the procedure is similar.
please refer to this:
http://msdn.microsoft.com/en-us/library/vstudio/bb763178(v=vs.100).aspx
in add role service, u will see "Application Development Features"
Check (enable) the features. I checked all.
In my case I was getting this error when attempting to update the authentication settings in IIS also in addition to browsing. I was able to remove this error by removing the authentication setting from the web.config itself. Removing a problematic configuration section may be less invasive and preferable in some cases than changing the server roles and features too much:
Section Removed:
<security>
<authentication>
<windowsAuthentication enabled="true" />
</authentication>
</security>
I had the similar issue, but I used the following powershell script which helped me to achieve above steps in on button click.
#Install IIS
Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Asp-Net45, Web-Mgmt-Console, Web-Scripting-Tools, NET-WCF-HTTP-Activation45, Web-Windows-Auth
the list of features can be added or removed based on the requirement.
I had an issue where I was putting in the override = "Allow" values (mentioned here already)......but on a x64 bit system.......my 32 notepad++ was phantom saving them. Switching to Notepad (which is a 64bit application on a x64 bit O/S) allowed me to save the settings.
See :
http://dpotter.net/technical/2009/11/editing-applicationhostconfig-on-64-bit-windows/
The relevant text:
One of the problems I’m running down required that I view and possibly edit applicationHost.config. This file is located at %SystemRoot%\System32\inetsrv\config. Seems simple enough. I was able to find it from the command line easily, but when I went to load it in my favorite editor (Notepad++) I got a file not found error. Turns out that the System32 folder is redirected for 32-bit applications to SysWOW64. There appears to be no way to view the System32 folder using a 32-bit app. Go figure.
Fortunately, 64-bit versions of Windows ship with a 64-bit version of Notepad. As much as I dislike it, at least it works.
I had the same issue.
Resolved it by enabling Application Server feature. Restarted iis
after that.
This worked for me
Also in IIS 8 you can solve this problem by changing the server to IIS Express. Goto debug->Properties
In the Web select the server as IIS Express from the dropdown and then rebuild the solution
To make a change at Application Level (Web.Config):
Please remove the Trust Level from the web.config:
Actually I was getting this error when I was trying to host my Website on the Hosting Server where I don't have control on their Server. Removing the above line from my Application web.config solved my issue.
I have IIS 7.5 on Windows 7 x64 and IIS 7.0 on Windows 2008 SP2 x86. In both cases, all the IIS 6 Compatibility features have been installed.
In IIS Manager, I have created a virtual directory named TestAccess with the physical path
c:\inetpub\wwwroot\TestAccess
I am trying to read the AccessFlags properties using VB.NET code like this:
Dim de As New DirectoryEntry("IIS://localhost/W3SVC/1/Root/TestAccess")
Console.WriteLine(de.Properties("AccessRead").Item(0))
Console.WriteLine(de.Properties("AccessWrite").Item(0))
Console.WriteLine(de.Properties("AccessExecute").Item(0))
Console.WriteLine(de.Properties("AccessSource").Item(0))
Console.WriteLine(de.Properties("AccessScript").Item(0))
Unfortunately, this code appears to grab the (inherited) information from
c:\Windows\System32\inetsrv\config\applicationHost.config
but if I go into IIS Manager, select the virtual directory, select Handler Mappings, click Edit Feature Permissions and make any changes, the actual changes are written to
c:\inetpub\wwwroot\TestAccess\web.config
If not DirectoryServices, what instrumentation code should I use to get a combined view of the applicationHost.config and the specific directory's web.config files so I can read the effective values of those properties? I would prefer something that works with both IIS 6.0 and 7.x.
As you're aware the System.DirectoryServices bits wrap the IIS6.0 compatibility layer. But the compatibility layer simply provides a mapping to features that were supported in IIS6 only.
IIS6 had no real knowledge of ASP.NET other that it being a script mapping to one or two ISAPI filters (and a minor update to the IIS MMC to permit switching en-mass the script maps from one version of ASP.NET to another).
IIS6 stores much of its configuration in the metabase so the API's are designed to manipulate the metabase store. The IIS6 metabase is ignorant of ASP.NET and web.config, again ASP.NET is just a script map.
There were never any settings to control IIS6 in a site's web.config file. IIS 6 is blind to this file and so the compatibility layer is also blind and doesn't take into account additional settings that might be configured in the <system.webServer> section of a site's web.config file.
The IIS6 compatibility layer emulates the metabase by modifying equivalent settings in applicationHost.config only.
IIS7 changes the game and settings in web.config files (under the <system.webServer> section are now assimilated into the overall runtime configuration of a site when it starts.
So the bottom line is if you want an aggregated view of an IIS7 site's configuration you'll need to use the new managed API's Microsoft.Web.Administration and Microsoft.Web.Management. You can also use the appcmd.exe command line configuration tool as well.
Using these tools you can specify where you want to read or modify settings e.g. at the Application Host level or at the local site level.
It should be noted that many settings are always assumed to be inherited unless overridden by a configuration file at a more specific location (e.g. site or subdirectory).
The IIS7 MMC console tends to place changes (such as to handler mappings, mime types etc) in the site local web.config file. If you need to ensure these changes are more persistent and not at risk of being deleted then you can commit them to the applicationHost.config file, but you need to use either appcmd.exe (with the /commit:apphost switch or work with the managed API's using tools such as VB.NET, C# or PowerShell.