Running Virtual Folder on Network Share with a different user

[ASP.NET User]

Hi

I am in a shop where developers are required to work off of a networ
share. This is so that code and other documentation is backed up nightly. This is outside the realm of Visual SourceSafe which we also use for code control. The network drive is used as the working folder. This is a configuration this shop has used for 6 years and I do not see it changing any time soon

So I am testing running an ASP.NET Web application with a Clas
assembly all on a shared drive

I have the solution working perfectly. However, I have run into
hiccup. In order to map IIS Virtual Dir to a network drive, you nee
to specify a username/password. When I use the username/password o
the person logged into XP for the Virtual Folder, then I can debug m
ASP.NET app with no problems. However, if I set the Virtual Folder t
connect as another ACL, then I get an error when debugging: Acces
Denied. If I log out of XP and then back in as that Virtual Folde
user, I can debug the ASP.NET application

Here is my configuration
Developer Workstation: X
File Server: Windows 200
CAS on XP has Full Trust of Windows 200

Two users: A &
Domain User
Administrators on both machines

IIS/ASP.NET on XP runs as A (through processModel machine.config
Impersonation is off

Virtual Folder 'Connects As' either A or B (ideally B
- using \\server\share. I tried mapping the drive and then using th
drive name but I receive 'The system cannot find the path specified
from IIS MMC

To Recap
1) - Logged into XP =
- processModel =
- Virtual Folder =
A can debug ASP.NET application

2) - Logged into XP =
- processModel =
- Virtual Folder =
B can debug ASP.NET application

3) - Logged into XP =
- processModel =
- Virtual Folder =
A CANNOT debug ASP.NET application: Access Denie

4) - Logged into XP =
- processModel =
- Virtual Folder =
B CANNOT debug ASP.NET application: Access Denie

The reason we want to have Virtual Folder connect as B is because
will be a generic username/password with special access to the Fil
Server. A will be any of the developer ACLs

This is to prevent administration with a couple 100 developer
changing 1000s of local virtual folders each time their password
change

[Steven Cheng[MSFT]]

Hi,

Regarding on your description, I've also performed some tests on myside. I
loged with a domain account which has sufficient priviliges on both
machine. and in the IIS's virtual dir, the UNC folder's connect as account
is set as
1. The powerful domain account
2. An Administrator account(also in debug user group) and has mapped on
both machine.

After that, we I try debug on the machine, the #1 work well and
the #2 occur Access Denied error as you mentioned.

Currently I'll consult some further experts on this issue and will update
you as soon as I got any further infos. 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

[[MSFT]]

Hello,

Did Steven's suggestion help on this issue? If you need more information,
please feel free to let us know.

Luke

[ASP.NET User]

The way I read the thread is that Steven was able to reproduce the same error that I was encountering and that he was going to consult further experts. So my understanding is an answer is forthcoming.

[Steven Cheng[MSFT]]

Hi,

I'm sorry for keeping you waiting since I was leave the previous days.
Currently I'm still waiting for some consult results from those experts on
this strange behavior. I'll let you know as soon as I got any updates.
Thanks for your understanding.

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

[ASP.NET]

Thank you, I will continue to monitor.

"Steven Cheng[MSFT]" wrote:

Hi,

I'm sorry for keeping you waiting since I was leave the previous days.
Currently I'm still waiting for some consult results from those experts on
this strange behavior. I'll let you know as soon as I got any updates.
Thanks for your understanding.

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

[ASP.NET]

Thank you, I will continue to monitor.

"Steven Cheng[MSFT]" wrote:

Hi,

I'm sorry for keeping you waiting since I was leave the previous days.
Currently I'm still waiting for some consult results from those experts on
this strange behavior. I'll let you know as soon as I got any updates.
Thanks for your understanding.

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

[Steven Cheng[MSFT]]

Hi,

We're still focus on this issue and will update you as soon as we got some
new info. 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

[[MSFT]]

Hello,

We are still working on this issue and will update you as soon as possible.
Thank you for the patience.

Luke

[[MSFT]]

Hello,

After consult with our programmer, we confirm this is a limitation for
using "Connect As". Currently, we suggest you not use "Connect As" option
for the issue. Just use an account who are administrator on both of the two
computers.

Luke

[ASP.NET]

Luke,

I have been working on 'plan B' if you came back with this answer. So we are going to use the same username as the person logged in.

This shop cannot run source code off of the C drive. The code (by organization policy) must run off of a network drive so it can be backed up nightly. This is in addition to checking compilable code into sourcesafe.

Our developers build and maintain hundreds of small applications. One developer can have 12+ web apps. Because each IIS virtual directory needs its own Connect As to the network drive you can imagine the maintenance nightmare everytime their Windows password is changed.

But I figured away to change the Connect As through Directory Services code so they'll just need to run a program that will apply the new password to all of their virtual folders.

I think I read once that ASP.NET could be setup to run in Master mode like Interdev used to -- which is why running our source code off the network was not a problem pre-.NET. So I may try and research that a bit too.
"[MSFT]" wrote:

Hello,

After consult with our programmer, we confirm this is a limitation for
using "Connect As". Currently, we suggest you not use "Connect As" option
for the issue. Just use an account who are administrator on both of the two
computers.

Luke

[[MSFT]]

Thank you for the information. If you have any questions during your
development, please feel free to post here. I will be gald to be asisstance.

Luke