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:
https://gallery.technet.microsoft.com/scriptcenter/How-to-add-credentials-to-c8e9bd5f
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).
