Copie e mova arquivos de um servidor para outro no Windows Server

1

Pediram-me para entrar e preencher um colega e escrever um script do Windows que seria executado no servidor # 2 e fazer:

1) Conecte-se e autentique no servidor remoto nº 1 do servidor nº 2

2) Copie somente arquivos do servidor nº 1 que correspondam a arquivos assim chamados:

Monthly_Review[1001-8754].journal

3) Mova esses arquivos para um caminho D: / Path / NotIntegrated no servidor # 2

Eu não sou um administrador de servidor do Windows e tenho trabalhado com o Linux há anos, portanto, qualquer sugestão / ajuda para me fazer ir seria ótimo.

Obrigado

UPDATE Parece que o PowerShell é a ferramenta certa para essa tarefa. (Graças a @Ryan Ries) Estou testando localmente no Windows XP, que parece funcionar apenas com o PowerShell 1, portanto, o script do PowerShell 3 abaixo não será executado no PowerShell 1. Como posso alterar isso para ser executado no 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)
}
    
por Slinky 10.04.2013 / 12:47

1 resposta

1

Powershell. Você não mencionou se os servidores estão em um domínio do AD ou não. A autenticação seria perfeita nessa situação, mas suponho que eles não são associados ao domínio, portanto, você precisa fornecer credenciais em seu script, a menos que queira digitar os credenciais manualmente.

Primeiro, armazene uma senha em um arquivo como este:

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

A senha será ofuscada, mas não criptografada. Mas isso ainda é um pouco melhor do que texto simples. Em seguida, no seu script, leia a senha desse arquivo e use-a para autenticar em outro servidor.

$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
}

Este exemplo foi escrito em PS 3. Você pode não ter o PS 3, então talvez seja necessário ajustar o script um pouco. Por exemplo, acho que a opção -File no cmdlet Get-ChildItem é nova na PS3.

Editar: movido um parêntese

edite 2: (OP você pode não se importar com isso, isso é mais para a questão de seguimento de tony roth.) Existem benefícios da classe System.Security.SecureString sobre System.Strings regulares, mas eles pertencem a proteger os dados e reduzir sua superfície de ataque enquanto está na memória (por exemplo, um dump de memória de processo não exporia seus SecureStrings.) Mas gravar dados que estavam em um SecureString em disco é uma invasão na minha opinião e não a forma como SecureStrings era realmente usado .

O SecureStrings usa uma chave simétrica (que também não é armazenada na memória desse processo) para criptografar e descriptografar os dados. Eu acredito que a chave é obtida por uma chamada para advapi32.dll, usando o SystemFunction041 infame. Isso implica para mim que a tecla de boot do sistema está envolvida. Se a chave usada para SecureStrings fosse apenas a chave de inicialização ou derivada da chave de inicialização, isso significa que o SecureString poderia ser descriptografado por qualquer pessoa nessa máquina com permissões suficientes. Mas eu me pergunto se a chave SecureString é a chave de inicialização do sistema combinada com o hash de senha do usuário? Mais uma vez, poderíamos descobrir isso muito facilmente também, se for esse o caso. (Procure o gerenciamento de chaves da DPAPI para mais pesquisas.)

Se você levar seu arquivo de texto para outra máquina, mesmo para outra máquina com a qual você tenha feito logon com o mesmo nome de usuário e senha, descobrirá que seu arquivo de texto agora é inútil. Você tem que gerar um novo para cada nova máquina. Eu acho que isso reforça minha hipótese sobre o bootkey estar envolvido porque é único em cada sistema. Mas o usuário A e o usuário B na mesma máquina não podem decifrar os arquivos de texto um do outro, portanto, ele deve usar alguns dados específicos do usuário além dos dados específicos da máquina para criar a chave.

    
por 10.04.2013 / 14:52