“Captain Literal”.NET

I spent a lot of time automating SharePoint when the company I work for installed SharePoint Portal Server 2003, so I was quite disappointed when SharePoint version 3 was released without PowerShell support – after all, Exchange 2007 managed it and it’s part of the Office 2007 Server suite, so why didn’t the other server products?

On a positive note though, I did find that stsadm.exe had been extended to now support a lot more operations:

[C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN]
3> .\stsadm.exe –help

Usage:
stsadm.exe -o <operation> [<parameters>]
stsadm.exe -help [<operation>]

Operations:


activatefeature
addalternatedomain
addcontentdb
addpath
addpermissionpolicy
addsolution
addtemplate
adduser
addwppack
addzoneurl
authentication
backup
backuphistory
binddrservice
blockedfilelist
canceldeployment
changepermissionpolicy
copyappbincontent
createadminvs
creategroup
createsite
createsiteinnewdb
createweb
databaserepair
deactivatefeature
deleteadminvs
deletealternatedomain
deleteconfigdb
deletecontentdb
deletegroup
deletepath
deletepermissionpolicy
deletesite
deletesolution
deletetemplate
deleteuser
deleteweb
deletewppack
deletezoneurl
deploysolution
deploywppack
disablessc
displaysolution
email
enablessc
enumalternatedomains
enumcontentdbs
enumdeployments
enumgroups
enumroles
enumservices
enumsites
enumsolutions
enumsubwebs
enumtemplates
enumusers
enumwppacks
enumzoneurls
execadmsvcjobs
export
extendvs
extendvsinwebfarm
forcedeletelist
getadminport
getproperty
getsitelock
geturlzone
import
installfeature
listlogginglevels
localupgradestatus
managepermissionpolicylevel
migrateuser
provisionservice
refreshdms
refreshsitedms
registerwsswriter
removedrservice
removesolutiondeploymentlock
renameserver
renameweb
restore
retractsolution
retractwppack
scanforfeatures
setadminport
setapppassword
setconfigdb
setlogginglevel
setproperty
setsitelock
setworkflowconfig
siteowner
spsearch
spsearchdiacriticsensitive
syncsolution
unextendvs
uninstallfeature
unregisterwsswriter
updateaccountpassword
updatealerttemplates
updatefarmcredentials
upgrade
upgradesolution
upgradetargetwebapplication
userrole

For information about other operations and parameters,
use “stsadm.exe -help” or “stsadm.exe -help <operation>”

But how useful are these commands? Consider the example of enumsites – this command lists all Site Collections or a given Web Application.

[C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN]
5> .\stsadm.exe -help enumsites

stsadm.exe -o enumsites
-url <virtual server url>
-showlocks
-redirectedsites

[C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN]
7> .\stsadm.exe -o enumsites -url http://localhost

<Sites Count=”1″>
<Site Url=”http://wss” Owner=”domain\administrator” SecondaryOwner=”domain\user” ContentDatabase=”WSS_C
ontent_Default” StorageUsedMB=”0.5″ StorageWarningMB=”0″ StorageMaxMB=”0″ />
</Sites>

Great, it gives me the output as XML, so I suppose that I can assign it to a variable within PowerShell and perform some XML queries on it - Not quite what I had in mind though when I thought about how PowerShell could automate SharePoint.

Fortunately though the SharePoint Team do an excellent API that exposed 100% via .NET – so PowerShell is right at home here thanks to its ability to just consume all things .NET, including the System.Reflection.Assembly class which can be used to load an assembly into the PowerShell Application Domain, so it can be called directly from the command line. T load Microsoft.SharePoint.dll, all we need do is the following:

[C:\PsScripts]
3> [System.Reflection.Assembly]::Load(”Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”);

GAC Version Location
— ——- ——–
True v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\ 12.0.0.0__71e9bce111e9429c\Microsoft.SharePo…

Now we can call into the SharePoint object model to get the Application that we wish to enumerate the Site Collections for:

[C:\PsScripts]
4> $webApplication = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup(”http://localhost”)

[C:\PsScripts]
5> $webApplication.Sites.Count
1

[C:\PsScripts]
6> $webApplication.Sites | ft url, Owner, SecondaryContact

Url Owner SecondaryContact
— —– —————-
http://wss domain\administrator domain\user

How cool is that? The PowerShell Team have given us a full scripting tool for SharePoint because the SharePoint Team wrote a very good API and we can work with object, not strings or XML.

As a final demo, I’ll show you that PowerShell can write through the SharePoint API as well as read from it:

[C:\PsScripts]
3> . .\Load-sharePoint.ps1;

GAC Version Location
— ——- ——–
True v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\ 12.0.0.0__71e9bce111e9429c\Microsoft.SharePo…
True v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint.Workflows\ 12.0.0.0__71e9bce111e9429c\Microso…

[C:\PsScripts]
4> $sc = new-object Microsoft.SharePoint.SPSite “http://localhost”;

[C:\PsScripts]
5> $rootWeb = $sc.Rootweb;

[C:\PsScripts]
6> write-host $rootWeb.Title;
WSS Root Web

[C:\PsScripts]
7> $rootWeb.Title = “PowerShell has change the title!”;

[C:\PsScripts]
8> $rootweb.update();

[C:\PsScripts]
9> write-host $rootWeb.Title;

Conclusion

Job Done! Not only have we got the same functionality that stsadm.exe provides us for the enumsites operation, but we’ve got the ability to change the WSS installation on the fly – Now that’s what I mean when I talk about automating SharePoint!

When we get round to deploying MOSS 2007 at my place of work, I’ll probably end up recreating all of stsadm.exe’s operations into PowerShell functions. But for now, I’ve created a PowerShell script (Load-SharePoint.ps1) that will load a couple of the SharePoint dll’s and then create a few functions:

• Get-SiteCollection – Returns the site collection at the specified URL.
• Get-SiteCollections – Returns an array of Site Collections for the given Web Application, same as demo above
• Get-Sites – Returns an array of sites for the given Site Collection

For details on running .ps1 scripts, please see my previous post - PowerShell Basics – Running Scripts.

If you want to explore the SharePoint object model (with or without PowerShell), you’re going to want to get the WSS 3 SDK and/or the MOSS 2007 SDK as it’s the only place to get a full description of the classes that you’re going to work with.

This post is only the tip of the iceberg, I’ve been using PowerShell and the MOSS 2007/WSS 3 API to upload InfoPath form templates, create sites/lists and to try things out before I commit them to C# assemblies. As a developer, PowerShell saves me from the write, compile, run loop that I usually get into when I’m learning an API.

Filed under: PowerShell, SharePoint