The best way to copy files across VPN. XCOPY, FSO or something else?

[TomLeMes]

I need to create a simple program to copy files from a network drive (local server) to a standard location on a remote server, connected via a VPN. Seems like a simple task, but the program needs to work on Win2K, WinXP(SP1) & WinXP(SP2).

I tried this using FSO.Copyfile (first mapping a drive with NET USE, then unmapping after the transfer is complete). This worked fine except on Windows XP sp2 where it gave an error message. The people using the program are working in France so the error messages are also in French (just to complicate matters!):

Erruer D'execution '-2147024409 (800701e7)': Tentative d'access a une addresse non valide

I don't know how good your French is, but this means something like "attempt to access an invalid address" (I think!).

After a bit of playing around I decided to try a different method - XCOPY using the IP address. Again I got this to work fine with Win2K and WinXP(sp1), but now got a new error message with WinXP(sp2). Afraid I've lost the error message now as this all happened last week.

I should mention that in both versions of the program, administrator credentials were being passed with the connection/copy commands.

Does anyone know of a method/command that will definitely work on WinXP(sp2)?

 

[jebenson]

Could it have something to do with Windows XP firewall, which SP2 turns on in XP?

 

[TomLeMes]

I thought it might be the firewall at first - it had been active - but after turning it off there was no change.

I've just connected to the computer in question and done some more testing and found that now (some of the time) the actual mapping and file transfer (using NET USE to map the drive and XCOPY to copy the files) are working. Now the problem seems to be removing the mapped drive afterwards! Frustratingly, it gives an error message at the point that the computer goes to unmap the drive, saying that the network drive is not accessible. However, in Explorer view, it still shows the mapped drive (I'm using W even after hitting F5, but when I click on it I'm told that the network drive is not accessible again (in French).

Starting to lose the will to live on this one. Any ideas gratefully received!

 

[hmckillop]

Its sounds like its definitely a firewall issue.
I am seen several problems with SP2 on XP and they have all been related to the firewall setup.

In Windows XP SP2, there are many changes for Windows Firewall, including the following:

• Enabled by default for all the connections of the computer

• New global configuration options that apply to all connections

• New set of dialog boxes for local configuration

• New operating mode

• Startup security

• Excepted traffic can be specified by scope

• Excepted traffic can be specified by application filename

• Built-in support for IPv6

• New configuration options with Netsh and Group Policy

"Windows Firewall in Windows XP SP2 is globally enabled by default. This means that, by default, all the connections of a computer running Windows XP with SP2 have Windows Firewall enabled, including LAN (wired and wireless), dial-up, and virtual private network (VPN) connections. [bold]New connections also have Windows Firewall enabled by default.[/bold]

You would need to ensure that you switch the firewall off for the global connection. If you have done this already try having a look at the microsoft at what else SP2 has added in the security side of things.

http://www.microsoft.com/technet/prodtechnol/winxppro/plan/xpsp2ff.mspx

Hope this helps

"I'm living so far beyond my income that we may almost be said to be living apart

 

[TomLeMes]

Thanks for that hmckillop - I'll have a good look through and see what I can find. Also, I've been testing all this on the actual French machine which makes it a bit tricky when all the error messages appear in French! Now I've procured an English XP with sp2, so hopefully I'll make some speedy progress.

 

[TomLeMes]

Still struggling with this! We've had SP2 removed from the French XP machines (so they are all on SP1 now) but still having problems. The problem seems to relate to a timing issue with the mapping of the drive.

I'm using

shell "net use W: " & my_destination & " " & my_mapping_details
Do Until fso.driveexists("W") = True
    Sleep 1000
    z = z + 1
    If z = 30 Then
        MsgBox "Mapping Failed"
        Exit Sub
    End If
Loop

to map the drive and put in a potential 30 second delay to try and handle the usual delay in mapping the drive (across a VPN). With Win2K machines, this seems to work quite well as it prevents the code from continuing on to the copying sub until the W drive has been added.

However, on XP machines the driveexists clause is being found true, then it throws an "Error 76: network path not found" when it tries to copy the files! When I look in Windows Explorer view you can see an extra drive, but without a drive letter next to it! If I hit F5 the drive appears properly! Is there some way to do the equivalent of hitting F5 from within VB? Any other ideas?

 

[VBrit]

Silly question, but why map a drive? Why not just use UNC???

fso.copyfile "\\myserver\source.txt", "c:\destination.txt"

????

 

[TomLeMes]

OK, I'm not all that up on the whole VPN stuff, or DNS stuff for that matter, but as far as I'm aware, we can't use the UNC path for our remote servers with our network settings. IP works, but UNC doesn't, and I don't think you can use IPs in the fso.copyfile method.

If that sounds wildly unlikely then please let me know as I'd be well-happy to drop this whole drive mapping nightmare and stick with fso.

 

[bjd4jc]

I just tested this code with IP Addresses and it worked Fine.

CreateObject("Scripting.FilesystemObject").CopyFile "\\192.168.10.101\c$\countries.txt", "\\192.168.10.101\c$\unctest.txt"

It doesn't hurt to test stuff out like this on your own - it beats the heck out of just assuming that it won't work. I encourage you to test things out for yourself... you'll learn much in the process of doing that. The worst thing that can happen is that it won't work.

 

[TomLeMes]

This is something I had tried previously but we're trying to copy to locations that the users don't have rights to - we need to pass username and passwords (Sorry, should have mentioned this) to get access and fso.copyfile doesn't have that as part of its syntax. This was one of the main reasons for mapping drives (which does allow the passing of credentials).


Thanks for the encouragement BJ, just want to reassure you I'm not just asking questions coz I can't be bothered to try stuff out for myself. It's just that sometimes it helps to get the benefit of other peoples' experience and ideas when you can't get it to work yourself... I appreciate everyone's help with this

 

[bjd4jc]

>> I'm not just asking questions coz I can't be bothered to try stuff out for myself

I wasn't trying to indicate that you were lazy. Some people just simply don't think to try things out, that's all

As far as passing credentials... thread222-944981

You still do not need to map a drive to do this. You can simply connect to the other location and not use a local drive letter.

 

[TomLeMes]

Nice one, this looks like just the ticket, thank you very much.

And I appreciate the whole point about people just asking before trying - unfortunately sometimes these issues have enough pitfalls that I'll try something, research it, try again and still not be able to get it to work - that's when I come to you guys for help

Thanks again!

 

[TomLeMes]

OK, I promise I tried this out before coming back to you ;-), but like the guy in the post says, that exact code gives an error and I'm not so hot on the old API stuff to fix it. However, it was a great starting point, so I've been looking into the WNetUseConnection API call and here's what I found:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wnet/wnet/wnetuseconnection.asp

and also:

http://support.microsoft.com/kb/q256847/

Both seem to suggest that although you don't actually have to specify a drive letter, this command assigns the first available letter, so we are still having to map a drive. Or is there a way to bypass that bit? Either way, I'm going to try using this in the hope that this is a more reliable way to make and break the connection. Cheers.

 

[bjd4jc]

I posted a fix in the previous form for the 87 error. I was crossing the user name and password and the variable BufferLen was mis-spelled.