Using SPPersistedObjects to store custom SharePoint Configuration Settings

SharePoint Applications can store configuration information in a many places (PropertyBags, lists, PersitedObjects, web.config ). PropertyBags and Lists are both stored in the Content Database, so when you copy your production environment down to QA environment, these settings come with it. Persisted Objects are stored in the Configuration Database, so if you copy your production environment down to QA environment, these settings remain intact.

This can be useful in many situations, such as if you wanted your QA SharePoint server to always talk to  a QA version of some external server you are accessing(a QA report server, Web Server or some external Web Service) even after you refreshed SharePoint from Production. The persisted objects can be use most any SharePoint Project (Web parts, Timer Jobs ,event receivers, coded workflows … anywhere we can add code, we can use persisted Objects). If we don’t want the data overwritten when you copy Production to QA we should consider using them.

The nice thing about storing configuration information in a list is that you get a means to maintain that information via the SharePoint UI. While you don’t get a UI to maintain configuration information stored in Persisted objects, it is quite easy to do using PowerShell.

As an example, I have a Timer job that pulls new information from an external database every 5 minutes. I store key information about the Job in a class that inherits from SPPersistedObject.

public class AgressoImporterTimerJobParameters : SPPersistedObject



public DateTime CustomersFromDate;


public DateTime EntitiesFromDate;


public DateTime VendorsFromDate;


public DateTime CounterpartiesFromDate;


public string ConnectionString;


public Guid SiteID;


public Guid WebID;

public AgressoImporterTimerJobParameters() { }

public AgressoImporterTimerJobParameters(string name, SPPersistedObject parent, Guid id)

: base(name, parent, id)



protected AgressoImporterTimerJobParameters(string name, SPPersistedObject parent)

: base(name, parent)




In the Execute method of the Timer Job the settings are retrieved by calling

 AgressoImporterTimerJobParameters settings = GetChild<AgressoImporterTimerJobParameters>(this.Name); // the parameters are storted as persisted objects under the job. Multiple jobs can eists for multiple sites, so jobname is used to differentiate

I can update the settings from within my timer job by calling

settings.CustomersFromDate = importer.LoadCustomers(settings.ConnectionString, customersList, settings.CustomersFromDate);


If I need to update some settings from PowerShell, I can use the following script

[System.Reflection.Assembly]::Load(“XXXAgressoImport, Version=, Culture=neutral, PublicKeyToken=b9c4d28743c1d3be”)

$job=[XXXAgressoImport.AgressoImporterTimerJob] (get-sptimerjob | where {$_.Name -match “XXX Agresso Importer Timer Job “} )

$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local

$parameters = $farm.GetObject($, $job.Id, [XXXAgressoImport.AgressoImporterTimerJobParameters])

$parameters.CounterpartiesFromDate=”3/22/2011 5:17:41 PM”

$parameters.CustomersFromDate=”3/22/2011 5:17:41 PM”

$parameters.VendorsFromDate=”3/22/2011 5:17:41 PM”

$parameters.EntitiesFromDate=”3/22/2011 5:17:41 PM”

#$parameters.ConnectionString=”Datasource= …..”


You need to get the full name of the assembly using Reflector or a sililar Tool.

This entry was posted in Powershell, sharepoint and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s