We gained a ton of improvemnts to WinRM error handling in
https://github.com/mitchellh/vagrant/pull/4943, but we also got one bug.
The new code raises an exception when `winrm_info` does not return right
away. This was preventing us from catching the retry/timout logic that's
meant to wait until boot_timeout for the WinRM communicator to be ready.
This restores the proper behavior by rescuing the WinRMNotReady
exception and continuing to retry until the surrounding timeout fires.
Leaving around plaintext username and passwords in a script on a box isn't the best from a security standpoint. This change ensures the scheduled task wrapper script for WinRM doesn't leave these around on the box, and instead passes them to the script as arguments.
StopOnIdleEnd was set in the task definition for elevated/privileged
windows guest scripts. This setting:
> specifies that the task stops when the idle condition ceases to be true [1]
The "idle condition" is something that Windows periodically checks for,
and it's defined by a bunch of criteria like user presence/absence, CPU
/ IO idle time, etc. [2]
Telling our provisioner to stop the task if the "idle condition" ceases
to be true is a recipe for some sporadically stopped tasks, which seems
like precisely the behavior being reported in #5362.
I'm pretty sure this fixes#5362
[1] https://msdn.microsoft.com/en-us/library/cc248332.aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383561%28v=vs.85%29.aspx
When the winrm communicator executes a command in an elevated shell,
this patch causes it to escape double quotes.
This is necessary as the first line in the file that it produces and
then executes it puts the command into a variable called command that
is delimited by double quotes.
Command failures include the stdout and stderr in the error message just like the SSH communicator.
Its now possible to specify only an error_class and have that use the correct error_key by default.
Running Windows guest commands through a scheduled task were not returning the correct exit codes, they were only returning 1 or 0. This has negative consequences especially for Puppet which can return an exit code of 2 for partial success.
Since we're running an executable from inside a powershell encoded command we need to ensure we explicitly propagate the exit code to the original caller just like a regular PowerShell script - in this case cmd /c which in return is called from a scheduled task.
Elevated command line is now rendered to a script which is uploaded to the guest and executed. This allows the command line itself to be less than 100 chars to start the script and any user commands are puts into the script which has unlimited* length.