Problem running local asp.net app with web site on network share

[JR]

I have a Web server running on Windows XP. On this Web server, I have a Web
site configured with its home directory on a network share. In the Web site,
there's a virtual folder pointing to a local folder on the Web server
containing an ASP.NET application.

I get a "Failed to start monitoring changes" when I try to run the
application. If I try to debug, I get a message "unable to start debugging
on the Web server".

I put an <identity impersonate=""> section in Web.config specfying a domain
account that has permissions to the share for the Web site and the local
ASP.NET application, but that didn't correct the errors.

I'm running ASP.NET 1.1 and I don't understand why ASP.NET would care about
any files above the virtual folder in the Web site, which again, points to a
local directory.

Of course, I have no problems with the ASP.NET application if I change the
home directory of the Web site to a local folder.

Note: I got this to run once using the <identity> setting, but I commented
it out to confirm it would fail, and now putting it back doesn't allow the
site to run.

Thanks.

 

[Jeff Widmer]

Take a look at this article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;317955

Make sure you have given permissions to the full path to teh virtual
directory.

Hope this helps,
-Jeff

 

[JR]

Unfortunately, it didn't.

Take a look at this article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;317955

Make sure you have given permissions to the full path to teh virtual
directory.

Hope this helps,
-Jeff


to

 

[Steven Cheng[MSFT]]

Hi JR,

I have performed some tests on my side. I can also reproduce this error
message.

Actually, the cause for the error message is in Windows XP, ASP.NET
application run with the work process aspnet_wp.exe, which by default use
the local "ASPNET" account. Since it is only a local account, we can't add
it to the UNC folder. This will cause the error message.

To trouble-shoot this error, we can try the following methods:

Method 1:
----------

We can set the account for aspnet_wp.exe to local system, and then add the
computer as one account to the UNC folder.

1. Locate the "machine.config" file.

2. Make a backup of this file.

3. Locate the following in this config file:

<processModel ... userName="machine" password="AutoGenerate"... >

4. Change "machine" to "SYSTEM".

5. Add the computer as one account to the UNC folder with appropriate
permission (or just "Full Control" permission).

Note: To add one computer as one account, make sure to check "Computers"
for "Object Type" when adding accounts.

Method 2:
----------

We can also specify one domain user account for aspnet_wp.exe, which has
appropriate permission to the UNC folder.

1. Locate the following in the machine.config file:

<processModel ... userName="machine" password="AutoGenerate"... >

2. Change the user name and password like following:

userName="DomainName\username" password="password"

3. Add the account to the UNC folder with appropriate permission (or just
"Full Control" permission).

For more information with the steps and the permission needed for this new
account, please refer to the following Knowledge Base articles from
Microsoft:

324393 HOW TO: Install the .NET Framework on a Cluster
http://support.microsoft.com/?id=324393

317012 INFO: Process and Request Identity in ASP.NET
http://support.microsoft.com/?id=317012

Have a nice day!

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[JR]

Steven, I can't investigate #1 because that won't work for our production
system. AS STATED IN MY INITIAL POST, I tried a variant of #2, making the
change in Web.config because machine.config changes will not be allowed in
our production environment.

Any idea as to why setting the <identity impersonate=""> setting in
Web.config to a domain account that has permission to the network share
isn't working?

-J

 

[Steven Cheng[MSFT]]

Hi JR,

Thank you for the response. Regarding on the issue, we're
finding proper resource to assist you and we will update as soon as posible.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security(This posting is provided "AS IS",
with no warranties, and confers no rights.)

 

[Steven Cheng[MSFT]]

Hi JR,

After some further analisis, I would like to explain the steps when running
the ASP.NET web application under our scenario. I believe this is helpful
for us to further understand the problem.

When we start the web application at the sub directory, it is attempting to
access the share because the configuration system is looking for a
web.config file at the root. When the process model is set to "machine",
then it tries to use the UNC account password to login, and it is failing.
I have also tried to grant "Everyone" with "Full Control" permission of the
shared folder. However, the same error message still appeared. When the
account is "system", it does not use the UNC account, and the machine has
access to the remote share.

We can find that ASP.NET has not tried to check the web.config in the sub
directory at this time. Therefore the Impersonate settings in the sub
directory will not take effect.

Actually, to access the remote shared root when starting the web
application, we need to make sure the ASP.NET work process has the
permission. This is the reason that we need to modify the <processModel> in
machine.config file.

I understand that it is hard to modify the machine.config on the production
server. However, if the root folder for the web site is one shared folder,
I am afraid that we still need to modify this file. Actually, the two
methods in my last reply both modify the machine.config file.

If there is any further concern, please don't hesitate to let me know.
Otherwise, I suggest that we backup and modify the machine.config according
to the steps in my last reply. Thanks!

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[JR]

Thanks for the thorough analysis. I'll speak with our production team about
making these changes. Last question: do you have anything that definitively
explains when an ASP.NET applicaition uses the processmodel setting versus
the impersonate setting? It's still not clear in my mind.

Thanks again.

 

[Steven Cheng[MSFT]]

Hi ,

Thanks for your effort and time. I really appreciate it.

Regarding the information when an ASP.NET applicaition uses the
processmodel setting versus the impersonate setting, please refer to the
following information:

When ASP.NET start running, it will parses the configuration file.
Inetinfo.exe, which runs under the System identity, reads the <processModel
/> section. After that, the ASP.NET worker process (Aspnet_wp.exe) reads
the <sessionState/> sections.

If content is hosted on a Universal Naming Convention (UNC) share, the
account that is used to access the UNC share must have permission to read
these keys.

We can find that at this time, the <Impersonate> settings in the web.config
file has not been checked at this point.

For more information, please check the following two Knowledge Base
articles from Microsoft:

329290.KB.EN-US HOW TO: Use the ASP.NET Utility to Encrypt Credentials and
Session State
http://support.microsoft.com/default.aspx?scid=KB;EN-US;329290

If there is any unclear, please feel free to let me know.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx