FTP 2003 vs 2012 R2 ?

[CadJoe]

Hi,

I'm switching from a 2003 FTP server to a 2012 R2 ftp server, using Winbatch 2014A and wwint44i.dll.

The iFTPPut code seems to work sometimes perfectly, and other times, not at all.

The iGetLastError is showing in my log as error 12003, and sometimes Error 0.
Yet other times, submitting the exact same files and code works perfectly with no changes.

I was originally thinking it might have something to do with Explorer on the Server locking the file since I was in the same folder when uploading watching it.

But upon backing out of the folder and explorer, it got a little further on a couple of files, but then started failing again.

I also checked the FTP user file permissions on the server folder, and it has Full Control.

Any ideas?

Thanks,

CadJoe
WinBatch, Gotta Love It!

[Deana]

We have had various reports with WinInet returning 12003 for various WinInet Functions. It appears there may have been some changes to the Systems WinInet.dll that you will need to modify your script to handle for these changes. Please read: http://support.microsoft.com/kb/168492

The above behavior can often be avoided by not using the @FTPPASSIVE flag in the iHostConnect statement. Try using @FTP ( assuming this is supported by the FTP server that you are trying to connect ).

If you are unable to connect using @FTP rather than @FTPPASSIVE...

iFtpPut will return @TRUE if successful, @FALSE failure, and 2 if successful with further information.

If iFtpPut returns 0 or 2 call iGetLastError to get the underlying WinInet error code. Then consider re-attempting the iFtpPut or simply log the error and filename to a text file to review which files the iFtpPut is having a problem.

[CadJoe]

Hmm, ok, two things.

1) I am using a Microsoft FTP server.
2) I am using @FTP on all iHostConnect lines for the Connection Handle, and NOT @FTPPassive

I looked at the Cisco Firewall in front of the MS FTP server, and it has the following lines

no ftp mode passive
port-object eq ftp
port-object eq ftp-data

However, it also has the inspect ftp strict command, which forces compliance with FTP RFC's.

Does the wwint44i.dlll comply with all FTP RFC's?

Here's what the inspect strict says:

There is an option to use the inspect FTP strict command. This command increases the security of protected networks by preventing a web browser from sending embedded commands in FTP requests.

After you enable the strict  option on an interface, FTP inspection enforces this behavior:
ââ€"¦An FTP command must be acknowledged before the Security Appliance allows a new command.   (Maybe the Script is going to fast ? )
ââ€"¦The Security Appliance drops a connection that sends embedded commands.
ââ€"¦The 227 and PORT commands are checked to ensure they do not appear in an error string.

Warning: The use of the strict  option might cause the failure of FTP clients that are not strictly compliant with FTP RFCs

Thanks,

CadJoe
WinBatch, Gotta Love It!

[CadJoe]

ok, I tried removing the inspect ftp strict so that it wouldn't have to comply with RFC's.

Still same issue, fails immediately with error 0.

Changes?

I noticed its ONLY when the iFTPPut has to overwrite an existing file on the FTP server, like log files, ini files, etc, that get appended to.
If the folder is empty, then everything works.

Could this be an ASCII or BINARY thing, as I'm using ASCII.
What about a TRUE for KeepAlive ?

CadJoe
WinBatch, Gotta Love It!

[Deana]

Quick question on the 2012 R2 ftp server what version of IE is installed? Is it IE 11?

I currently suspect that IE11 introduced a possible WinInet bug that in turn is effecting the WinInet Extender: https://connect.microsoft.com/IE/feedback/details/808279/ftpopenfile-and-internetwritefile-broken-changed-in-ie11

See also:
https://www.google.com/#q=ftpopenfile+Microsoft+12003+IE11
http://stackoverflow.com/questions/19683291/wininet-from-ie-11-randomly-returns-error-12003-for-most-ftp-functions
http://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=898

[CadJoe]

Hmm, it is IE 11 version 11.0.9600.16663, Update Versions: 11.08 (KB2961851)
Its a bug because of version 666 above.. hehe

However, in playing around with the iFTPPut, I never in 10 years have had to use @True for KeepAlives, but that seems to have fixed it.

Will run it over and over and test it a lot, but thinking that might be a work around solution.

Should I pursue the IE11 bug fix, or will this issue come back again in IE12 even with the KeepAlive?

Thanks,

CadJoe
WinBatch, Gotta Love It!

[Deana]

Hmm, it is IE 11 version 11.0.9600.16663, Update Versions: 11.08 (KB2961851)
Its a bug because of version 666 above.. hehe

However, in playing around with the iFTPPut, I never in 10 years have had to use @True for KeepAlives, but that seems to have fixed it.

Will run it over and over and test it a lot, but thinking that might be a work around solution.

Should I pursue the IE11 bug fix, or will this issue come back again in IE12 even with the KeepAlive?

Thanks,

CadJoe
WinBatch, Gotta Love It!

Interesting. Not exactly sure why the keep alive would have resolved the issue, but good to know. Do you have code in your script to capture last error information, if not I recommend adding it to capture any future issues.

As far as pursuing a bug fix, it appears there are a ton of users reporting this issue to Microsoft and is actively being investigated. I recommend keeping your eye on this bug report: https://connect.microsoft.com/IE/feedback/details/808279/ftpopenfile-and-internetwritefile-broken-changed-in-ie11

[Deana]

I have read some reports that closing and reopening the connection can resolve the 12003 WinInet error issue. You might consider adding code to close a re - open is the case of the 12003 error.

[CadJoe]

Well, so far the KeepAlive is working, haven't had a single error since.

Not sure if my error trapping is correct, but see attached, that's how I was seeing 12003 in my LOG file.

Worried now that a windows update on the 2012 R2 server in the future might break this again.  Thoughts?

CadJoe
WinBatch, Gotta Love It!

[Deana]

Use Winsock Extender function ftpPut instead...That will put the WinInet issue to rest. Unfortunately it will require a code rewrite using the WinSock Extender FTP functions.

[CadJoe]

ok, that's an option.

If I'm going to do a rewrite, I'd rather it be for a Secure FTP.

Been waiting for that for years, any plans on an extender to do Secure FTP, without 3rd party add-ons?

Thanks,

CadJoe
WinBatch, Gotta Love It !

[td]

ok, that's an option.

If I'm going to do a rewrite, I'd rather it be for a Secure FTP.

Been waiting for that for years, any plans on an extender to do Secure FTP, without 3rd party add-ons?

Very unlikely.

[td]

You can perform FTPS transactions using WinBatch's dotNet support.

[CadJoe]

You can perform FTPS transactions using WinBatch's dotNet support.

Ok, not familiar with this.  I didn't see this as an extender on the Download page, is this built into WBDNA44i ?

Any examples, etc ?

Thanks,

CadJoe
WinBatch, Gotta Love It!

[Deana]

dotNet is included in the main dll.

WinBatch supports access to the Microsoft dotNet Framework. WinBatch makes this possible by hosting the common language runtime (CLR) and exposing functionality for creating and accessing the members of classes, structures and enumerations of managed code assemblies (DLLs) that are part of or based on the Framework. Search for dotNet in the Consolidated WIL help file.

Maybe check out the FtpWebRequest Class( but requires .NET Framework 4.5)    : http://msdn.microsoft.com/en-us/library/system.net.ftpwebrequest.aspx

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/dotNet