launch executable on remote node

[skinnedknuckles]

Management Node:

CentOs 7.1

Ansible 2.1

Remote Node:

Windows 7

Powershell 3.0

How do I launch an executable on a remote node running Windows 7?  As I understand win_scheduled_task only works with Windows Server 2012 and win_nssm is only for startup services.  Is there any other way do do this?  If not, is there any way to access the Invoke-Command option of Powershell?  I suppose a module could be written to do that but I'm new to python and doubt I could pull it off.

Thanks,

Jonathan

[J Hawkesworth]

You can use the raw module to run console applications.  Things that start a gui may not start due to the lack of an interactive user.

- name: import a registry file
  raw: "reg.exe IMPORT C:\\settings.reg"

(by the way, don't the above, use win_regedit or win_regmerge instead - just an example of running an .exe which is available on the PATH)

Hope this helps,

Jon

[skinnedknuckles]

Is it possible to launch a web service that would in turn launch a gui executable?

[J Hawkesworth]

I wouldn't know for sure but it would be unusual.  Usually web services have some kind of client which can be launched independently from a web service.

When you are doing things via winrm, its my understanding that there is no interactive user session, meaning there's no gui associated with the commands being run.  Not a problem for command line programs that communicate via stdout and stderr, but if you only have a gui then that's an issue.

What are you trying to achieve?

You could, for example use net send to send a pop up message to any logged on users who do have interactive sessions (and guis to look at).

Jon

[Jonathan Anderson]

With each software upgrade I need to change several parameters in the gui.  I have a console ap that can do this by sending tcp/ip commands to the gui.  But in order for this to happen the gui must be opened after the new version has been installed.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/YyTvvuoOXEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d78f87ee-5f89-4fdf-8cc9-27116565760b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[skinnedknuckles]

With each software upgrade I need to change several parameters in the gui.  I have a console ap that can do this by sending tcp/ip commands to the gui.  But in order for this to happen the gui must be opened after the new version has been installed.

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote:

[J Hawkesworth]

Hmm.  It sounds like the gui app could do with being split up into a windows service with a separate client app for the gui interface.

I have encountered older windows apps which run as services but also present a GUI.  For security reasons Microsoft have discouraged this for years now but I put a bit in my talk about working with such things at Ansiblefest London earlier this year.  Slides are here: http://www.slideshare.net/jhawkesworth/ansible-20-windows-and-no-powershell-this-year-i-promise-ansiblefest-london-2016 and audio here https://www.ansible.com/ansible-2-windows

The above won't help if the app isn't a service though - I think a bit of re-engineering might be needed - unless anyone else has some suggestions?

Jon

[skinnedknuckles]

I have tried starting a new process from inside a .net console application called by ansible but it didn't work.  That process should have it's own thread right?  The process shows up momentarily on the Task Manager and then disappears.  Alternatively I could reboot if there was some way to get through the Windows login process after rebooting.  That would work as well.

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote:

[Matt Davis]

You have to do some extra semi-complex magic when launching the process to break out of the winrm "jail"- otherwise anything you start will be nuked when your winrm session ends (by WinRM design, not Ansible's). I'm building said magic into Ansible for 2.2 to support async tasks on Windows (among other things), and I'll probably expose it on win_shell/win_command as well.

Not sure what you mean by "get through the Windows login process", but have you looked at win_reboot?

[skinnedknuckles]

The program I'm trying to launch starts up automatically after the user logs-in which could possibly be part of a solution for me.  But I can't depend on any user doing that for me so I would have to automate the login and I don't see how win_reboot can do that.

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote:

[J Hawkesworth]

This script can set up auto logon for a user.

http://andyarismendi.blogspot.co.uk/2011/10/powershell-set-secureautologon.html

I have a role that runs this script and then calls win_reboot to make the autologon happen.

Hope this helps,

Jon

[skinnedknuckles]

Is your role on Ansible Galaxy?  I searched for your name but came up with nothing.  Do you use another name for your Galaxy contributions or where can I find the role you mentioned?

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote:

[skinnedknuckles]

I tried converting my password to a secureString by using "ConvertTo-SecureString" commandlet of powershell like this.

  - name Convert password to secure string

    raw: ConvertTo-SecureString "password" -AsPlainTest -Force

    register: result

  - set_fact: ssPassword={{result.stdout_lines.0}}

  - name Setup Auto Reboot

    script: Set-SecureAutoLogon.ps1 "{{userName}}" "{{ssPassword}}" "acme" "1" "true"

Then when I run it I get "Cannot process argument transformation non parameter "Password" Cannot convert the System.SecuritySecureString value of type System.String to type System.Security.SecureString"

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote:

[J Hawkesworth]

Hi,

Sorry role not shared anywhere right now.  Keep meaning to put stuff on galaxy but haven't found the time.

My apologies, looking at the code I'd forgotten that I'd tweaked the powershell script so I could pass in plaintext password.  I doubt a SecureString would be serializable.

I think the only bit I changed was at the start of the process section.  Instead of this

process {

 

    try {

        $ErrorActionPreference = "Stop"

         

        $decryptedPass = [Runtime.InteropServices.Marshal]::PtrToStringAuto(

            [Runtime.InteropServices.Marshal]::SecureStringToBSTR($Password)

        )

I have this

process {

 

    try {

        $ErrorActionPreference = "Stop"

 
        $secPass = ConvertTo-SecureString -String $Password -AsPlainText -Force        

        $decryptedPass = [Runtime.InteropServices.Marshal]::PtrToStringAuto(

            # [Runtime.InteropServices.Marshal]::SecureStringToBSTR($Password)


            [Runtime.InteropServices.Marshal]::SecureStringToBSTR($secPass)

        )

Hope that helps,

Jon

[skinnedknuckles]

I tried this and it worked fine but now my ansible profile is all messed up and many other tasks in my playbook are failing.  My USERPROFILE is supposed to be C:\\Users\\ansibleAdmin but now it shows up as C:\\Users\\ansibleAdmin.DOMAIN or sometimes C:\\Users\\Temp.

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote:

[J Hawkesworth]

Sorry to hear this, hope you can go back to a snapshot or similar?

Can't really think why it would be different.

I run the script like this:

- name: set auto logon
  script: "setSecureAutoLogon.ps1 -Username {{ automation_user }} -Domain {{ windows_domain_name }} -Password {{ automation_password }}"

Jon

[skinnedknuckles]

I tried a simpler powershell script and it seems to work fine.

 Param(

        [string]$DefaultDomainname,

        [String]$DefaultUsername,

        [String]$DefaultPassword

    )

    Begin

    {

        #Registry path declaration

        $RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

    }

    

    Process

    {

        try

        {

            #setting registry values

            Set-ItemProperty $RegPath "AutoAdminLogon" -Value "1" -type String  

            Set-ItemProperty $RegPath "DefaultDomainName" -Value $DefaultDomainname -type string

     Set-ItemProperty $RegPath "DefaultUsername" -Value "$DefaultUsername" -type String  

            Set-ItemProperty $RegPath "DefaultPassword" -Value "$DefaultPassword" -type String

         }

        catch

        {

            Write-Output "An error had occured $Error"

            

        }

    }

    

    End

    {

        

        #End

    }

On Wednesday, May 11, 2016 at 10:01:52 AM UTC-5, skinnedknuckles wrote: