Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We currently use a free SSL-FTP client called Move-It-Freely to transmit data from a custom data entry program at over forty facilities scattered around the state to our central server. Under XP, it works flawlessly.

Some facilities have upgraded to Windows 7. On these machines, uploads (transfers to us) work, downloads (transfers from us to them) fail. Replacing the Windows 7 machine with an XP machine solves the problem. We have also verified that the network firewall settings have not changed.

This problem persists even if Windows firewall is not running. We were able to remote into one of the Windows 7 machines to verify that the Windows firewall was indeed turned off.

We cannot replicate the problem on our own Windows 7 machines, and are at a loss of how to fix this feature for our customers. The data contain health-related information, and needs to be encrypted (hence SSL-FTP.)

Despite hours spent on Google, we cannot find a solution.

share|improve this question
Have you filed a bug report of submitted a ticket with the makers of Move-It-Freely? – MDMarra Jan 23 '12 at 16:36
The software doesn't claim to be compatible with Windows 7. Have you considered alternative software that does specifically support your environment? – Chris S Jan 23 '12 at 16:37
@Chris, while the website doesn't list Windows 7 in its compatibility list, the PDF file, MOVEit-Freely-Overview.pdf, states that it "Runs on Windows 7, Vista Business Edition, XP, 2003, and NT 4.0" – Andrew Neely Jan 23 '12 at 17:06
@MDMarra, The software is not open source, nor do I see a Bugzilla to report bugs. The freeware version has no support whatsoever. We went with the free version because, as a State Government office, buying anything is a difficult, painful task involving many levels of approval. Buying software even more so. – Andrew Neely Jan 23 '12 at 17:13
@AndrewNeely A piece of software doesn't have to be open-source to tell the devs that it's broken and Bugzilla isn't the only bug tracker in town. If there's no obvious way, an email to support will usually suffice. That said, if you chose to rely on a product for a critical task that has no support, you should have a backup plan in place in anticipation of a situation like this. – MDMarra Jan 23 '12 at 17:17

have you verified that the SSL settings are the same for win 7 systems in house vs the failing ones? Are you there is no external firewall setting (not on the client) that could be blocking this? It seems very odd that it works inside your lab but not going to the outside without some third party (like a proxy) doing something odd to the connection.

share|improve this answer
The SSL settings are identical (port settings, server name, user name and password.) since they come from a script. – Andrew Neely Jan 23 '12 at 17:15
You need to look at the SSL settings in windows (IE have you disabled SSLv2 and the software is trying SSLv2. ) Also have you taken one of the working systems outside the intranet to verify that working means working inside and out? – Jim B Jan 23 '12 at 19:49

Have you tried looking at a network sniff to help diagnose the issue? One big difference between Win7 and XP is that 7 sends TLS extensions, which could cause some servers to not succeed in negotiation of SSL/TLS connection. Have you tried the software against different servers running different software?

It could also be related to ciphersuites offered by the OS. Really, a network sniff can help you answer a ton of questions. If you manage to get one of the working case and failing case, post it publicly and I can help you look into it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.