Hey, Scripting Guy! Tell Me About SharePoint Remoting with Windows PowerShell 2.0 and WinRM

(Note: Today’s Hey, Scripting Guy! Blog post was written by guest scripter, Tome Tanasovski. Tome is a manager of a team of server engineers in New York City. He is a Microsoft Certified Trainer who specializes in SQL Server, SharePoint, and VMWare. He is a contributor to the Windows PowerShell forum and the Hey, Scripting Guy! forum. Tome is a part-time blogger, and is currently organizing the inaugural meeting of a Windows PowerShell User Group in New York City. Thanks, Tome!)

———-

Frustration. Dictionary.com’s fourth definition is “a feeling of dissatisfaction, often accompanied by anxiety or depression, resulting from unfulfilled needs or unresolved problems.”

I think that sums up my early experiences working with the Microsoft Office SharePoint object model interfaces. When Microsoft Office SharePoint Server (MOSS) 2007 was released, I was eager to play. The new workflow engine, cooler searching, and a more flexible structure sounded like perfect new toys. I dove headfirst into lists and automation, but eventually found that I wanted to do some very simple things such as consume the data from my workstation using my own code. I quickly learned what everyone learns when they try to do this: It doesn’t work that way.

In order to use the SharePoint object model, you must run your code on the SharePoint Web interface that is hosting the site you want to access. Thinking that this was completely useless for my needs, I started looking into how to use the Web services to get to the data. Attempting to do this with Windows PowerShell proved to be not only difficult, but also tedious and ineffective for what I wanted. Frustration—dissatisfaction accompanied by depression resulting from unfulfilled needs. Sigh.

Then along came Windows PowerShell 2.0 and WinRM.

Elation. Dictionary.com’s only definition: “a feeling or state of great joy or pride; exultant gladness, high spirits.”

Unfortunately, it wasn’t all immediate elation, but I knew it was within my reach. The concept is simple: Using Windows PowerShell remoting, I should be able to use the Office SharePoint object model interfaces from any computer. After installing Windows PowerShell 2.0 with WinRM on the SharePoint server and connecting to a remote session, I found that I could indeed load the Microsoft.SharePoint namespace. However, I would soon find that the same problem existed when trying to use the class remotely.

The end result of my tinkering was to find that you could make this work using CredSSP authentication. The one pitfall here is that CredSSP does not work on Windows Server 2003. Here are the steps required to get Windows PowerShell remoting to work between my Windows 7 workstation and a Windows Server 2008 workstation running Microsoft Office SharePoint Services 2007.

1.     Install Windows PowerShell 2.0 with WinRM on the SharePoint server.

2.     Enable Remoting on the SharePoint server:

a.  Enable-PSRemoting

3.     Enable CredSSP on the server:

a.  Enable-WSManCredSSP -Role server

4.     Enable CredSSp on the client:

a.  Enable-WSManCredSSP -Role client -DelegateComputer server1

5.     On the client, you also need to configure your policy by running gpedit.msc and enabling “Allow Delegating Fresh Credentials” located in the Credentials Delegation folder:

a.      

6.     You will need to add WSMAN/server.fqdn to the list or use a wildcard character as follows:

b.     

After you have completed th e above steps, you can begin to explore the very elegant world of the SharePoint object model from your workstation using the -Authentication CredSSP parameter in Invoke-Command. Let’s look at how easy it is to access data from a calendar and export it to a CSV file on a network share:

$script = {

    [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.Sharepoint”)

    $site = New-Object Microsoft.SharePoint.SPSite(“http://server1”)

    $web = $site.OpenWeb(“”)

    $list = $web.Lists[“Calendar”]

 

    $exportlist = @()

    $list.Items |foreach {

        $obj = New-Object PSObject -Property @{

            Title = $_[“Title”]

            StartTime = $_[“Start Time”]

            Location = $_[“Location”]

        }

        $exportlist += $obj   

    }

    $exportlist |Export-Csv -path ‘\tome-pcshare$Calendar.csv’

}

Invoke-Command -ComputerName server1 -scriptblock $script -Authentication Credssp

 

Let’s create a new Web site:

 

$script = {

    [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)

    $site = New-Object Microsoft.SharePoint.SPSite(“http://server1”)

    $web = $site.OpenWeb(“”)

    $web.Webs.Add(“NewSite”, “NewSite”, “NewSite Desc”,[Convert]::ToUInt32(1033), $web.WebTemplate, $false, $false)

}

Invoke-Command -ComputerName server1 -scriptblock $script -Authentication Credssp

 

And let’s do some folder and file manipulation. In this script we browse to the Shared Documents folder, create an archive folder, and then copy all of the contents into it:

 

$script = {

    [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)

    $site = New-Object Microsoft.SharePoint.SPSite(“http://server1”)

    $web = $site.OpenWeb(“”)

    $folder = $web.GetFolder(“Shared Documents”)

    $folder.SubFolders.Add(“Archive”)

    $folder.Files|foreach {

        $_.CopyTo((“Shared Documents/Archive/” + $_.Name))

    }

}

Invoke-Command -ComputerName server1 -scriptblock $script -Authentication CredSSP

 

Of course you are not limited to using script blocks. All of the remoting methods are available to you. You can create the script locally and use the -FilePath parameter of Invoke-Command to execute the script: