Packer: No output returned from PowerShell provisioner when elevated

[matt-richardson]

When I use the PowerShell provisioner, when using the elevated_user and elevated_password parameters, the output of the provisioner is not returned to the host.

Interestingly, it appears the code is there to read the scheduled task output and log it, but it never appears.

• Packer version from packer version

0.12.0

• Host platform

macOS Sierra 10.12.1

• Debug log output from PACKER_LOG=1 packer build template.json.
  https://gist.github.com/matt-richardson/8870b30c50edef21e3839760c21faa24#file-packer-log
• The _simplest example template and scripts_ needed to reproduce the bug.
  https://gist.github.com/matt-richardson/8870b30c50edef21e3839760c21faa24#file-packer-json

What I see: https://gist.github.com/matt-richardson/8870b30c50edef21e3839760c21faa24#file-stdout-log
What I expect to see:

...
==> amazon-ebs: Provisioning with shell script: /var/folders/3k/dc8q184975n75tv39hb6s0700000gn/T/packer-powershell-provisioner046243266
Hello. This output should appear in the log during the packer run
==> amazon-ebs: Stopping the source instance...
...

[mwhooker]

confirmed still happening in 0.12.2

[matt-richardson]

Hi @mwhooker, is that confirmed fixed? Or confirmed broken?

[mwhooker]

@matt-richardson broken 😆

[mwhooker]

@taliesins i wonder if you have any insights into this. I think this behavior might have changed with 4b394c8563dc66db875d12416d0575ee56ae8dd7

[taliesins]

We are slurping the results and then echoing them to output. Maybe it's a race condition. I honestly thought this was working.

I think we should probably update the elevated powershell approach to match: https://github.com/WinRb/winrm-elevated/blob/master/lib/winrm-elevated/scripts/elevated_shell.ps1

Then we will use the same approach that Vagrant uses.

[DanHam]

I thought I'd better follow on from the discussions in #4375 here. I've done a bit of digging into this. Long and short, I think we may be chasing a bit of a red herring here...

I think this may be something to do with the adminuser not being set up correctly by those net user... commands. I haven't found the root cause yet but I was thinking it could be something along the lines of the adminuser not having the correct permissions to run a 'scheduled task' (or something similarly weird and wonderful biting us from the squirrelly world of Windows permissions) ...

I am able to reproduce this locally using a virtualbox-iso builder:

• If I set up the adminuser using the net user... commands and then run the elevated powershell provisioner using those credentials I get NO output from the elevated command (as reported).
• If I run the elevated command as the administrative user I set up in my autounattend.xml file I get the output back from the command as expected.

In other words:

• I get back output from the elevated command using my admin user.
• I don't get back any output using the adminuser created in that template.

That tends to suggest to me that there is no problem with Packer per se and hints at the issue being with the set up of that adminuser.

Note: I have reproduced the issue using the amazon-ebs builder (I don't however think this is specific to any particular builder). I also tried reverting the changes made by 4b294c8 to no avail.

[taliesins]

Is the user actually created? When you rdp what do you see.

Is the powershell provisioner the right choice for creating the user. How about https://www.packer.io/docs/provisioners/windows-shell.html

It may be some weird windows uac ballocks blocking powershell.

[matt-richardson]

I haven't looked at this closely lately, but it definitely creates the user, and the scheduled task definitely runs and creates the log file - it just doesn't read it back.

[DanHam]

So my initial suspicions regarding the validity of those net user... commands and the resulting rights of the adminuser to create and run a scheduled task were wrong. The user is created OK. Additionally, opening up Task Scheduler give the 'Last Run Result' of the 'Packer elevated task' as 'The operation completed successfully'. Apologies for that - in my defence I had seen issues with permissions and scheduled tasks previously (User Rights Assignment -> Log on as a batch job).

I've now issued a PR that I hope fixes this. Details in the PR.

[DanHam]

@taliesins Review of the changes in that PR would be much appreciated!

[taliesins]

@DanHam thanks for sorting that bug out 👍