Running Virtual Folder on Network Share with a different user.

  • Thread starter Thread starter flat_ross
  • Start date Start date
F

flat_ross

Hi,

I am in a shop where developers are required to work off of a network
share. This is so that code is backed up nightly.

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

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

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

Two users: A & B
Domain Users
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 the
drive name but I receive 'The system cannot find the path specified'
from IIS MMC.

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

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

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

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


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

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

Regards,
Ross
 
wouldn't using Source Safe take care of even needing this funky setup?
Why use a huge hinkey workaround so you get backups, why not just do backups
properly?
 
Perhaps your company should go with the more standard approach of letting
the developers work locally connected to a centralized SourceSafe database.
That database can then be backed up nightly.
You're just asking for headaches with such a non-standard approach.
 
Back
Top