Setting up PowerShell for SharePoint

By: Joshua Fuente | Comments | Related: > SharePoint Administration

Problem

You want to use PowerShell to administer your WSS 3.0 or SharePoint 2007 farm.

Solution

I will provide the basic steps to setup PowerShell and use it to access SharePoint, and provide reference links for you to dig deeper on your specific situation.

PowerShell basics

If you have already used PowerShell, you can skip down to the "Load the DLL" section. If you have never used PowerShell, please read on...

PowerShell is setup by default to be somewhat useless. You will not be able to run a script right off the bat. That is because Microsoft set the default security level to not allow this behavior. This is good, because it helps to prevent security issues, and in my opinion, limits the possibility that a beginner makes a serious mistake. PowerShell can be very unforgiving. Once a process is started, it is all but impossible to stop it. So be sure to test everything you write thoroughly before executing in a production environment.

If you have not downloaded PowerShell, here is the link. And by the way, Microsoft's new name for PowerShell bundled with Windows Remote Management (WinRM) 2.0 and Background Intelligent Transfer Service (BITS) 4.0, is called, "Windows Management Framework".

So you have installed PowerShell, and you run it for the first time. You get a blue screen, that looks pretty much like a normal "shell" or "console". Taa-Daa!! This is PowerShell.

Now, to be able to run a script, you will need to explicitly allow them, run the following command;

get-executionpolicy

You should see that the policy is set to "restricted". If not, someone else has already used your PowerShell. :)

So to set the policy, you guessed it. Run this command

set-executionpolicy

You will see that PowerShell is prompting you for more information. You can input the executionpolicy, or ctrl+c to cancel the command. To make a long story short, you have a few choices here.

Restricted: Does not load configuration files or run scripts. "Restricted" is the default.
AllSigned: Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.
RemoteSigned: Requires that all scripts and configuration files downloaded from the Internet be signed by a trusted publisher.
Unrestricted: Loads all configuration files and runs all scripts. If you run an unsigned script that was downloaded from the Internet, you are prompted for permission before it runs.
Bypass: Nothing is blocked and there are no warnings or prompts.
Undefined: Removes the currently assigned execution policy from the current scope. This parameter will not remove an execution policy that is set in a Group Policy scope.

So assuming you are trying this on a development, or sandbox server, I would set it to unrestricted.

set-executionpolicy unrestricted

Done. You will want to research and decide for yourself if you want to set a more strict execution policy.

Run

get-help about_signing

- for more information about signing scripts.

Create a Profile

First things first. To effectively use PowerShell, you will need a profile. And even before that, lets just see if someone has already created one. Run this command;

test-path $profile

If there is not one, you get "false" back as the result, if there is one, then "true"

If you already have a profile, you can open it right from the shell by running;

notepad $profile

If not, then run this command to create it

new-item -path $profile -type file -force

(be careful, the force command will overwrite it, if it does exist)

Great, now you have a profile, open it with the same command as above;

notepad $profile

Load DLL

Now that you have a profile, you need to put stuff in it! (Remember, to open your PowerShell profile, type notepad $profile.)

Also it important to note the following:

You must run PowerShell on the SharePoint server.
You must have the farm administrator role assigned, as well as SQL rights.
You must be a local administrator on the server itself.

I will give you two options here.

Option One:

Copy the following line into your profile, and save it.

$12hive = (join-path -path "c:\program files\common files\microsoft shared\web server extensions\12\" -childPath "\isapi")
Get-ChildItem -Path (join-path -path $12hive -childPath "Microsoft*.dll") | ForEach-Object {[System.Reflection.Assembly]::LoadFrom((join-path -path $12hive -childPath $_.Name))}

This will load all needed assemblies on a server that has WSS 3.0 or SharePoint Server 2007.

Option Two:

To take a more direct approach, you could do this instead...

[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0 , Culture=Neutral, PublicKeyToken=71e9bce111e9429c")
[System.Reflection.Assembly]::Load("Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

Get to work!

Your PowerShell is now setup to use the SharePoint Assemblies, so that you can administer your WSS or SharePoint farm.

Now type this into your PowerShell command line;

$spsite=[Microsoft.SharePoint.SPSite]("http://localhost/sites/intranet")
$spsite

And off you go.... What you just did was to create a variable "$spsite". This variable is an "object" of the type "Microsoft.SharePoint.SPSite", with a URL value of "http://localhost/sites/intranet"

So when you type just $spsite, it basically executes the variable, and displays the object, in all its glory!! :)

Next Steps

There are many, more resources available for SharePoint 2007 and PowerShell, if you are unable to find what you need on MSSharePointTips, here are a few links to get you started.