Won Yoo's Blog : Configuration

Workaround: Running ASP.NET 1.1 on Vista SP2/WS08 SP2

wonyoo — Thu, 18 Jun 2009 22:01:00 GMT

Many of you have probably read the article on how to install ASP.NET 1.1 on IIS7 on Vista and WS08 (The article can be found at http://learn.iis.net/page.aspx/472/how-to-install-aspnet-11-with-iis7-on-vista-and-windows-2008/).

While above works great on Vista/Vista SP1/WS08 RTM, if you try to run ASP.NET 1.1 on Vista SP2/WS08 SP2, you may have experienced the following error if you are on a 64-bit OS:

There was an error while performing this operation.

Details:

Filename:
\\?\C:\Windows\system32\inetsrv\config\applicationHost.config
Error:

Here is the problem.

In order to support .NET 4.0 Framework, IIS team has released a hotfix (http://support.microsoft.com/kb/958854) which is also included in SP2. At the root of the problem is that this hotfix allows the IIS runtime to read the correct version of .NET Framework configuration based on the .NET Framework version that is associated with the application pool. For example:

.NET Framework version 1.1: the config location is %windir%\Microsoft.NET\Framework\v1.1.4322\CONFIG
.NET Framework version 2.0: the config location is %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG
.NET Framework version 4.0: the config location is %windir%\Microsoft.NET\Framework\v4.0.nnnnn\CONFIG

The problem is that when the runtime tries to load the corresponding configuration, it doesn't take the bitness of the application pool into the consideration. As you know, ASP.NET 1.1 is only supported on 32-bit. So if you have a 64-bit OS, in order to run ASP.NET 1.1, you have to enable 32-bit applications in the application pool. So, with the QFE/SP2 on 64-bit OS (and only on 64-bit OS), the runtime is incorrectly looking for the 1.1 version of the configuration under Framework64, which does not exist.

Workaround:

Create the Framework64 directory for 1.1
md \windows\microsoft.net\framework64\v1.1.4322\config\
Copy the 32bit config to 64bit config location created in step 1.
copy \windows\microsoft.net\framework\v1.1.4322\config\machine.config \windows\microsoft.net\framework64\v1.1.4322\config\

In the spirit of full disclosure, without the hotfix/SP2, the behavior was still incorrect on Vista/Vista SP1/WS08 RTM in that the runtime was alreays reading the 2.0 configuration although the application pool is configured to use .NET 1.1. (Because the runtime was always reading the 2.0 config regardless of the .NET Framework version that is associated with the application pool. This was the bug that hotfix/SP2 tried to address as part of supporting .NET 4.0, but it didn't quite consider the fact that ASP.NET 1.1 is only available in 32-bit.) This bug in Vista/Vista SP1/WS08 RTM may not have been too obvious to those running ASP.NET 1.1 on 64-bit Vista/Vista SP1/WS08 RTM unless you have significant/specific settings/differences between 1.1 and 2.0 configurations.

Shared configuration and password expiration.

wonyoo — Mon, 26 Jan 2009 22:15:00 GMT

Most of you have probably heard of shared configuration. It is a simple and convenient way to centralize IIS configuration among multiple IIS instances. (More info on shared configuration can be found here.)

A step in setting up shared configuration is to provide a user credential that can be used to access the shared configuration. Now, what happens when the password changes for the user? Naturally, the IIS instances that are using the shared configuration will no longer be able to access the shared configuration on a file share and, therefore, they won't work properly. So, in order to fix this problem, you may be thinking that all you need to do is to open the IIS Manager and just update the password. You may be right, except that you have a chicken and an egg problem.

Although IIS Manager launches successfully, when you try to connect to the server, you will see the following error:

You guessed it. The IIS Manager is unable to read the configuration because it no longer has the access to the file share where the configuration file is located, hence the chicken and the egg problem.

Before we discuss how you can workaround this problem, we will first need to understand how the shared configuration works. Before the IIS config system loads applicationHost.config, it relies on redirection.config to see if shared configuration is enabled or not. Below is an example of redirection.config (which is located at %windir%\system32\inetsrv\config\):

<configuration>

    <configSections>
        <section name="configurationRedirection" />
    </configSections>

    <configProtectedData>
        <providers>
            <add name="IISRsaProvider" type="" description="Uses RsaCryptoServiceProvider to encrypt and decrypt" keyContainerName="iisConfigurationKey" cspProviderName="" useMachineContainer="true" useOAEP="false" />
        </providers>
    </configProtectedData>

    <configurationRedirection enabled="true" path="\\server\folder" userName="removed" password="[removed]" />

</configuration>

The IIS config system looks at the redirection.config file first.

If configurationRedirection is enabled, then it will try to read the applicationHost.config file from the path using the userName and password.

If configurationRedirection is disabled, it will try to read the applicationHost.config from the local file system. So, in order to temporarily get around the chicken and the egg problem, open the redirection.config in the notepad and set enabled="false". Doing so will effectively take this IIS instance out of shared configuration. More importantly, it will now allow you to launch the IIS manager and connect to the server successfully.

After launching the IIS manager, navigate to Shared Configuration page and enable shared configuration. Once enabled, update the password fields with the new password and Apply:

Now repeat the same steps in remaining IIS instances that are using the shared configuration.

Setting up Shared configuration on IIS 7.0

wonyoo — Tue, 13 Jan 2009 02:59:00 GMT

Problem: When IIS 7.0 server is configured to work in shared configuration mode then configuration files are stored on a file share. This configuration is recommended for setting up web farms. But in case file share goes offline, the whole set up fails and web servers stop responding. Moreover when the file share comes up again, IIS server is not able to detect it gives following error message:

HTTP Error 500.19 - internal server errorThe requested page cannot be accessed because the related configuration data for the page is invalid.

We have to do an IISreset to start the web servers again after this.

Resolution: Follow the below given steps to set up shared configuration with offline files (client side caching) enabled.

Step 1: On the Web server, in Control Panel, open Offline Files.

Step 2: In the Offline Files dialog box, click Enable Offline Files. Do not reboot the machine yet.

Step 3: Ensure that the cache is set to read only by running the following command:REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v ReadOnlyCache /t REG_DWORD /d 1 /f

Step 4: Reboot the Web server.

Step 5: Browse to the file share folder from web server. Right click and select “Always Available Offline”.

Step 6: Go to control panel -- > Offline Files. Select Schedule option.

Step 7: Schedule offline file sync after every 1 day or as per the requirement. This could be in minutes too. Even without setting up any scheduler, the moment I change anything in applicationhost.config file, it is reflected on the web server.

Now the web server works fine even if the file share is offline and there is no need of IISReset now.

Many thanks to Amol Mehrotra for helping with the content.

ApplicationHost.config file getting corrupted when OneCare or Forefront is running?

wonyoo — Mon, 24 Mar 2008 23:48:00 GMT

We have seen some reported cases when applicationHost.config file is getting corrupted when OneCare or Forefront is running on the same machine. By "corruption" I mean the XML is malformed is you may get an error:

Error: Configuration file is not well-formed XML.

Without going into the technical details, it has to do with how OneCare/Forefront scans the files and the timing between when OneCare/Forefront scans the files and when an application, such as IIS, performs a file operation. The OneCare/Forefront team is currently working on a fix to address this problem, but for now, the following workaround is provided:

Create the following key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MpFilter\Parameters” .
Add a DWORD value “ScanOnCleanup” and set it to 0.
Restart OneCare/Forefront service.

Above registry key setting tells OneCare/Forefront services not to scan the files when they are being written or modified. This is not a security compromise because:

Not having above registry key value does not mean that OneCare/Forefront prevents an infected file from being saved. Rather, it is a notification of the infected file. So without the registry key value, you may be notified sooner, but the infected file is still written. This is necessary because anti-virus programs, including OneCare/Forefront, allow the file to be written in its entirety before it can be inspected for virus.
All files are still scanned when they are tried to be opened. So if the file is infected, OneCare/Forefront would prevent the file from being opened and the system is still safe.

I will post a follow up when the fix from OneCare/Forefront becomes available. Meanwhile, above workaround is your best alternative.

(Note that in Forefront, there is a way to exclude path to be scanned. Configuring Forefront not to scan applicationHost.config is not a viable workaround. This is because despite this setting, Forefront still scans the file but it omits in reporting. There is a reason for this and this behavior is by design.)

Section level encryption of ASP.NET settings in IIS 7

wonyoo — Thu, 10 Jan 2008 06:31:00 GMT

As you know, ASP.NET supports section level encryption for protecting its configuration. It supports both RSA, which is default, and DPAPI out of the box and it also provides a way to use a custom protection provider. (Click here for more information on using RSA. Click here for DPAPI.) The most commonly encrypted sections are appSettings, connectionStrings, identity and sesstionState.

While the initial encryption is done using the aspnet_regiis.exe, once the sections are encrypted, IIS 6 inetmgr allowed the users to view the encrypted settings in clear text (ie. the UI decrypted the sections) and it also allowed the users to edit the values and saved the settings encrypted (ie. the UI re-encrypted the sections).

Unfortunately, in IIS 7, the inetmgr does not know how to handle encrypted sections for ASP.NET settings. It is important to note that the section level encryption is still supported and it is as secure as it was in IIS 6. It is just that the manageability of the encrypted sections is not supported in the IIS 7 inetmgr. If the connection string section is encrypted in configuration, the user will see the following error when clicking on the connection string icon in IIS 7 inetmgr:

There was an error while performing this operation.
Details:
Filename: <path to configuration file>
Line number: <line number>
Error: Configuration section encryption is not supported

This was a consious design decision in IIS 7.

I still recommend the users to encrypt and secure the ASP.NET settings that they find sensitive. However, in order to view the values and/or update them, the users will first have to manually decrypt the sections using aspnet_regiis.exe, edit the file, and again re-encrypt the sections using aspnet_regiis.exe. The steps to encrypt and decrypt the sections using RSA and DPAPI are provided in the links above.