3

I am trying to develop a custom task using Powershell which needs to use Start-Job -Cred to switch to another user in places. Agent is running as user A and I need to switch to user B. Logging in to the server running the agent as user A and then running the script works fine - the Start-Job switches credentials and runs a scriptblock as user B.

Running exactly the same thing from VSTS in the cloud using the same (on-prem) agent server running the agent as user A fails with the uninformative error:

"The background process reported an error with the following message: ."

I have done more debugging and there is no other error message anywhere. It seems to be related to the -Cred parameter of Start-Job as it makes no difference what is in the script block run and if I remove the -Cred parameter, it's also fine.

  • User A is in the Adminstrators group on the server running the agent
  • Agent runs as user A

Any ideas?

PLK
  • 389
  • 2
  • 13
  • Try wrapping your code in a try/catch block and see if an error is being reported to the shell. Make sure you add `-EA Stop` to the end of your command. In your catch block, you can use `Write-Output "[$($_.Exception.GetType().FullName)] $($_.Exception.Message)"` – Maximilian Burszley Jul 20 '17 at 15:03
  • Already tried that - can't get any more informative error than the one I mentioned. The error seems to be triggered by the `Receive-Job` in the `Start-Job | Wait-Job | Receive-Job` because the `Start-Job` fails for some reason. – PLK Jul 20 '17 at 15:05
  • Is the executionpolicy the same on the cloud device? – Maximilian Burszley Jul 20 '17 at 15:26
  • I am not sure what you mean - how would I check that? – PLK Jul 20 '17 at 15:31
  • `Get-ExecutionPolicy` – Maximilian Burszley Jul 20 '17 at 15:33
  • I can check but as I mentioned, this is all on the same server anyway. The difference is that the script is run via the VSTS agent service as user A (fails) instead of directly as user A logged on interactively (works). – PLK Jul 20 '17 at 15:42
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/149737/discussion-between-theincorrigible1-and-plk). – Maximilian Burszley Jul 20 '17 at 15:49

2 Answers2

1

Try it with Invoke-Command, for example (output current user name):

$mypwd = ConvertTo-SecureString -String "[password, could use variable]" -Force -AsPlainText
$Cred = New-Object System.Management.Automation.PSCredential('[user name]',$mypwd)
$scriptToExecute = 
{
$VerbosePreference='Continue'
Write-Output "$env:UserName"
# Write-Verbose "Verbose" 4>&1
}
$b = Invoke-Command -ComputerName localhost -ScriptBlock $scriptToExecute -Credential $Cred
Write-Output "Content of variable B"
Write-Host $b
starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53
0

Based on your experiences, your credentials are not being passed properly. Try this method and insert it into your script:

Outside of your script, get the securestring object-

Read-Host -AsSecureString | ConvertFrom-SecureString

Take the output of this command (where you enter the password), and put it before your start-job-

$Secure = ConvertTo-SecureString -String 'above output'
$Cred = New-Object System.Management.Automation.PSCredential('Username',$Secure)
Start-Job -Credential $Cred

The SecureString can be reversed by someone with know-how, but if the script and/or account is secure, then that doesn't matter.

Maximilian Burszley
  • 18,243
  • 4
  • 34
  • 63
  • Hmm, I can't do that, everything has to come from inside the script but I am converting to a secure string from plain text (retrieved from a secure password vault etc.) and then passing the `$Cred` exactly as you mention. – PLK Jul 21 '17 at 10:38
  • @PLK Are you converting the plain text using the ConvertTo-SecureString cmdlet? – Maximilian Burszley Jul 21 '17 at 15:13