Mike Volodarsky's blog

Formerly the core server PM for IIS 7.0 and ASP.NET, now I run LeanSentry.
UPDATES: New troubleshooting guide released! Fix IIS website hangs →

The next step

It's been one week since I left Microsoft, and what a week its been! I dont remember the last time I was on so little sleep :)  I'll be making some changes to www.mvolo.com and posting more info about the new stuff shortly.

I have to say though that my focus is still almost completely on IIS 7.0 and related Windows Server 2008 tech.  In the past week, I've been doing more learning and writing code than I have in a long time, which has been extremely exciting.  I've been working on and talking about the extensibility architecture of IIS 7.0 for such a long time, that using it to solve real problems becomes a very rewarding experience.  Interestingly, while the web server provides a lot of new features out of the box, the potential offered by its customization and extensibility is even greater.

In the meantime, I wanted to post about a topic I have to deal with all the time (and likely so do you): Connecting to IIS 7.0 configuration remotely using Microsoft.Web.Administration or several other configuration management APIs.  Check it out, and grab the tools that I use to make doing this easier.




Connecting to IIS 7.0 configuration remotely with Microsoft.Web.Administration

As you know, IIS 7.0 provides a number of ways to manage configuration other then MWA, including IIS Configuration COM objects for script, IIS Configuration COM objects from .NET or native clients, WMI, the IIS Manager tool (inetmgr.exe), and AppCmd. While all of these can be used to manage an IIS 7.0 box remotely (AppCmd with extra help of a remote shell environment or WMI), MWA remains one of the most common options because its so easily accessible from .NET.

Microsoft.Web.Administration uses the IIS 7.0 configuration objects under the covers, just like all of the other management options (except for IIS Manager, which uses the IIS Management service, and WMI, which uses the WMI DCOM remoting infrastructure).

Incidentally, this also means that Microsoft.Web.Administration can be used to remotely manage a Server Core installation.

This is despite the fact that currently Server Core does not support the .NET Framework - and is possible because MWA uses the IIS configuration COM objects as the underlying provider, which is native. So, while you cannot use MWA to manage a Server Core server locally, you can do it by running the .NET program remotely on a normal Windows Server 2008 or Windows Vista SP1 machine. However, you cannot use IIS Manager to manage a Server Core server remotely, because IIS Manager uses the IIS Management Service for remote management over HTTPS, which currently is not available on Server Core.

This brings us to the core of the issue: MWA uses the IIS configuration COM objects to manage the server, and therefore in the remote case requires DCOM access to the remote machine.

By default, DCOM access is blocked by Windows Firewall. Therefore, when you try to connect to a Windows Server 2008 or Windows Vista SP1 computer using Microsoft.Web.Administration, or another mechanism that also uses the IIS Configuration COM objects (everything except for WMI and IIS Manager), you will receive the RPC_S_SERVER_UNAVAILABLE error.

To enable DCOM access, you'll normally need to open TCP/135 for the DCOM port mapper, and the entire dynamic port range between 1024 and 65535 used by DCOM. Obviously, this is not something you want to do, especially not on a production server.

Luckily, DCOM provides a way to specify a fixed port for each COM+ package, which allows to enable remote configuration access by opening two ports:

  1. TCP 135 - DCOM port mapper
  2. A single TCP port for the IIS configuration COM objects

You can read more about this approach in Using Distributed COM with Firewalls.


Go here to skip the reading, and grab the batch file to configure remote IIS config, and the RemoteConfigTest.exe tool to test IIS config connectivity.


Here are the 3 steps to do it:


1) Configure the IIS configuration objects to use a fixed DCOM port

- Run dcomcnfg.exe
- Expand Component ServicesComputersMy ComputerDCOM Config, select the “ahadmin” COM+ package
- Select PropertiesEndpoints tab, click Add:
- Select “Connection-oriented TCP”
- Set fixed port


DCOM configuration

Setting the endpoint configuration:

Setting a fixed DCOM endpoint

For command line usage, or if you are on server core, here is the equivalent:

> REG ADD HKEY_LOCAL_MACHINESOFTWAREClassesAppID{9fa5c497-f46d-447f-8011-05d03d7d7ddc} /v EndPoints /d "ncacn_ip_tcp,0,<PORT>" /t REG_MULTI_SZ /f

(where <PORT> is the TCP port between 1024 and 65535 you'd like to dedicate to IIS config)


2) Open the required ports in the firewall

- Open TCP port 135 for the DCOM port mapper
- Open the selected TCP port

I additionally secure the opened ports as follows:

  1. Private profile only
  2. Set scope to “Local subnet” only, or specific computer addresses on the network
  3. Restrict ports to the process/services that provide DCOM access to the IIS config COM objects 

For command line usage, or if you are on server core, here are the commands:

> netsh advfirewall firewall add rule name="RPC Mapper" dir=in action=allow profile=private remoteip=localsubnet protocol=tcp localport=135 service=RpcSs

> netsh advfirewall firewall add rule name="AHADMIN Fixed Endpoint" dir=in action=allow profile=private remoteip=localsubnet protocol=tcp localport=<PORT> program=%windir%system32dllhost.exe

(where <PORT> is the fixed TCP port you chose in step 1)

You can also use ipsec to restrict access further.


3) Insure adequate access

You will need Administrative privileges on the remote machine in order to use IIS Configuration objects. This means that you either need to be logged in as/impersonating the local Administrator account with a syncronized password, or a domain account that has Administrative privileges on the remote server.

Due to UAC, you will not be able to use a local user other then BUILTINAdministrator, even if that user is a member of the Administrators group on the remote machine (that is, unless you disable UAC).

There are additional things you can do by modifying activation ACLs on the COM+ package or DCOM security settings, but these are out of scope of this post.

4) Reboot 

I've seen cases where a reboot is required to pick up the DCOM changes.  Possibly because RpcSs caches the DCOM activation settings and therefore requires a reboot (its not possible to  restart RpcSs).

If you are unable to connect remotely after going through the steps above, be sure to reboot and try again.

Tools you can use: 

1) Batch file that will perform steps #1 and #2 for you:

> iisremoteconfig.bat 5000 - to setup IIS config access on port 5000

> iisremoteconfig.bat 0 - to remove the IIS config access

(NOTE: A reboot may be required to activate these settings)

2) The RemoteConfigTest.exe tool that will attempt a connection and diagnose the connectivity issues if any:

> RemoteConfigTest.exe

This tool will alert you if you have a firewall connectivity problem, forgot to register the IIS configuration COM objects, or do not have sufficient permissions to use them.