How do I properly read the AccessFlags property using DirectoryServices on IIS 7.x? - iis

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.

Related

Why is w3wp.exe looking through my dotnetcore api path to find web.config?

Using IIS 7 with a deployed dotnetcore 2.1 or 3.1 web API alone in an application pool, we discovered while looking at Process Monitor on the server, the w3wp.exe workers were logging many errors where they were apparently looking for a web.config. They checked every route in the api's route. The expected behavior was that the w3wp.exe (an IIS worker) would "hand off" the request to the dotnetcore application's routing, which would find the endpoint, but instead, it appeared to be also checking for a web.config. The process monitor revealed w3wp.exe QueryOpen NAME NOT FOUND and PATH NOT FOUND errors.
I looked at a few articles and concluded it was a problem with web.config inheritance, and there must be some setting in IIS or a dotnetcore configuration that was dictating the behavior of checking each API route path as if it were a virtual directory folder system that might contain a new web.config. The benefit would be that you could have a different web.config in a sub-application, but we didn't want that benefit and we didn't want these IIS workers blowing up the logs with thousands of these errors throughout the day. We found an insanely simple solution that an IIS admin might say "duh" but will hopefully save someone out there some time.
We found the answer on an old blog.iis.net post about web.config inheritance (https://blogs.iis.net/steveschofield/control-web-config-inheritance-with-iis-7-asp-net-options). There is a configuration called allowsubdirconfig that directs the w3wp.exe worker to check subdirectories for a web.config file. Here's how you change it in IIS applicationhost.config that can be found through IIS Manager:
Go to configuration editor
Go to system.applicationHost => sites => virtual directory defaults
Set allowSubDirConfig to False
We also discovered that Microsoft recommends you use this setting for hosting dotnetcore applications on IIS
Skipping the additional file operations can significantly improve
performance of websites that have a very large set of randomly
accessed static content.
https://learn.microsoft.com/en-us/previous-versions//dn529134(v=vs.85)?redirectedfrom=MSDN
Keep in mind, if you use this setting, you'll need to come up with a solution to separate applications that use or don't use the setting.
Related issue with MVC:
ASP.NET MVC security and IIS allowSubDirConfig configuration

My iis automatically points my solution directory though it's published

I have published my IIS application to C:/inetpub/wwwroot/appDirectory and it's have different configuration in web.config file.
and in development version solution directory i have another web.config file and When i build solution my IIS start pointing to solution directory.
that's too annoying, every time i need to remove application from iis and again make application on IIS itself.
Go to properties of your web service in Visual Studio.
Navigate to Web tab
Either Change the local IIS to express or you can give a different application name so it wont replace your deployed application.

Enterprise Web Library web.config not currently compatible with Azure?

I am trying to use Enterprise Web Library with Windows Azure. It appears that the web.config file for the EWL project works fine locally, but when I deploy to Azure the application cannot initialize. After logging in and viewing the site locally on Azure, it appears there are several web.config elements EWL requires that are locked on Azure. I've had to edit the following in order to have the application initialize on Azure:
Remove <serverRuntime uploadReadAheadSize="8388608" />.
Remove everything nested inside of the modules element.
The application seems to run fine on Azure after removing these parts.
The Web.config elements you removed are important to ensure that EWL works properly: uploadReadAheadSize fixes a problem with client certificate authentication, and using <clear/> in the <modules> section makes the behavior of EWL applications consistent across different servers by keeping the same set of modules in the pipeline regardless of what IIS features are installed on the machine.
There has to be a way to unlock these config sections in an Azure web role. Assuming they are locked in the web role's applicationHost.config file, maybe you can modify this file using a startup script as described in this answer: https://stackoverflow.com/a/10140024/35349.
I am not very familiar with Enterprise Library. If William’s suggestions do not help, please check your web.config to see if you’re missing any configuration sections. On your local machine, when you install Enterprise Library, it may modify machine.config to add certain configurations. But they may not exist in the cloud. So please search your local machine.config to see if there’re any Enterprise Library specific sections, and then add them to your web.config.
Best Regards,
Ming Xu.

When installing an add-on to IIS, how can I verify the IIS WMI Provider is available?

Apparently the management piece of IIS - the IIS WMI provider - is installable separately from the IIS runtime.
I'd like to produce an installer for an add-on to IIS, and I know how to check for the existence of the IIS runtime in the WIX project. But, the installer needs to do various management things, WMI things, and for that it needs not only IIS, but the WMI Provider for IIS. Which as I said, may or may not be present.
In a WIX project, How do I check for the existence of the IIS WMI Provider, and how do I present a reasonable dialog to the user if the IIS WMI Provider is not present?
The installer already has a few MSI Custom Actions implemented in Javascript, and I can use
var iis = GetObject("winmgmts:root\WebAdministration");
...to check for the existence of the WMI Provider. It will fail (throw) if no WMI Provider is there. I suppose I could use this to set a Property, and then check that Property in a Condition early on in the Product.wxs file.
is this going to work? any other suggestions?
I suppose the better way for this is still to browse the registry for appropriate setting. Another question is it's not always easy to find the right one. :)
For instance, my installer needs IIS6 compatibility to be enabled (for IIS 7 machines), in particular, IIS 6 WMI compatibility. This setting is located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components, in a value called WMICompatibility. So, everything I should do is to author a RegistrySearch element to search for this value and check if it's 1.
In order to find the correct setting, I would search for the key all IIS parameters reside under (it might differ for each version of IIS, I'm not certain here), enable IIS WMI provider you need and see what was changed in registry. I suspect registry monitor software can help here a lot.
Yes, testing instantiation of the object via the moniker is going to work. It's a reasonable strategy, better than spelunking around in the registry. It delivers the right result, all the time. Just catch the exception that occurs if the WMI provider is not available.

How to run classic ASP scripts under IIS 5.1 (WinXP Pro) alongside .NET & CF?

I'm running into a problem setting up my development environment. I've been working on ColdFusion and .NET applications up until recently I haven't needed to touch IIS. Now, I have to set up a classic ASP application for some one-off work.
I added a virtual directory in IIS and pointed it at the actual codebase on my local machine. I then set the security to low (for ISAPI extensions, i.e. ASP) and allowed for script execution. For some reason though, if I hit any .asp page it says the page cannot be found. However, HTML and static files load up just fine.
EDIT: URLScan fix seems to have done it. Fired up the app in another browser (i.e. not IE6), and I'm getting better error reporting. Looks like we're missing some includes, but it is executing the scripts. Thanks!
You need to make sure that the "Active Server Pages" web service extension is set to an allowed status.
Check out: http://classicasp.aspfaq.com/general/why-does-iis-hang-and/or-stop-serving-asp-pages.html
Also, you should be aware that a virtual directory may affect the include file paths in the asp pages themselves. If the original asp application does not use a virtual directory, then your local copy shouldn't either.
Take a look at your URL scan settings and see if .asp is an allowed file extension
On my XP machine the relevant file is located at C:\WINDOWS\system32\inetsrv\urlscan\urlscan.ini

Resources