Question

I’m writing some code to permit users to remotely manage IIS7. Under the bonnet this adds authorisation rules to c:\windows\system32\inetsrv\config\administration.config under the following config section:

system.webServer/management/authorization/authorizationRules

I’m using the Microsoft.Web.Administration assembly and namespace with code similar to the following:

using Microsoft.Web.Management.Server;
...
ManagementAuthorization.Grant("MySiteUser, "My Web Site", false);

This code throws an exception if run in a 32 bit process, if built as 64 bit it runs fine:

System.Runtime.InteropServices.COMException was unhandled
  Message=Filename: \\?\C:\Windows\system32\inetsrv\config\administration.config
Error: The configuration section 'system.webServer/management/authorization' cannot be read because it is missing a section declaration`

However other server management tasks performed using the Microsoft.Web.Administration assembly and namespace work just fine in a 32 bit process, for example:

using Microsoft.Web.Administration;
....
int iisNumber = 60000;
using (ServerManager serverManager = new ServerManager())
{
  var site = serverManager.Sites.Where(s => s.Id == iisNumber).SingleOrDefault();
  if (site != null)
  {
    site.Stop();
  }
}

Both these assemblies appear in the GAC and are pure MSIL (even though there is a COM interop layer to talk directly to IIS7’s underlying management mechanisms).

The underlying configuration files applicationHost.config and administration.config are only visible to 64 bit editors (e.g. notepad.exe or NotePad2.exe) and I suspect that this is why my code can’t modify administration.config via the Microsoft.Web.Management

Why does the Microsoft.Web.Administration allow me to read/modify applicationHost.config in a 32 bit process but Microsoft.Web.Management can only read/modify administration.config if run in a 64 bit process?

I am unable to recompile my project to target x64 because there is a dependency on a 32bit COM library that we don’t have source for. I can build a work around which would involve making calls to an out of process 64 bit WCF app (or some such similar thing) but would prefer not to.

Answer 1

After some digging it looks like this is a bug:

This forum thread and a post by Carlos Aguilar explains all:

http://forums.iis.net/p/1157779/1956471.aspx

Now I understand the issue, what is
happening is that Cassini is a 32 bit
process and that in conjunction of a
bug in our configuration makes us try
to load the “redirected” syswow
(instead of system32) which is the
reason why we cannot find
administration.config. Running in 64
bit process alleviates the problem
cause there is no “magic” redirection
and we go to the right folder.

Any 32 bit process is going to encounter this roadhump.