The error message the server {3D14228D-FBE1-11D0-995D-00C04FD919C1} did not register with DCOM within the required timeout has started appearing in my IIS 5.0 server's event logs. Before the message started appearing, the server was working; now, it can't deliver content. What's causing this problem, and how can I fix it?

The error message tells you that the object's globally unique identifier (GUID), which is the number enclosed in the curly brackets ({}), and that Distributed COM (DCOM) is causing the problem. For this error message to make sense, you have to understand COM and its relationship to IIS—a difficult topic to teach IIS administrators, who aren't interested in programming technology until an error message like this one appears in their event logs and the Web server is down. Suddenly, COM gets very interesting!

Let's start with the GUID. If you're trying to hunt down information about a GUID, the first place to check is the registry. However, in this case, the GUID is special, and you won't find it in a typical search. This GUID is assigned to an entry associated with the Service Control Manager (SCM—i.e., services.exe), whose registry information resides in the HKEY_LOCAL_MACHINE\SECURITY subkey. By default, administrators don't have access to this registry subkey. Even if the Administrators' group has Full Control permission on the subkey, the information isn't readily apparent. You must drill down to the HKEY_LOCAL_MACHINE\SECURITY\Policy\Secret registry subkey and look for the name SCM: {3d14228D-fbe1-11d0-995d00c04fd919c1}.

The SCM launches services for IIS and is involved in many internal operations. If you examine the COM+ applications in the Microsoft Management Console (MMC) Components Services snap-in, you'll find the connection. From the Component Services snap-in, expand the Computer, My Computer, COM+ Applications node. Then, right-click IIS Out-of-Process Pooled Applications and Select Properties. Click the General tab, which Figure 1 shows.

Notice that the application ID (i.e., the GUID) is the same as that reported in the event logs. Thus, you know that your system is having trouble launching an instance of dllhost.exe in which it can load applications set to run in the Medium (Pooled) application-protection mode. (For more information about application-protection modes, see "Determining the Process in Which an Application Is Running," March 2002, InstantDoc ID 23815.)

Often, other event-log error messages accompany this DCOM problem. In particular, you might find an entry such as the one that Figure 2 shows.

One key diagnostic test you can perform is to run your application in Low (In Process) application-protection mode and see whether the new setting works. If your application runs, you know that your system is unable to create an instance of dllhost.exe in which to place applications marked for Medium protection. If the application fails to run in Medium application-protection mode, it will probably also fail in High (Isolated) application-protection mode.

All processes (and dllhost.exe is a process) must run in the context of a user account. Inetinfo.exe runs under the System account. Dllhost.exe runs under the IWAM_servername account. Consequently, IIS must know the password for the IWAM_servername account, which resides in three places:

• the LM/W3SVC/WAMUserPass IIS metabase key
• the Component Services snap-in
• the local SAM or Active Directory (AD)

If a password in any one of these locations fails to agree with the passwords in the other locations, you'll see error messages similar to the one in the above question.

Now that you know that the problem lies with the IWAM_servername password, you can fix it. To do so, follow these steps:

1. Stop IIS by typing

iisreset /stop

at the command line.

2. In the MMC Local Users and Groups snap-in or the MMC Active Directory Users and Computers snap-in, change the IWAM_servername account's password to a known value.



3. At the command line, type

cscript.exe :
  \inetpub\adminscripts  adsutil.vbs set w3svc/
wamuserpass ""

where newpassword is the password you entered in Step 2.

4. At the command line, type

cscript.exe :
  \inetpub\adminscripts
    run synciwam.vbs -v

to configure the IWAM_servername account with the new password.

5. Open the DCOM Configuration Tool (dcomcnfg.exe). Click the Default Security tab, then click Edit under Default Launch Permissions. Make sure the IWAM user listed has Allow Launch permission.



6. Restart IIS by typing

iisreset /start

at the command line.

In addition to the IWAM password becoming out of sync, two other problems can cause the error message in the above question to appear. First, registry ACLs that don't allow access to required registry keys can result in the error message. If you use Sysinternals' Regmon tool, you can see a list of the registry keys that a server has accessed. If, when you launch your Web application, you see any entries showing Access Denied, you've probably found the problem. Second, changing the IWAM_servername account's group membership (e.g., making the IWAM_servername account a member of a restricted group) can cause the error message.