FSO Path Not Found Error

[Matt]

I am migrating from NT 4.0 (IIS 4) to 2003 Server (IIS 6). Our Intranet
has numerous applications that utilize the FileSystemObject (FSO) and
each one is returning a "Path not found." error. These applications
work fine on IIS 4. Here is the scenario:

- Mapped Drives on server to anotheer network Drive (I.E. - Q:\)
- IIS uses different Domain accounts for anonymous access (based on the
application).
- These domain accounts have all of the proper rights to the mapped
drives.
- I then pass an ASP function the desired path to display files (i.e.-
Q:\IT, or Q:\IT\Documents)

At this point is when I receive the Path not Found error. I have read
some other posts that mention the mapped drive can not be seen by the
anonymous user account. Is this a new issue with IIS 6 (Win 2k3)?
Again, this works fine with the exact same setup in IIS 4 (Win NT 4). I
don't want to use UNC paths because there are so many locations within
the Intranet that contain the drive letter paths. Can anyone help with
this issue? I also changed one of the anonymous accounts in IIS to the
Domain account that the server is logged in as and I still received
this error. I know there si nothing wrong with my code because the
exact same code works fine on the existing server. I am beating my head
against the wall on this. Please let me know if you know how I can
correct this issue. Thanks.

 

[Roland Hall]

in message
:I am migrating from NT 4.0 (IIS 4) to 2003 Server (IIS 6). Our Intranet
: has numerous applications that utilize the FileSystemObject (FSO) and
: each one is returning a "Path not found." error. These applications
: work fine on IIS 4. Here is the scenario:
:
: - Mapped Drives on server to anotheer network Drive (I.E. - Q:\)
: - IIS uses different Domain accounts for anonymous access (based on the
: application).
: - These domain accounts have all of the proper rights to the mapped
: drives.
: - I then pass an ASP function the desired path to display files (i.e.-
: Q:\IT, or Q:\IT\Documents)
:
: At this point is when I receive the Path not Found error. I have read
: some other posts that mention the mapped drive can not be seen by the
: anonymous user account.

I don't know if a mapped drive cannot be seen but it appears to be a
permissions issue. Is this a new server? If so, the remote system has to
accept the account that is trying to access the file.

: Is this a new issue with IIS 6 (Win 2k3)?
: Again, this works fine with the exact same setup in IIS 4 (Win NT 4).

It works if permissions are set correctly.

: I don't want to use UNC paths because there are so many locations within
: the Intranet that contain the drive letter paths.

So? UNC means never having to map a drive. Just because drives are mapped
does not mean you cannot also use UNC.

: Can anyone help with
: this issue? I also changed one of the anonymous accounts in IIS to the
: Domain account that the server is logged in as and I still received
: this error.

Then you have to disable anonymous access.

: I know there si nothing wrong with my code because the
: exact same code works fine on the existing server. I am beating my head
: against the wall on this. Please let me know if you know how I can
: correct this issue. Thanks.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Aaron Bertrand [SQL Server MVP]]

- Mapped Drives on server to anotheer network Drive (I.E. - Q:\)

You can't rely on mapped drives. Did you log onto the server as each of the
different Domain accounts and configure all of the drives identically? If
you are not willing to do that (and you should not be), use a UNC path.

http://www.aspfaq.com/2168

don't want to use UNC paths because there are so many locations within
the Intranet that contain the drive letter paths.

Are these all hard-coded within the ASP page? This may be a wise time to
make the root location(s) configurable and global instead of hard-code all
over the place.

 

[Matt]

So baically, unless I log onto the web server as each of the domain
accounts (used as anonmymous accounts in IIS) and map the network
drive, this won't work unless I use UNC paths?

 

[Matt]

Are there specific account logon rights that are required for 2003
Server? I tried a UNC path in one place and received the same "Path no
found." error. Again, I have a domain account I use as the anonymous
account, in the form of "DomainName\itdeptadmin", and this itdeptadmin
account has "modify" permission on the network drive that I am trying
to access through FSO. I have this drive mapped to the web server as
the Q:\. I have tried both the UNC path "\\cyclops\it" and the mapped
drive "Q:\IT" and in both cases I receive a "Path not found." error.
Again, on the NT 4 web server this works fine for me with the exact
same setup. There must be something on my 2003 web server preventing
this?

On the 2003 server I have copied and pasted both paths into the run
command and was able to access the directory. I executed a
response.write and copied the path from the screen to ensure my
application was trying to access the proper location.

I also have auditing turned on for success and failure on both the web
server and the remote server and do not see any failure attempts in
Event Viewer.

 

[Matt]

Sorry. I posted this last one to fast. I had another FSO call under the
first one that I did not update to UNC and that is what was giving me
the error.

If I begin to use UNC paths will this propose any issues to me in the
future as using mapped drives has at this point?

Also, I will place all of these UNC paths into one default location.
What is your reccomendation between the following or if you have
another idea:

A) Place all the information into a database and create a default
function the call to retrieve a path.

B) Create a common include file and set variables = to the desired UNC
path and reference those variables from my ASP pages.

My thought is probably (B) because then I don't have to query the
database each time I need a path.

Thanks for your posts.

 

[Aaron Bertrand [SQL Server MVP]]

A) Place all the information into a database and create a default

function the call to retrieve a path.

B) Create a common include file and set variables = to the desired UNC
path and reference those variables from my ASP pages.

My thought is probably (B) because then I don't have to query the
database each time I need a path.

And since this path is unlikely to change frequently.

 

[Matt]

Thank you to both of you for your input. Much appreciated.

 

[Aaron Bertrand [SQL Server MVP]]

My gut feeling is that information like this *should* be stored in a
database, not in source code, especially when there is a chance that the
information will be used across multiple applications in an enterprise.
However, this is not always practical, since database connectivity is
overhead that might otherwise be avoided.

So another idea, and one I have been implementing a lot lately, is to have
an admin page that (re-)generates the include file from information stored
in the database. You go to a web interface, change the path, and when you
hit submit, a new static #include file is generated, replacing the old one.
The app continues to function quickly without that db hit, and nobody had to
check files out of SourceSafe or delve through ASP code looking for variable
declarations...