Run powershell script using another account

In my last post i wrote about how to run a powershell script block in the background. It could happen that this script block should be run by another account. Such a case could be that we are running our Powershell script using an normal windows user account but the given script block which installs something intersting to the given machine needs administrator privileges to be successfull.

In that case we need a credential variable which stores this account information with admin privileges. In our example we have the account information data in clear text (for example you import them from a csv).

So we need to convert the password clear text string into securestring by using the following command:

$secpasswd = ConvertTo-SecureString $password -AsPlainText -Force

Then we are able to create our credential object:

$credential = New-Object System.Management.Automation.PSCredential ($username, $secpasswd)

or just simply use the $credential = get-credential command to get the information on the fly. NOTE that the $username is in the next format: domain\username

Okay, we have the Credential info. Let’s use it to run our script block:

$Param1 = "Hello World!"
$Param2 = "Hello Universe!"
$Arguments = @($Param1, $Param2)
$Job = Invoke-Command -ComputerName $env:COMPUTERNAME -Credential $credential -ArgumentList $Arguments -ScriptBlock
Param (
Write-Host -ForegroundColor "Yellow" $World
Write-Host -ForegroundColor "Yellow" $Universe
Write-Host -ForeGroundColor "Green" "Let's sleep a bit!"
Start-Sleep -s 6000
Write-Host -ForeGroundColor "Green" "Once more"
Write-Host -ForegroundColor "Yellow" $World
Write-Host -ForegroundColor "Yellow" $Universe
$ScriptBlockOutput = $Error
#Go forward in the main script

In that case a new Powershell window will start using the $credential account information and all the information will appear in the new window while the original window seems to be frozen.

In my next post i would like to write about progress indication in this situation.

A real example for this case could be the next:
1. you have a normal user account which starts the powershell script
2. an application (for example MOSS 2010 binaries should be installed that’s why we use $credential information
3. as the installation takes long time to finish you have to show some progress info for the user (keep him sure that the installation is in progress in the background)

SeeYou 🙂


7 thoughts on “Run powershell script using another account”

  1. I have a question that’s so basic it might be stupid, but I can’t seem to find a direct answer: What do I have to do to use Powershell V2 with SharePoint 2007? Is it even possible?


    1. Hey Keith,

      You can normally use Powershell v2 for managing sharepoint content. If you run Powershell on the same machine as the Sharepoint you need just to import a dll then you can start your scripting 🙂 please find how to connect sharepoint locally by following this link.

      If you want to connect your sharepoint site remotely (for eg from a client machine) please follow this post.

      If you need more assistance just ask for 🙂 seeyou

      1. Hello Acsoma,

        Thank you for the quick response. I log directly into the server which hosts the MOSS 2007 Central Admin, so that’s where I’ll be running Powershell. What’s the name of the .dll I need to import, I couldn’t find a link to follow in your message.


  2. Hello Keith,

    This is the first line in your case of any powershelling in the PWS window:


    This will import the Sharepoint namespace/dll. Then you can connect to your Sharepoint site, web, list etc. On how please follow this post.
    In that post you will have a view on how to handle any listitem. 🙂
    Of course the account you used when opening the PWS window should have the right to connect the Sharepoint portal itself as well.


  3. The script gives the error:
    parameter set cannot be resolved using the specified named parameters

    This is because it cannot tell whether i want to use Invoke-Command (computerName) or (URI), based on the parameters provided.
    Both have -Credential as an optional, and -ScriptBlock as the only required.

    So i added -ComputerName $env:COMPUTERNAME and it is OK now (This is being ran on a local machine.)

    $secpasswd = ConvertTo-SecureString $password -AsPlainText -Force
    $credential = New-Object System.Management.Automation.PSCredential ($username, $secpasswd)

    # $Job = Invoke-Command -Credential $credential -ScriptBlock {
    $Job = Invoke-Command -Credential $credential -ComputerName $env:COMPUTERNAME -ScriptBlock {

    1. Thanks for the Reply. Originally i used PS session for this task. i Rechecked the sample-script and i have to accept your comment. I update the sample script using the -computer parameter.

      using PS session you can have the next lines:
      $s = new-pssession -computername ‘.’ -Name ‘Install’ -Credential $Credential

      in case of using session the ps remoting should be enabled: Enable-PSRemoting -Force | Out-Null
      And from now you can use the invoke-command:

      $Job = Invoke-Command -Session $s -AsJob -ArgumentList $Arguments -ScriptBlock `
        $output = "script block output"

      And you can get value of a given variable out from the script block using the following line:
      $JobOutput = invoke-command -session $s -scriptblock {$Output}

      to stop PSRemoting use:
      Get-PSSession | where {$_.Name -eq ‘Install’} | Remove-PSSession

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s