Re-Post: #SharePoint 2010 with Windows #PowerShell Remoting Step by Step

Enable Remoting support on SharePoint Server box

  1. Enable Windows PowerShell Remoting
  2. Increase memory limit for remote shell (Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000)
  3. Setup CredSSP support

Setup client machine for Remoting

  1. Enable CredSSP support
  2. Store and use credentials for scripting

A credential in Windows PowerShell is a object which contains username (as plain text) and password (as secure string).

First, use the following command to covert password from keyboard input to a secure string in a text file.

Read-Host -AsSecureString | ConvertFrom-SecureString | out-file C:\crd-sharepoint.txt


When you need to create a credential object, read this password (the secure string) from the file and create the credential with the following command:

$pwd = Get-Content C:\crd-sharepoint.txt | ConvertTo-SecureString

then create the credential (replace myusername with your domain\username):

$crd = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "myusername",$pwd


Then you will be able to use this credential in the command line without any dialogue.

Enter-PSSession -ComputerName -Authentication CredSSP -Credential $crd

3. Load SharePoint Windows PowerShell Snap-in

Add-PSSnapin Microsoft.SharePoint.Powershell

3 thoughts on “Re-Post: #SharePoint 2010 with Windows #PowerShell Remoting Step by Step

  1. NOTE: Windows PowerShell Remoting sends your code to the remote system and executes it inside a separate session on that system. The code runs locally, just on a different machine, so, you can remote any command that can run locally. Just make sure the command you want to run really does exist on the remote system. For example, you might have robocopy.exe on your local machine, but you can run it remotely on another system only if it is present on the remote system, too.
    Also, all file paths, variables and locations in your commands are interpreted on the remote system, not your own. So to access folders, they must exist on the remote system.
    Finally, beware of second hop issues that occur when you try to access protected resources, such as file shares. Because you have already authenticated on the remote system, your commands cannot pass your credentials to resources outside the target system. This is why your code cannot “hop” to additional machines or access file shares that require authentication. The following example illustrates an illegal second hop call:
    PS> Invoke-Command { Get-WmiObject Win32_BIOS -ComputerName PC04 } -ComputerName PC01
    In this case, your commands would be transferred to PC01 and executed there. The command would then try to get WMI information from PC04, which requires another authentication and would fail.
    To access different systems from inside a remote system, you must explicitly present new credentials or use advanced techniques such as Delegation or CredSSP to allow the target system to pass your credentials forward.

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 )

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: