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.
Use SMB.
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:
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 :-)
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.
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.
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.