mylifeinaminute.com

The following is the Powershell profile that I have been using on the SharePoint 2007 farms I administer.

############################################################################
# Assumptions:
# - Running on machine with WSS/MOSS
# - C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN in path
# - For development servers only, does not dispose of objects
############################################################################
# Example usage:
# $list = get-splist -webUrl "http://site" -listName "Announcements"
############################################################################

$12HiveDir = "${env:CommonProgramFiles}\Microsoft Shared\web server extensions\12\"

[void][reflection.assembly]::Loadwithpartialname("Microsoft.SharePoint") | out-null
[void][reflection.assembly]::Loadwithpartialname("Microsoft.Office.Server.Search") | out-null
[void][reflection.assembly]::Loadwithpartialname("Microsoft.Office.Server") | out-null

# Returns the SPWebApplication at the specified URL
function get-spwebapplication ([String]$webUrl=$(throw 'Parameter -webUrl is missing!'))
{
    return [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup("$webUrl")
}

# Returns the SPSite at the specified URL
function get-spsite ([String]$webUrl=$(throw 'Parameter -webUrl is missing!'))
{
    return New-Object -TypeName "Microsoft.SharePoint.SPSite" -ArgumentList "$webUrl"
}

# Returns the SPSite object from the specified URL
function get-spweb ([String]$webUrl=$(throw 'Parameter -webUrl is missing!'))
{
    $site = New-Object -TypeName "Microsoft.SharePoint.SPSite" -ArgumentList "$webUrl"
    return $site.OpenWeb()
}

# Returns the SPList object from the specified URL and list name
function get-splist ([String]$webUrl=$(throw 'Parameter -webUrl is missing!'),
[String]$listName=$(throw 'Parameter -listName is missing!'))
{
    $site = New-Object -TypeName "Microsoft.SharePoint.SPSite" -ArgumentList "$webUrl"
    $web = $site.OpenWeb()
    return $web.Lists[$listName]
}

Reference

• Getting started with PowerShell and SharePoint

Ah yes, the people picker again. I recently inherited an environment where the previous administrator was kind enough to not document anything, especially the items he/she had been playing with in development.

When trying to designate a user as a Primary Site Collection Administrator in Central Administration, I was unable to query for subsets of domain users on a single web application. After checking all of the usual suspects (Peoplepicker-searchadforests I’m looking at you) with no success, it was off to the not-so-usual suspects.

It turns out the previous admin was kind enough to set the Peoplepicker-searchadcustomfilter property on the main portal site collection. After setting the property to null

stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "" -url [URL]

all was once again right with the world.

Now where did I leave my sledgehammer?

After a recent farm migration, a number of content databases were left offline. This had the unintended consequence of not allowing user profile synchronization to occur across site collections (where the content databases were offline).

The quick fix? Bring the content database(s) online.

The moral of the story? Do not leave your content database(s) offline without a good reason. If you do leave them offline, User Information Lists in the offline site collections will not be synchronized with the SSP.

When upgrading from a standard SKU to an Enterprise SKU in SharePoint (MOSS 2007), things can (and do) go wrong. Come to think of it, I’ve never seen one complete successfully without some type of manual intervention. Fortunately, the majority of errors that are experienced are recoverable. Take for instance:

An existing request to enable the Enterprise feature is in progress. To check the status of this request, go to the Timer Job Status page in Central Administration Operations and check the status of the Office Server Enterprise Features Upgrade Job.

When you find the job in the Timer Job Status page, you will see that it needs to run on all servers in your farm. Chances are it has failed on one (or more) servers. The quick fix? Restart (or start if stopped) the Windows SharePoint Services Timer service on the server where the upgrade job failed. After the job has completed, return to Central Administration to verify that your farm has been upgraded.