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

I've found myself with an interesting problem; I need to push files from one windows server to another. SMB/CIFS is out because we block the port.

If I was on a linux / OS X system I'd have SCP; WinRM doesn't support file transfers until powershell 3.

I can use any services that come with Windows Server 2008 R2 or Server 2012.

So the question is, who can come up with an original solution?

Edit: To help highlight this requirement TCP 445 is unavailable; any solution will need to use a different port.

share|improve this question
I can't follow. Why does SMB/CIFS not work? You could use NFS, both 2008 R2 and 2012 support it... – MichelZ Jul 19 '12 at 12:34
"SMB/CIFS is out due to sharing the port with Active Directory services." What? – MDMarra Jul 19 '12 at 12:35
I think I forgot to mention, the reason CIFS is out is that these machines talk across a DMZ; Port TCP 445 is used by domain computers to communicate authentication tokens and other sensitive information. To mitigate the risk of attack, we've decided to block TCP 445 which has the side effect of blocking CIFS. – Preflightsiren Jul 19 '12 at 13:05
You should edit your question and explicitly state all ports and restrictions that are specific to your environment. If you can't use token-based auth, how are you going to be authenticated to transfer the files? A separate authentication process? That sort of thing factors into this. – MDMarra Jul 19 '12 at 13:11
Also, authentication tokens are distributed over port 88, not 445. 445 is used for password changes, but afaik, no tokens are ever transmitted over it. – MDMarra Jul 19 '12 at 13:42

Use SMB.

SMB/CIFS is out due to sharing the port with Active Directory services.

I'm not sure what exactly you're talking about, but that's not right. Modern implementations of SMB use SMB over TCP, which happens on port 445. Legacy implementations of SMB rely on NetBIOS over TCP, which uses a combination of ports 137-139. None of these ports are AD specific.

AD relies a lot of ports, the most common ones are:

  • 53 - DNS resolution
  • 88 - Kerberos
  • 135 - RPC Endpoint Mapping
  • 389 - LDAP
  • 636 - LDAP over SSL
  • 3268 - Global Catalog
  • 3269 - Global Catalog over SSL
  • 49152 - 65535 - for RPC endpoints (on a 2008 and later DC)

Sure some functions of a client logging in use SMB (like processing GPOs), but there's nothing authentication or authorization specific that runs over the same ports as SMB. You seem to be (mistakenly) over-protective of port 445 :-)

share|improve this answer
AD members communicate over TCP 445 for particular AD operations.… and… – Preflightsiren Jul 19 '12 at 12:55
Hence, can't use SMB/CIFS :( – Preflightsiren Jul 19 '12 at 12:55
I still don't get it. I have an Active Directory running on my Domain Controller, and I'm still able to browse to \\dc\c$ over CIFS/SMB :D – MichelZ Jul 19 '12 at 12:57
@Preflightsiren Still not sure what you're trying to say. Are you saying that this will not work because of some conflict, or that some security requirement for your network? Are you planning on hosting these shares directly on your Domain Controllers? – MDMarra Jul 19 '12 at 12:59
Then you'll have to use a mechanism other than SMB, such as FTP. – joeqwerty Jul 19 '12 at 13:32

Since you're blocking the port that Windows natively uses for both authentication and file transfers, you're up a creek for finding a native protocol to do this. You might be able to use NFS for this. You could install FileZilla server (free), and script the transfers with psftp or another SCP client. Since you have no native option, the sky is almost the limit for you.

share|improve this answer
NFS might work, but I feel dirty enough using it on Linux, nevermind Windows :) Not to mention it's not native in Windows until 2008 R2. The tags here say 2008, but a good option nonetheless. – MDMarra Jul 19 '12 at 14:25

Windows Server 2008 only natively supports (both the server and the client for) CIFS and FTP. Everything else requires that you install/download something else. Since CIFS is unavailable this leaves you with FTP.

share|improve this answer
Which would be far less secure than any other option I can think of. – mfinni Jul 19 '12 at 14:52
True, but it fits his requirements. – Chris S Jul 19 '12 at 14:54
Not if security is one of his requirements. They block port 445 because they (incorrectly) think AD Kerberos can be replay-attacked : you think they're going to allow plain-text passwords? – mfinni Jul 19 '12 at 15:37
Windows also supports webdav, if you add IIS. – Zoredache Jul 19 '12 at 15:42
@Zoredache You have to download the WebDav add-in for IIS... It's not part of the OS as-is. – Chris S Jul 19 '12 at 15:43

Just a thought in light of the all the discussion above, if the server is in a DMZ, are you blocking traffic inbound to the DMZ from the private network? You could connect to the server in the DMZ via SMB/CIFS from a host in the private network and pull the files from the destination server instead of pushing the files.

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.