OLE Automation Server fails with ASP
Hi,
I'm not a programmer, and my experience with COM is very limited, so
please bear with me.
Here is a summary of my environment:
Server A (development), Server B (Production)
Windows Server 2000, SP4
IIS 5.0
Third Party Application which uses a self-registering OLE Automation
server (.exe) (with Visual FoxPro)
Client A types in a URL and that request gets sent to IIS on Server B.
Part of the request includes a call
to server.CreateObject("component.oneofitsmethods"). After about 30
seconds the request will fail and I see
this error in the page source:
006~ASP 0177~Server.CreateObject~Server execution failed
The event log on Server B contains the following error (which is
generated each time this fails):
The server {D6D492F2-3880-4D4A-861D-71D8CBD01ABD} did not register with
DCOM within the required timeout.
This was working on Server B up until about 1 month ago. I've never
received this error on Server A. The asp scripts
are the same on both servers. Also, if I make the request locally
(launch browser directly on Server B), it works. If I
launch a browser from my workstation, it fails. After much
experminentation I noticed that if I change the identity for the
COM object using DCOMCNFG from "launching user"to IWAM_Computername,
the application works both locally and remotely. I also
notice the COM object in Task manager(TM) on Server B briefly, and can
see that it was launched using IWAM_Computername. When
the identity is set to "launching user", and I make the request locally
I can see the component in TM and that it was
launched with my domain account. However, the component is never
loaded in TM when I make the request remotely. The identity
is set to "launching user" on Server A, and it's never had any trouble.
Attempted Solutions: The following changes to permissions, files,
shares, settings and the like are not listed in the order
in which they were applied. Some of these changes included a restart of
IIS, a reboot of the server B, or some combination
thereof.
- Modified launch and access permissions for the component to
include
the Everyone group using DCOMCNFG
- Modified default launch and default access permissions for all
components to include the Everyone group using
DCOMCNFG
- Set the default impersonation level for all components to
Impersonate
using the DCOMCNFG utility
- Changed the launching identity from the launching user to the
interactive user for the component using the DCOMCNFG
utility
- Modified NTFS permissions on the folders associated with the
application, along with the 'Winnt\temp' folder
and each respective nested folder and file to allow full control for
the Everyone group
- Unregistered and re-registered the component
(E.g.[componentname]
/unregserver, [comname] /regserver)- Unregistered
the component. Manually deleted all related registry entries for the
existing and previous versions of the component.
Re-registered the component
- Deleted and recreated the website and virtual directory that
host the
application on Server B.
- Created a new virtual directory for the app within the admin
web site
to test the application on a different web site
- Stopped and restarted various services (Remote Procedure Call,
COM+,
Distributed Transaction Coordinator)
- Synchronized the password for the IWAM_servername account
between the
IIS Metabase and Local Groups and Users (see
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q297989&ID=Q2...
for more info)
- Confirmed that the NT_Authority\Authenticated Users and
NT_Authority\INTERACTIVE accounts had not been removed from
the Users group (see step #5
http://support.microsoft.com/default.aspx?scid=kb;en-us;309051 for more
info)
- Recreated the IIS packages (see step #6
http://support.microsoft.com/default.aspx?scid=kb;en-us;309051 for more
info)
- Confirmed that the Administrators, System, and Everyone
group/accounts had the necessary permissions to the
%windir%/registration folder. (see
http://support.microsoft.com/default.aspx?scid=kb;en-us;909444 for more
info)
- Ran the Windows System File Checker (SFC) utility
- Created a server certificate for Server B. Changed the
authentication
method from Integrated to Basic Authentication.
Loaded the main page through HTTPS.
I don't know if this is a thread issue, memory issue, or a permissions
issue.
Please help.
Rob
date: 21 Dec 2005 11:03:08 -0800
author: unknown
