"Failed to access IIS metabase" ??

[Guest]

I am trying to test an asp.net site using IIS. I'm getting the "Failed to
access IIS metabase". I find this mentioned plenty, but nothing works for
me. The error says that the worker process can not read the IIS Metabase. I
have 1) deleted ASPNET user, 2) run aspnet_regiis -i and then -ga
<mach>/ASPNET to reset everything. I can run meteacl.vbs and see that ASPNET
does have read access.
So, while everything seems fine, I can't run thru IIS!
If user ASPNET is OK, might the worker process be somehow configured for
some other identity? Where is that set??
Any other possibilities??
-- Thanks

 

[Juan T. Llibre]

re:
!> If user ASPNET is OK, might the worker process be somehow
!> configured for some other identity? Where is that set??

It's set in web.config. Look for <identity impersonate="true" /> in the file.

If it's set, change it to <identity impersonate="false" /> or get rid of it,
until you can debug your problem. The default is "false".

Which version of IIS are you using ?
If you don't know...which OS are you using ?

Another possibility : when you deleted the ASPNET user,
if <mach>/ASPNET is the account ASP.NET is configured to run as,
you also blew away all the permissions to several key directories the
account needs access to.

re:
!> run aspnet_regiis -i and then -ga

Try running, first, run aspnet_regiis -u (that will unregister the .Net Framework from IIS ),
and *then* running run aspnet_regiis -i (which will then recreate the account with all needed permissions).

Running aspnet_regiis -i without previously running aspnet_regiis -u
does not rebuild the account/permission set.

If you're using Windows 2003, however, the ASP.NET account is "NT Authority\Network Service",
though, and not ASPNET, so the permissions need to be assigned to *that* account.

 

[Guest]

Juan,
Thanks for the pointers.
I am running XP w/SP2. That would be IIS 5 (I guess). I have the 3.0
bits installed on top of VS 2005.
I tried running -u before -i, but it didn't fix the problem. This seems
so simple -- user ASPNET needs read access. When I run MetaAcl I get:

C:\Temp\iis-acl>cscript metaacl.vbs IIS://LOCALHOST/W3SVC

ORION12\ASPNET
Access: R E
S-1-5-21-1417001333-1677128483-1060284298-1012
Access: R E
ORION12\IUSR_ORION12
Access: R E
S-1-5-21-1417001333-1677128483-1060284298-1011
Access: R E
S-1-5-21-1417001333-1677128483-1060284298-1007
Access: R E
BUILTIN\Administrators
Access: RWSUED
Everyone
Access: E

It seems to indicate that it has Read access. 2.0 aspnet-regiis -lk returns:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -lk
W3SVC/ 2.0.50727.0
W3SVC/1/ROOT/Printers/ 2.0.50727.0
W3SVC/1/ROOT/PTWeb/ 2.0.50727.0
W3SVC/1/ROOT/PTWebService/ 2.0.50727.0
W3SVC/1/ROOT/WcfHost/ 2.0.50727.0
W3SVC/1/ROOT/TestSite/ 2.0.50727.0

And ...

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -lv
1.1.4322.0 Valid
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\asp
net_isapi.dll
2.0.50727.0 Valid (Root)
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\as
pnet_isapi.dll

What could be easier. I'm wondering if ASPNET is failing for some other
reason and mis-reporting it!

Any ideas?? I'm going to have to try rebuilding this machine, which won't
be any fun!

-- Chris

 

[Guest]

Some more digging around turned up another solution, which worked. The
solution is to change the identity the WP runs under. This is done in
machine.config with:

<processModel userName="SYSTEM" password="AutoGenerate" autoConfig="true" />

source ref is
http://www.thescripts.com/forum/thread455297.html

(still a mystery as to why ASPNET can't be successfully configured)

 

[Juan T. Llibre]

Can you try this :

cscript metaacl.vbs IIS://LOCALHOST/W3SVC ORION12\ASPNET RWSUED

?

 

[Juan T. Llibre]

re:
!> <processModel userName="SYSTEM" password="AutoGenerate" autoConfig="true" />

Running under the System account could create security snafus for you down the road.
It'd be better for you to correctly configure the ASPNET account, instead.

If you have no problems running as the System account,
i.e., your network is well protected against intruders or you're
running standalone with a good firewall, you're OK.

Otherwise, review this post :

http://forums.asp.net/p/1064973/1553869.aspx

It's essentially what I had posted earlier,
but adds manual deletion of the ASPNET accout before recreating it.

Also, review this ACL checklist for permissions :

http://msdn2.microsoft.com/en-us/library/kwzs111e.aspx
....and make sure the listed directories have the appropiate permissions.

 

[Guest]

Juan,

I'm running behind a decent firewall, and only doing development on the
'broken' machine. So, I'm at least coding again. I will follow up on these.
I had read elsewhere about manually deleting user ASPNET -- it didn't seem
to help.

I will take a look at the file permision issue. that was the only other fix
that I'd seen mentioned. It seems possible that SYSTEM has some file
permissions that ASPNET needs but doesn't have. That would be consistant
with why none of the other fixes helped.

Thanks very much -- Chris