Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2782
  • Last Modified:

Using objFSO.GetFolder

I want to be able to see what is in a certain folder using objFSO.GetFolder. The catch is it is on a different drive on the web server.

I can do this and get it to work:
Set objFolder = objFSO.GetFolder("C:\Program Files\Messenger")

But the thing is the folder I want to see is on drive G:
Set objFolder = objFSO.GetFolder("G:\Scanned_Images")

I get this error message.

Server object error 'ASP 0177 : 800a004c'
Server.CreateObject Failed

/htmlpages/untitled-4.asp, line 50

The operation completed successfully.

A virtual directory was created and I checked the permissions and they seemed fine. Can anyone tell me what is wrong?
  • 6
  • 6
1 Solution
It looks like the path G:\Scanned_Images is invalid.

If G: is a mapped network drive, keep in mind that the mapping will not necessarily be accessible to the account under which your code is running or there may not be a user logged on to the server if the mapping is user-specific.

To debug the problem, take smaller steps:

Dim oFSO As Object
Set oFSO = CreateObject("Scripting.FileSystemObject")
' To check for the folder's existence
MsgBox "Folder Exists? " & oFSO.FolderExists("G:\Scanned_Images")

' If the folder doesn't exist, does the drive exist?
If Not oFSO.FolderExists("G:\Scanned_Images") Then
    Dim oDrive As Object
    For Each oDrive In oFSO.Drives
        MsgBox oDrive.DriveLetter
End If
ajcatanoAuthor Commented:
I took your advice and took small steps the drive does exist but it does not see the folder. I guess its back to looking at the permissions.
Is G a network drive?  That is, is G really a drive mapping to a share on another computer?

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

ajcatanoAuthor Commented:
Yes it is the drive letter on a mapping to another computer.

I thought for sure it was permissions but I set them to let everything and everyone in and I still got the error. On top of that if I put a virtual path I can pull an image from it. The thing is it just will now work with the filesystemobject.
If the Administrator is logged into the computer all of the time and the drive is mapped by the Administrator account and IIS is set to run under the Administrator Account, Active Server Pages will be able to access the mapping.  If this is a VB client, it will also be able to access the mapping, but only if the user logged onto the local computer where the VB prog is running is the Administrator.  Every user on an NT WS/server can have their own mappings.

On which computer is the VB program running?  The server, or any workstation?  Is it an ActiveX component or an EXE?  Is it always run by the Administrator? or by just any user?
ajcatanoAuthor Commented:
It is just a local login but it has administrative rights. it is a ASP Page that is running the script. I went this word for word


with no luck.
So I don't need to type in all the possible options:
Are you on a Domain or using Active Directory?
Is the IIS server running under the local IUSR account or under a domain account?
ajcatanoAuthor Commented:
Active Directory.

IIS is running under local IUSER but I have tried it under a domain account with no luck.
You mentioned that drive G exists, but not the directory you are looking for.  When you Response.Write through the Subfolders collection for drive G, do you see any folders?

You also mentioned that you could access the data from a virtual directory.  Could you do a Server.Mappath() to fetch the virtual directory's underlying path and feed that to FSO?

When you set up the virtual directory, did you provide an authentication login and password?  I would think you would have had to have becuase the IUSR account would not have rights on any other computers.  Therein would lie the reason why that method worked.

ajcatanoAuthor Commented:
No I do not see any folders at all.

When I try the Server.Mappath()

I get this error

Invalid Path Character

An invalid character was specified in the Path parameter for the MapPath method.

If I take the http: out I get this error

Invalid Path Character(s)

An invalid '/' or '\' was found in the Path parameter for the MapPath method.

Yes it was set up with a login and password.

Yes, Server.MapPath() only wants the virtual path like Server.MapPath("/images")  It would then return something like "C:\inetpub\wwwroot\images"

I don't think that would work anyway, since the path it would return would not be a drive mapping, but a UNC like \\myserver\myshare which would end up in an access-denied message.

The problem is that the user browsing the page did not pass credentials that will work on the remote computer.  This is either because the credentials passed are subject to the single-hop NTLM limitation or because the credentials themselves do not allow the user access to the remote resource.

1. The browser connects to the server with anonymous authentication.  The resource is unavailable.
2. The server passes back a "401 not authorized" and in the header indicates which types of authentication are permitted (Basic, NTLM, Digest, Kerberos)
3. If IE is used, it will attempt NTLM next.  The problem is that only a hash is sent.  IIS receives the hash and instances the FSO, however, the FSO cannot then pass on the hash because the hash was created using a value originally generated by IIS in the 401 header.  It won't be valid on another computer.  That's the single-hop limitation with NTLM.
4. If Basic is enabled on the server, the credentials are passed in the clear and IIS is able to pass them to any other resource that requests them.  Unfortunately, the passwords are easily sniffed by others on the network.  Not good.
5. If digest is used, the password is secured by a hash similar to NTLM and you end up with the same problem.
6. If Kerberos is used, then the channel is secured and the credentials can be passed to IIS and repassed to other resources.

IIS always tries to access a resource using the user's credentials first, then will use it's own credentials.  Since it's a local login, that typically doesn't get IIS any farther towards getting the resource.

This problem started to occur several years ago when MS started tightening up security on the server.  I remember some service pack I installed broke my FSO code.

OK, so that's why it's not working and it also hints at what your options are for getting this to work:

1. Use a server-side MTS/Component Services ActiveX Component to pump the data back to you.
2. Use IIS/FSO on the remote computer to return the data in a page that you can include in an IFRAME or FRAMESET.  Even this is now problematic because of cross-frame security built into the browser.  There are ways around it including change security zone settings in the browser or using a HTA HTML Application.
3. Enable Kerberos (not trivial, basically a change to your network)
4. Enable Basic Authentication (Not Recommended) (if you want to test, make sure to restart IIS)

I chose to go with number 1, since the folder/file access is also *much* faster using VB and making API calls (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/file_management_functions.asp)  or you could still use VB and FSO for a little speed improvement.
The catch is that you need to run the component under Component Services (formerly MTS) using impersonation of a domain account.  Don't use the Domain Administrator, but use some account that has access to the directories you need to enumerate.  To do this:

1. Create your component as an ActiveX DLL.
2. Test it using a second Standard project in a project group. Don't mark the classes as MTS components until your local testing is complete.
3. Mark the classes as MTS, no transaction required.  
4. Turn on Binary compatibility and auto-increment version number.
5. Compile
6. Copy the DLL to the IIS server.  It doesn't really matter where you put it (i.e. C:\ServerComponents).
7. Register the component with regsvr32 <componentname>.
8. Create a new package in Component Services
9. Add your new component as a component that is already registered
10. Test from ASP
Dim x as Server.CreateObject("ProjectName.ClassName")

Now we know it won't work perfectly the first time so here's what you need to do after you fix the bugs:
1. Remove the component(s) from Component Services, the package can stay
2. Before copying the new DLL to the server, unregister it with regsvr32 /U <componentname>
3. Restart IIS (Otherwise it will usually maintain (lock) the component in memory for something around 20 minutes)
4. Delete the old DLL
5. Copy the new to the server
6. Register the new component
7. Add it to your package in Component Services
8. Test it again

Probably more than you wanted to know :)
ajcatanoAuthor Commented:
wow that is alot. I went in a different direction to get it done. Thats a little (actually A LOT) past my level right now. Thanks for all your help.
How u solved this problem in a different way,

For me its running in one IIS and not in other,
I tried all the way but in vain.Please help....

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now