Konstantin Vlasenko

An engineer is someone who can make for a dollar what any fool could make for two. – Alan Kay

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

http://ow.ly/16JRWa

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

snap0099[5]

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


snap0100

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

Enter-PSSession -ComputerName sharepoint.contoso.com -Authentication CredSSP -Credential $crd

3. Load SharePoint Windows PowerShell Snap-in

Add-PSSnapin Microsoft.SharePoint.Powershell

3 responses to “Re-Post: #SharePoint 2010 with Windows #PowerShell Remoting Step by Step

  1. Konstantin Vlasenko March 8, 2010 at 11:37

    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.

  2. Pingback: SharePoint 2010: Como administrar tus despliegues con PowerShell de forma remota! « Pasión por la tecnología…

  3. Pingback: SharePoint 2010: Como administrar tus despliegues con PowerShell de forma remota! - Blog del CIIN

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: