I have two servers:

SVR1 (Windows Server 2008) in LAN - part of domain

SVR2 (Windows Server 2008) in DMZ - workgroup

I need to access SVR2 from SVR1 via command line batch - copy some files and execute sc command to manage services on SVR2. This batch is scheduled so I need to access SVR2 without credentials input.

The only possibility I know is to have the same username and password on both servers but it is not so graceful and it is potential risk.

What is the best approach to solve my problem? It would be the best to do it without third party software.

  • Could you run the batch via Task Scheduler on SVR2 and put your credentials in the Task Scheduler? – Nixphoe Oct 20 '14 at 19:30
  • No, I have to run the batch from SVR1 because of copying files from SVR1. – teo Oct 21 '14 at 4:52

Since SVR1 and SVR2 are not part of the same AD domain, you will need to store credentials for SVR2 somewhere on SVR1 for your automated script to access.

Using WinRM and sufficiently updated Powershell, Powershell Remoting will let you establish a connection from SVR1 to SVR2 and do whatever you can think of on a command line in an automatic fashion.

You can save a password in the Windows Credential Vault using Powershell and your script can access the credentials from the Credential Vault:


I would recommend this as a slightly better way to store credentials. The older, classic way of storing credentials was to do something like this:

read-host -assecurestring | convertfrom-securestring | out-file operationspassword.txt

Then in your script, "decrypt" the password like so:

$pass = Get-Content operationspassword.txt | convertto-securestring
$creds = New-Object -Typename System.Management.Automation.PSCredential -argumentlist "SRV2\admin",$pass

The "encrypted" creds are only decryptable by the same account and on the same machine where they were originally encrypted, so you can't just steal the text representation of the SecureString and use it somewhere else. But it's still kind of unprofessional to store creds this way and I don't really advise it in general.

Also don't forget to modify your Powershell TrustedHosts list to allow connections to the "untrusted" machine... you must do this because you're not using Kerberos or SSL.

That reminds me... use SSL for WinRM connections for better security: http://support.microsoft.com/kb/2019527

Windows 2008 WinRM ports are 80 (HTTP) and 443 (HTTPS).

Microsoft soon realized that those ports were kind of already in use, and so:

Windows 2008 R2 and above WinRM ports are 5985 (HTTP) and 5986 (HTTPS).

  • psexec.exe will allow you to launch cmd.exe on a remote system. My main concern is having to store the password in an easily-readable text file somewhere. – Ryan Ries Oct 21 '14 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.