Copy and Move Files from One Server to Another on Windows Server

Question

I was asked to jump in and fill in for a colleague and write a Windows script that will run on server #2 and do:

1) Connect and authenticate to remote server #1 from server #2

2) Copy only files from server #1 that match files named like so:

Monthly_Review[1001-8754].journal

3) Move those files to a path D:/Path/NotIntegrated on server #2

I am not a Windows server admin and have been working with Linux for years so any suggestions/help to get me going would be great.

Thanks

UPDATE Seems that PowerShell is the right tool for this task. (Thanks to @Ryan Ries) I am testing locally on Windows XP which seems to only work with PowerShell 1 so the PowerShell 3 script below won't run on PowerShell 1. How can I change this to run on PowerShell 1?

$source = "C:\Users\Me\" 
$destination ="C:\Users\Me\Processed\"

if(-not(Test-Path $destination)){mkdir $destination | out-null}

foreach($i in Get-Children -Path $source -Recurse)
{
if(($i.Name -notmatch "Monthly_Review[\d\d\d\d-\d\d\d\d].journal") -and (-not $i.PsIsContainer))
{
    continue;
}

Copy-Item -Path $i.FullName -Destination $i.FullName.Replace($source,$destination).Trim($i.Name)
}

Answer 1

Powershell. You didn't mention whether the servers are in an AD domain or not. Authentication would be seamless in that situation, but I'm guessing they're not domain joined, so you have to supply credentials in your script, unless you want to type in the creds manually.

First store a password to a file like this:

Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File password.txt

The password will be obfuscated, but it's not encrypted. But that's still a little better than plain text. Then in your script, read the password in from that file and use it to authenticate to your other server.

$PW = Get-Content password.txt | ConvertTo-Securestring
$Creds = New-Object -Typename System.Management.Automation.PSCredential -Argumentlist "SERVER02\Administrator",$PW
ForEach ($_ In $(Get-ChildItem C:\ -Recurse -File | Where-Object { $_.Name -match "myfile_\d\d\d\d-\d\d\d\d.journal" }))
{
    Copy-Item $_ -Destination \\SERVER02\D\Path\NotIntegrated -Credential $Creds
}

This example was written in PS 3. You might not have PS 3 so you might have to adjust the script a little. For instance, I think the -File switch on the Get-ChildItem cmdlet is new in PS 3.

edit: Moved a parenthsis

edit 2: (OP you might not care about this, this is more for tony roth's followup question.) There are benefits of the System.Security.SecureString class over regular System.Strings but they pertain to securing the data and reducing its attack surface while it is in memory (e.g., a process memory dump would not expose your SecureStrings.) But writing data that was in a SecureString out to disk is a hack in my opinion and not the way SecureStrings were really meant to be used.

SecureStrings use a symmetric key (that also is not stored in that processes' memory) to encrypt and decrypt the data. I believe that key is gotten by a call to advapi32.dll, using the infamous SystemFunction041. That implies to me that the system's bootkey is involved. If the key used for SecureStrings was just the bootkey or derived from the bootkey, then that means the SecureString could be decrypted by anyone on that machine with sufficient permissions. But I wonder if the SecureString key is the system bootkey combined with the user's password hash? Again, we could figure that out pretty easily too if that is the case. (Look up DPAPI key management for further research.)

If you take your text file to another machine, even another machine which you logged on to with the same username and password, you will find that your text file is now useless. You have to generate a new one for each new machine. I think that reinforces my hypothesis about the bootkey being involved because it's unique on each system. But user A and user B on the same machine cannot decipher one another's text files, so it must use some user-specific data in addition to machine-specific data to come up with the key.