We are trying to move files via an ASP page. The process is captured in a 
dll file that has been instantiated as a COM+ application.

This smoketest.dll COM+ component was created and assigned to the 
SysAdmin user so that all calls to the program will run in that user's 
space.

The SysAdmin has full domain access to all servers. 

The smoketest.dll uses a path passed by the ASP page and the 'domain' 
where the files are to be copied.

The app reads a list of file names, parses the name for the directory 
location and attempts to copy the file from the original default location 
to the mapped directory provided in the call to the dll.

The dll tests fine with a VBScript file in the WScript shell. However, 
when it is called via ASP, a "Path not found" error is generated. 
Debugging around the FileSystemObject shows that the path failure 
dervives from the FSO FileCopy method. The source path is not found.

I have tried using both a mapped network drive path and a virtual 
directory path to the source file. Neither work. Administrator, IUSR and 
IWAM all have FULL CONTROL over ALL of the network folders.

It was my understanding that the SmokeTest.dll instantiated through COM+ 
would run under the SysAdmin as if they were logged into the server. And 
I presumed that it would run similarly to the VBS file that was used in 
testing the smoketest.dll, originally.

What could be missing or done to resolve this problem?

I have resolved the problem. As it turns out, the shares where the files 
either existed or were to be moved to did not necessarily have all the 
privileges I was originally led to believe.

Lesson: When all else fails, blame the SysAdmin.

The COM+ resource handles the call appropriately in the SysAdmin role.

If anyone else has difficulty with a situation like this in the future. I 
might be able to offer some trouble-shooting ideas to isolate the missing 
link in the chain.