Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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)
}
share|improve this question

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer
    
this statement "The password will be obfuscated, but it's not encrypted" makes it seem worse then it is right? Its encrypted for all intents and purposes except for the user that created it. If users A runs the command "Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File password.txt" The only person that will be able to use this will be user A, user B even if they have access to the password.txt file will not be able to use the pw. –  tony roth Apr 10 '13 at 13:30
    
@tonyroth Edited my answer to address your question –  Ryan Ries Apr 10 '13 at 14:22
    
In this case user b can not decrypt users a's password.txt file. –  tony roth Apr 10 '13 at 14:24
    
Then it must also use some user-specific data as well as machine-specific data to create the key. Incidentally, you can also use your own encryption key with the ConvertTo-SecureString cmdlet. –  Ryan Ries Apr 10 '13 at 14:26

Your Answer

 
discard

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.