SharePoint and PowerShell - practical tips

Creating scripts to set off a load of stsadm commands have been a common task in SharePoint for a long time. In development and testing environments the need to install, create farm, web applications, site collection and sub sites, in a repeatable manner is must have, not a nice have. The scripts are used for setting up fresh syspreped vpc's, reinstalling (after someone (yourself?) have messed up, creating test and prototype sites. Finally a production version of the script is likely to run.

There are a lot of settings in SharePoint. And you need to change many of them from environment to environment. This implies you create and keep a settings file for each environment. By this time your little script project is perhaps not so small anymore - and is it still neat and tidy all the way? If you are using batch files (.bat) or command (.cmd) files it is probably not.

But if you have done all this, you might also had a look at Gary Lapointe's STSADM extensions. They provide you with even more things you can script and automate. Great! Expect for the fact that your scripts are getting more numerous and longer...

More and more of us are starting to use PowerShell to accomplish scripting tasks in SharePoint.

What is PowerShell?

If you have not heard of PowerShell, it is plainly said the new scripting language and tool from Microsoft. It is actually included as a part of Windows 2008. It comes with a lot of functions ready for you to use.

What can PowerShell do for your SharePoint scripting?

First of all - you should probably not just translate all your scripts to PowerShell. I do not think that will improve your situation much. My advice is that you extract and simplify wherever you can. Because you now have the means to do it. I cannot give a full listing of all the possibilities (and I still consider myself new to this scripting language), but here are some highlights:

Arguments:
foreach ($i in $args) {$i}

Comparison:

-lt	Less than
-le	Less than or equal to
-gt	Greater than
-ge	Greater than or equal to
-eq	Equal to
-ne	Not equal to
-like	Like (uses wildcards for matching)
-notlike	Not like (uses wildcards for matching)

Variable:
$a = "white"

Conditional:

if ($a -eq "red")
{"The color is red."}
elseif ($a -eq "white")
{"The color is white."}
else
{"The color is blue."}

Help:
Get-Command
Get-Alias
Get-Help cmdlet -full

Include another PowerShell file in your file:
. .\filename.ps1

You can also bind to active directory, create .Net objects, get WMI, write and read from files, color output and much more. There are a lot of examples out on the net, so you probably can get a lot for free by taking a look at scripts repositories like Script Center at TechNet. There you will also find a link to the PowerShell V2 CTP 2, which includes the graphical editor:

The editor has three panes: Top one for editing the script, middle for output and bottom one for command line input. (Remember to navigate the command line input to the folder where your scripts are located).

Creating the SharePoint scripts

There are several ways to implement the scripts. I have tried a couple of approaches, but think the one I outline here gives the most flexibility and reuse. However, this might differ from project to project, so you will need to decide if this approach is fit for your need. Here is what I have:

Three common scripts:

1. Build farm.ps1
2. Upgrade farm.ps1
3. Destroy farm.ps1

One run/settings file per environment, i.e.:

1. Dev_vpc.ps1
2. Dev_alias_vpc.ps1
3. Test_Daily.ps1
4. etc.

The common scripts only contain functions for creating, upgrading and destroying. These functions does not contain a single environment specific parameter! Each function starts with an if-statement, linking to an variable in the run/settings files. This make us able to make settings separate for each file.

To run the files, type the name of your run/settings file with a parameter stating which of the common scripts you would like to run. So the settings file first load all the settings and parameters, then it has a small function at the end, which selects the appropriate common file to run, based on your parameter.

Here are some (scaled down) example bits:

#Variables:
$CreateFarm = $true
$ProvisionCentralAdmin = $true
$InstallServices = $true

#Create Alias'
new-alias "stsadm" ($env:CommonProgramFiles + "\Microsoft Shared\web server extensions\12\BIN\stsadm.exe")
new-alias "psconfig" ($env:CommonProgramFiles + "\Microsoft Shared\web server extensions\12\BIN\psconfig.exe")

#Create farm
if ($CreateFarm)
{
  & psconfig -cmd configdb -create -server ""$DBServer"" -database ""$env_ConfigDB"" -user ""$env_FarmAdmin"" -password ""$env_FarmAdmin_pwd"" -admincontentdatabase ""$env_AdminContentDB""
  if ( $LastExitCode -ne 0)
  {
    #An error occured
    (Read-Host "Manually fix this error and hit <ENTER> to continue")
  }
}

#Install global wsp solutions
if ($InstallGlobalSolutions)
{
  foreach( $solution in $GlobalSolutionArray)
  {
    & stsadm -o addsolution -filename wsp\$solution
    & stsadm -o deploysolution -name $solution -immediate -force -allowGacDeployment -allowCasPolicies
  }
  & stsadm -o execadmsvcjobs
}

#Create site
if ($CreateTestSite)
{
  & stsadm -o createsite -url $env_Test_URL -ownerlogin $userAndDomainName -owneremail $email -sitetemplate "CMSPUBLISHING#0" -title "TestPortal" -description "Test Portal root"
}

And so it goes on... :) Reusing the files from farm to farm really saves time.

I'm curious to see what comes in line of Visual Studio integration! There are still some pieces missing from PowerShell, but the improvements are good from version to version.

Last you should definitively check out the PowerShellPackforSharePoint. These script provides a lot of functionality you will probably use in your projects.

Thanks to Karl Martin for helping me get started with PowerShell. :)

References

• Windows PowerShell
• Windows PowerShell Blog
• STSADM extensions
• TechNet Script center
• PowerShell pack for SharePoint