Failed attempt #2
on another remote computer, i use the invoke-command and pass the same credentials. invoke-command uses WinRM.
Successful attempt #1
Like I mentioned, I’m able to install by locally logging in.
Successful attempt #2
on another remote computer, i use enter-psession
On both failed attempts, the visual studio creates a folder in the %temp% drive and then deletes it and the bootstrapper and setup process terminates. Visual studio will kickoff a bootstrap process, then another vs_setup_process, and then a bunch of windows installer process. I don’t think these processes are getting the right permissions?
Any ideas? Am I using “become” right? Sorry, first time using ansible.
P.S. I really want to avoid psexec and installing an agent just to do an install
Just a few things to note, you don’t need to set the task directory become, become_method, become_user if you have set the vars as well. Variable > than task directives when it comes to precedence.
If the initial exe is then starting up another executable and exits immediately it makes sense that it wuld come back ok but then kill the WinRM session and subsequently all child processes, like the newly spawned installer.
I would try and add ‘async: 600’ to the task to see if that works for you. Async slightly changes the type of session the module is run in and it may be enough to get things working for you but there’s no guarantees.
If I get some time I might try this out but I can’t do it right now.
I found some time to play around with this a bit more. It turns out the initial installer spawns multiple processes and doesn’t actually wait until it is finished. This causes the parent WinRM process to close it’s shell which has the side affect of killing any children it spawns.
It’s weird behaviour from the installer as it should be waiting until all the installed processes have finish before finishing but this isn’t the case. The reason why it works when you run locally or through ‘Enter-PSSession’ is because those sessions are persistent, whereas Ansible and ‘Invoke-Command’ will close that session as soon as it’s command is finished.
Luckily using async will allow you to escape this behaviour, using the following playbook you can install VS and wait until the installer has actually completed. It uses async on the first task so that the spawned installer is not killed when WinRM exits and then waits until it is complete in the 2nd task. Become isn’t needed for this task, you just need to escape the WinRM job boundary which is what async is for.
Thank you Jordan! I just tried the suggestion and it works great! I agree, the installer is terrible to begin with. I initially wanted to do a chocolatey package but it was overwhelmingly even more complex too learn for this type of installer. I really appreciate your help and test