Powershell: Invoke-Command under non-current user

I want to run a command under a different user (like RunAs but using Powershell) however:
Invoke-command -ScriptBlock {netsh winhttp show proxy} -Credential user@domain.loc

Open in new window

gives this error:
Invoke-Command : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:4
+ icm <<<<  -ScriptBlock {netsh winhttp show proxy} -Credential user@domain.loc
    + CategoryInfo          : InvalidArgument: (:) [Invoke-Command], ParameterBindingException
    + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.InvokeCommandCommand

Open in new window

How to make it work?
Thank you.
LVL 1
PavelTMNAsked:
Who is Participating?
 
QlemoConnect With a Mentor Batchelor, Developer and EE Topic AdvisorCommented:
Did some tests and PS debugging, and it seems as if the help is incorrectly stating you can provide a scriptblock, credentials and omit the computername.

Debugging
First find out available parameter sets and their parameters:
get-command invoke-command | 
  select -Expand parametersets | 
  % {
    $set = $_.Name
    $_.Parameters |
       % { write-host $set, $_.Name -fore $(if ($_.IsMandatory) { "Red" } else { "White" }) }
  }

Open in new window

InProcess ScriptBlock
InProcess InputObject
InProcess ArgumentList
InProcess Verbose
InProcess Debug
InProcess ErrorAction
InProcess WarningAction
InProcess ErrorVariable
InProcess WarningVariable
InProcess OutVariable
InProcess OutBuffer
FilePathRunspace Session
FilePathRunspace ThrottleLimit
FilePathRunspace AsJob
FilePathRunspace HideComputerName
FilePathRunspace JobName
FilePathRunspace FilePath
FilePathRunspace InputObject
FilePathRunspace ArgumentList
FilePathRunspace Verbose
FilePathRunspace Debug
FilePathRunspace ErrorAction
FilePathRunspace WarningAction
FilePathRunspace ErrorVariable
FilePathRunspace WarningVariable
FilePathRunspace OutVariable
FilePathRunspace OutBuffer
Session Session
Session ThrottleLimit
Session AsJob
Session HideComputerName
Session JobName
Session ScriptBlock
Session InputObject
Session ArgumentList
Session Verbose
Session Debug
Session ErrorAction
Session WarningAction
Session ErrorVariable
Session WarningVariable
Session OutVariable
Session OutBuffer
ComputerName ComputerName
ComputerName Credential
ComputerName Port
ComputerName UseSSL
ComputerName ConfigurationName
ComputerName ApplicationName
ComputerName ThrottleLimit
ComputerName AsJob
ComputerName HideComputerName
ComputerName JobName
ComputerName ScriptBlock
ComputerName SessionOption
ComputerName Authentication
ComputerName InputObject
ComputerName ArgumentList
ComputerName CertificateThumbprint
ComputerName Verbose
ComputerName Debug
ComputerName ErrorAction
ComputerName WarningAction
ComputerName ErrorVariable
ComputerName WarningVariable
ComputerName OutVariable
ComputerName OutBuffer
FilePathComputerName ComputerName
FilePathComputerName Credential
FilePathComputerName Port
FilePathComputerName UseSSL
FilePathComputerName ConfigurationName
FilePathComputerName ApplicationName
FilePathComputerName ThrottleLimit
FilePathComputerName AsJob
FilePathComputerName HideComputerName
FilePathComputerName JobName
FilePathComputerName FilePath
FilePathComputerName SessionOption
FilePathComputerName Authentication
FilePathComputerName InputObject
FilePathComputerName ArgumentList
FilePathComputerName Verbose
FilePathComputerName Debug
FilePathComputerName ErrorAction
FilePathComputerName WarningAction
FilePathComputerName ErrorVariable
FilePathComputerName WarningVariable
FilePathComputerName OutVariable
FilePathComputerName OutBuffer
Uri Credential
Uri ConfigurationName
Uri ThrottleLimit
Uri ConnectionUri
Uri AsJob
Uri HideComputerName
Uri JobName
Uri ScriptBlock
Uri AllowRedirection
Uri SessionOption
Uri Authentication
Uri InputObject
Uri ArgumentList
Uri CertificateThumbprint
Uri Verbose
Uri Debug
Uri ErrorAction
Uri WarningAction
Uri ErrorVariable
Uri WarningVariable
Uri OutVariable
Uri OutBuffer
FilePathUri Credential
FilePathUri ConfigurationName
FilePathUri ThrottleLimit
FilePathUri ConnectionUri
FilePathUri AsJob
FilePathUri HideComputerName
FilePathUri JobName
FilePathUri FilePath
FilePathUri AllowRedirection
FilePathUri SessionOption
FilePathUri Authentication
FilePathUri InputObject
FilePathUri ArgumentList
FilePathUri Verbose
FilePathUri Debug
FilePathUri ErrorAction
FilePathUri WarningAction
FilePathUri ErrorVariable
FilePathUri WarningVariable
FilePathUri OutVariable
FilePathUri OutBuffer

Open in new window

Then see how parameters are bound:
Trace-Command -Option all parameterbinding -PSHost { invoke-command -scriptblock { write-host "1" } -credential $cred }

Open in new window

which outputs
BIND NAMED cmd line args [Invoke-Command]
    BIND arg [ write-host "1" ] to parameter [ScriptBlock]
        COERCE arg to [System.Management.Automation.ScriptBlock]
            Parameter and arg types the same, no coercion is needed.
        Executing VALIDATION metadata: [System.Management.Automation.ValidateNotNullAttribute]
        BIND arg [ write-host "1" ] to param [ScriptBlock] SUCCESSFUL
    BIND arg [System.Management.Automation.PSCredential] to parameter [Credential]
        Executing DATA GENERATION metadata: [System.Management.Automation.CredentialAttribute]
            result returned from DATA GENERATION: System.Management.Automation.PSCredential
        COERCE arg to [System.Management.Automation.PSCredential]
            Parameter and arg types the same, no coercion is needed.
        BIND arg [System.Management.Automation.PSCredential] to param [Credential] SUCCESSFUL
BIND POSITIONAL cmd line args [Invoke-Command]
Remaining valid parameter set: ComputerName
Remaining valid parameter set: Uri

Open in new window

(the remaining output is for displaying the error message).
Obviously (and according to http://connect.microsoft.com/PowerShell/feedback/details/676872/invoke-command-parameter-bug-parameter-set-cannot-be-resolved) PS cannot decide which parameter set to apply. That is a definition error, since there should be a difference in the mandatory parameters for different parameter sets.

The only workaround is to use -ComputerName localhost (or -ComputerName 127.0.0.1), but that requires Remoting (WinRM), and it is significantly slower compared to the -Scriptblock-only command.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Strange, that should work. Try if enclosing the user name in single or double quotes helps.

A parameter set is a combination of parameters needing to be used together. The -Scriptblock allows for 4 different parameter sets, which of two contain -Credential . You should get that error only if you mix different sets, like using -Scriptblock and -FilePath together.
However, the error message showing ICM while you use Invoke-Command is suspicious ... Are you showing the real command you've used?
0
 
PavelTMNAuthor Commented:
Try if enclosing the user name in single or double quotes helps
No, it doesn't.
showing ICM while you use Invoke-Command is suspicious
ICM is an alias for Invoke-Command. I made a mistake when copy-pasting.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Of course, icm is the alias, but I suspected we do not see all you've done. If that is the only mistake you made, I'm clueless, because it should work and does here. We can be sure it is PowerShell 2.0?
0
 
PavelTMNAuthor Commented:
That one-liner is all there is.
The version is 2
PS C:\Windows\system32> $PSVersionTable

Name                           Value
----                           -----
CLRVersion                     2.0.50727.5466
BuildVersion                   6.1.7601.17514
PSVersion                      2.0
WSManStackVersion              2.0
PSCompatibleVersions           {1.0, 2.0}
SerializationVersion           1.1.0.1
PSRemotingProtocolVersion      2.1

Open in new window

Could be GPO settings but on a domain-independent system it's the same.
0
 
SubsunCommented:
Are you entering the correct credentials when prompted?
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Let's perform some tests, and see if icm acts as expected:
* use only -scriptblock, without -credentials
* use a PSCredential object for -credentials:
-Credentials (new-object System.Management.Automation.PSCredential(
  'user@domain.loc', 
  ConvertTo-SecureString 'Password' -AsPlainText -Force)

Open in new window

0
 
footechCommented:
@Qlemo - Thanks!  I learned something about PS debugging today.  :)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.