Remote commands to drush on Windows server + backend invoke / sql-sync refactor

I'm having trouble configuring winrm, so I have not actually tested this myself yet. :P However, in simulate mode, this patch does appear to generate the correct winrs command to run a drush command remotely on a Windows server, so it just might work. To use, just add 'os' => 'windows', to the site alias for a site running Windows OS, and drush will then use winrs instead of ssh for drush @winserver status and the like.

Note that this patch does not affect sql-sync, which remains unsupported. That issue is being tracked in #1149886: sql dump does not work with windows sql server, which I will hopefully address shortly.

Still needs a bit of documentation (ideally including winrm setup :> ).

Great!

Is there any way to provide a password to winrs non-interactively? Is there any equivalent of ssh key pairs with winrs? Having to enter a password for all remote commands is a serious liability.

I'll look into the double-escaping.

I'm not sure whether the default for an unspecified OS should be the same as the client platform or "Linux". Originally it was always "Linux"; I changed it recently. I think assuming "Linux" is probably better, because then the same alias will work the same way on different machines; it would be inelegant for an alias to change from "Linux" to "Windows" just because you sent it to someone using a different OS than you.

Thanks, moshe.

Winrm comes pre-installed, and in theory is really easy to set up, but none of the config commands work for me -- I get 'permission denied'. I have identified that you need to run your shell as administrator, and the admin must have a non-empty password, but that is insufficient. Once I figure out how to configure it, I'll write up some docs.

Further work on this issue is waiting on #1058874: drush_backend_invoke buffers output till end of command. Show progress., but here are some notes on configuring winrm / winrs.

Before you use winrs, you must configure winrm. On a new install of Windows 7:

1. Log in as an account with administrator access rights.
2. Insure that your account has a password. Assign one if necessary, then log out and log back in again.
3. Right-click on Accessories -> Command Prompt and select run as administrator to open a DOS prompt in administration mode.
4. Run winrm quickconfig and answer "yes" to all prompts.

The output I received from winrm quickconfig is shown below:

C:\Windows\system32>winrm quickconfig
WinRM is not set up to receive requests on this machine.
The following changes must be made:

Set the WinRM service type to delayed auto start.
Start the WinRM service.
Configure LocalAccountTokenFilterPolicy to grant administrative rights remotely
to local users.

Make these changes [y/n]? y

WinRM has been updated to receive requests.

WinRM service type changed successfully.
WinRM service started.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely
 to local users.
WSManFault
    Message
        ProviderFault
            WSManFault
                Message = WinRM firewall exception will not work since one of th
e network connection types on this machine is set to Public. Change the network
connection type to either Domain or Private and try again.

Error number:  -2144108183 0x80338169
WinRM firewall exception will not work since one of the network connection types
 on this machine is set to Public. Change the network connection type to either
Domain or Private and try again.

The errors do not matter; the first two operations were successful, and only the last, "grant administrative rights remotely to local users" (which does not sound like a good idea anyway) failed.

After that, you can set the TrustedHosts config variable to allow your client to connect to your server:

C:\Windows\system32>WinRM set winrm/config/client @{TrustedHosts="*"}
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = *

You can replace the "*" with the fqdn of a specific server if you do not want to open up your configuration to the whole world. (n.b. these instructions are for a dev machine setup on a local network; adequate security precautions are left as the responsibility of the reader.)

At one point, I got my Win7 box into a strange state and could not get any winrm commands to work; I would receive an "Access Denied" error regardless of what steps I tried. Running winrm quickconfig returned an error message that the system was already configured, followed by another "access denied" error. It was reported that winrm could be reset as follows:

winrm invoke restore winrm/config @{}

Unfortunately, this did not work for me; I received the same "access denied" error. Perhaps this command will help in some instances, though.

It appears that installing msysgit is the thing that causes winrs to stop working.

This time, the reset instructions from #6 worked.

This works. Adds capability to specify 'winrs-password' to your site alias. This is documented in examples.aliases.drushrc.inc; however, cmdkey is recommended:

cmdkey.exe /add:your-remotehost.domain.com /user:USERNAME /pass:PASSWORD

Further refactoring backend invoke to make it more reusable (e.g. from sql-sync).

Expanding the scope of the refactoring to include sql-sync, so that remote syncs also use winrs.

Contexts now forwarded via backend invoke per #1185142: drush_invoke_process_args() does not inherit contexts

Upping priority of Windows issues important for drush-5.0.

I went ahead and committed this; it works well on Linux, and all test cases pass. Remote commands on Windows work, sql-sync on Windows may need further adjustment in a future issue, but we're a lot closer.