Packer: Elevated powershell provisioner in Azure fails

[Poddo]

When running the powershell provisioner on an azure build and specifying an elevated user, the powershell provisioner fails. I have attempted it without elevated user and it succeeds. Which is nice except for when elevation is needed.

I am running this from a macOS 10.13.6 machine but it also fails from centos. Packer version is 1.3.2.

Gist of a simple template, the ps1 file it calls, and the packer_log output.
https://gist.github.com/Poddo/60ac637d706ce38289e7fd15082f84d1

Gist of the created ps1 file it made to schedule the elevated task (this is from a previous run so the UUIDs in this file won't match the previous gist, but they are from the same template)
https://gist.github.com/Poddo/57ae773dd205cea3c365ccee04307651

Edit: I have also tried this locally with vbox and vmware, and it works as expected there

[jborean93]

The lines below give you an indication of what's happening, it's just hard to see.

2018/11/05 14:41:09 ui:     azure-arm: (12,8):UserId:
2018/11/05 14:41:09 ui:     azure-arm: At C:\Windows\Temp\packer-elevated-shell-5be0aace-a7ca-15b2-97ed-6e1e2c97589d.ps1:49 char:1
2018/11/05 14:41:09 ui:     azure-arm: + $f.RegisterTaskDefinition($name, $t, 6, "Administrator", "1fdTVEJAzFV ...
2018/11/05 14:41:09 ui:     azure-arm: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2018/11/05 14:41:09 ui:     azure-arm:     + CategoryInfo          : OperationStopped: (:) [], COMException
2018/11/05 14:41:09 ui:  azure-arm: + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException

I modified the register line to be (and manually changed the stuff to throw the same error)

try {
    $f.RegisterTaskDefinition($name, $t, 6, "...", "...", 1, $null) | Out-Null
} catch [System.Runtime.InteropServices.COMException] {
    throw "COMException while creating scheduled task (HRESULT: 0x$($_.Exception.HResult.ToString("X")): $($_.Exception.Message)"
}

When running again I get a "slightly" more descriptive error

COMException while creating scheduled task (HRESULT: 0x80070534: (12,8):UserId:
At C:\temp\task.ps1:53 char:5
+     throw "COMException while creating scheduled task (HRESULT: 0x$($_. ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (COMException wh... (12,8):UserId::String) [], RuntimeException
    + FullyQualifiedErrorId : COMException while creating scheduled task (HRESULT: 0x80070534: (12,8):UserId:

From there we can see the error code (HRESULT: 0x80070534), converting that to a Win32 Error change 0x8007 to 0x0000, we can see at https://msdn.microsoft.com/en-us/library/cc231199.aspx that 0x00000534 means ERROR_NONE_MAPPED - No mapping between account names and SIDs was done.. This means that the value specified under the UserId XML element and the username part of RegisterTaskDefinition is not a valid username on that host. Looking at your Packer config file, your winrm user is packer and typically Azure renames the builtin Administrator account to the one configured. This would explain why it works on other providers and not Azure.

[SwampDragons]

Thanks @jborean93! @Poddo if @jborean93's advice doesn't help you, I can reopen.

[Poddo]

Yep, this works perfectly. I'll chalk it up to a combo of bad windows errors and me being too frustrated to see clearly. Thanks @jborean93 !

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.