Re: IWAM out of sync (DCOM error) 10004

From: Karl Levinson [x y] mvp (levinson_k@despammed.com)
Date: 04/17/03


From: "Karl Levinson [x y] mvp" <levinson_k@despammed.com>
Date: Thu, 17 Apr 2003 10:06:13 -0400


I would first recommend using the ADSUTIL command to look at and set the
password that is cached in the IIS Metabase for the IWAM and IUSR accounts.
This should show you whether the password is being changed in the metabase.
Also, if you reset the IWAM or IUSR password in the metabase, then you know
the problem is there. If you reset the password on the domain account, then
you know the problem is there. Search www.iisfaq.com or
www.microsoft.com/support for ADSUTIL for the correct syntax for the ADSUTIL
command.

I would have to wonder whether the IUSR account is being used instead of
IWAM, and IIS is set to control the IUSR password? If the script being run
or the folder it is in is set to "Low" in the Application Isolation section
of the IIS MMC, then IUSR might be the account in use.

The other thing I might check is whether the domain account is being changed
somehow, e.g. whether the password is being changed, the password is
expiring, the account is locked out, etc.

Enabling failure auditing on the IIS server and domain controllers might be
helpful as well:

http://securityadmin.info/faq.htm#auditing

Last, using the free utility filemon [and maybe even regmon and process
explorer just for fun] from www.sysinternals.com might be useful as well,
only if nothing above helped.

"news.microsoft.com" <tradingjk@finning.ca> wrote in message
news:uulA3MEBDHA.2264@TK2MSFTNGP12.phx.gbl...
> EventID: 10004
>
> Our first webserver was having a continual reoccurance of DOM error 10004,
> which means the IWAM user account withing IIS's metabase was out of sync
> with the user account for the domain. We would often need to resyncronize
> the metabase with a series of script commands which would again allow our
> IIS to display ASP pages in HIGH (isolated) execution mode.
>
> To correct this problem we rebuild a new webserver, and we still are
getting
> the same errors occuring on now a weekly basis. If anyone could shed some
> light on how to prevent this error from ever occuring again it would be
> greatly appreciated.
>
> Thank you all for your time, help, and consideration through this issue.
> Jayme
>
>
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;255770
> http://support.microsoft.com/default.aspx?scid=kb;en-us;269367
> http://www.eventid.net/display.asp?eventid=10004&source=
>
>