Partager via

SharePoint - SharePoint 2010 and Remote PowerShell for use with System Center Orchestrator 2012

  • Article

Today we will be taking a look at how to enable a PowerShell script to execute SharePoint cmdlets on a remote server running SharePoint 2010 for use with System Center Orchestrator 2012. You may be thinking, “That’s sounds simple, I can use PowerShell to remotely execute SharePoint cmdlets using New-PSSession and Invoke-Command.” And while you would be right, running commands in a PSSession on a remote computer will start an interactive session on that remote computer. This may work fine in day to day PowerShell based system administration, but interactive sessions do not work as well when we are trying to automate, which is what we are looking to do with System Center Orchestrator. 

To configure things to be non-interactive and not require an administrator to be at a keyboard for the script to complete successfully, I have chosen to simply use the Invoke-Command cmdlet on its own. If you utilize PowerShell throughout your day, hopefully you are running the latest production release, PowerShell version 4. If you are running PowerShell version 4 and are looking to get this to work, some additional configuration is needed on each SharePoint server that you want to run remote commands against.

Assuming that you have configured WinRM and your remote SharePoint server is capable of handling PowerShell remote commands, we will start with a simple example that should work without any additional configuration:

Invoke-Command -Computer SP2010 –ScriptBlock {
Get-Host
}

Saving the above code as a ps1 file allows us to run this simple PowerShell script against a remote computer called SP2010 from our management server. It is always a good first step to ensure that your script works properly outside of your automation environment before you try to add it in, so I do all my testing first just against the ps1 files themselves.

Let’s dig deeper now that we know remoting is working, and let’s come up with a simple script that utilizes a SharePoint cmdlet

Invoke-Command -Computer SP2010 –ScriptBlock {
Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm = Get-SPFarm
}

If you are up to date with PowerShell and running version 4 throughout your environment, the above command will fail. The reason is that the SharePoint snapin that is referenced is not compatible with version 4 of the .Net Runtime, which is used by default in PowerShell version 4. You may have come across this already as well and you may be thinking, “I already have a way to fix this, I just need to run powershell -v 2 before I go to add the snapin.” And again you would be right, except this only works in an interactive session. Since we are trying to do this non-interactively so it can be run any time by Orchestrator, we need to find a different solution. The issue with this comes up when we try to run the Invoke-Command cmdlet, as the Invoke-Command will never complete when the powershell –v 2 option is included in your script.

This led me to do some searching, and I came across the following article by Cyril Leroy https://www.gsx.com/blog/bid/86424/Allow-Remote-PowerShell-on-SharePoint-2010-and-PowerShell-v3

In their post, Cyril demonstrates the Set-PSSessionConfiguration cmdlet. Using this cmdlet, we can force a computer to use a desired version of PowerShell when we connect into it to execute remote commands.

On each SharePoint 2010 server that has PowerShell version 4 installed, we will run the following command to force the server to run remote commands using PowerShell version 2. While this seems similar to the powershell –v 2 command we talked about earlier, the difference here is that this configuration will still allow us to run the Invoke-Command cmdlet.

Set-PSSessionConfiguration -Name microsoft.powershell -PSVersion "2.0"

Upon running this command, we can head back over to our management server and run our script that contains our SharePoint cmdlets and the Invoke-Command to our remote SharePoint server and things should now complete successfully.

Comments

  • Anonymous
    January 01, 2003
    Ralph - thanks for this post. I can think of several situations where I could utilize this info in a customer scenario.