I have a custom SharePoint timer job which needs access to a WCF service.

Access to that service is configured via WCF endpoints in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTimer.exe.config file. The configuration also has a custom section defined in the configuration\configSections section which references an external dll which tacks on extra security information to the WCF channel.

I want to move the configuration out of the timer service's config file to another location so that we are not in a situation where the WSP which installs the dependent dll is uninstalled but the config is left in the config file causing the timer job to consistently fail.

What other ways are there to store the timer job WCF endpoints and behaviors (including a custom behavior) as well a custom config section dependent on an external dll, other than in the timer job's config file?

Any help is appreciated.

3 Answers 3


Each SharePoint Timer Job has a property bag (SPPersistedObject) that it can read from. When I write timer jobs that need to have configuration that is where I store it. Accessing this configuration information from your timer job is as easy as having code like the following in your Execute() method. In the example below, I put all of my configuration as an XML string in a "Config" property.

if (this.Properties.ContainsKey("Config"))
    object config = this.Properties["Config"];
    XDocument doc = XDocument.Parse(config.ToString());

    // Now do something with the configuration

Setting the configuration can be done via a custom central admin screen or even PowerShell. Here is an example using PowerShell.

$webApp = [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]::Local
$job = $webApp.JobDefinitions | Where {$_.TypeName -eq "MyTimerJobs.MyTimerJob"}
$job.Properties.Add("Conifg", "<someXml/>");

A key point with the PowerShell example above is that it assumes that the timer job is tied to the central admin web application. A SharePoint timer job is either tied to a web app or a service and whatever is chosen is where the timer job configuration (SPPersistedObject) is stored. If you use a different web app or a service, you'll need to adjust the PowerShell script accordingly.

Also, if you can have several instances of your timer job in the same container (web app or service), then finding it based on TypeName will not work for you. There are other properties on the job you can use to differentiate.


The main challenges of consuming WCF services in a SharePoint are determining how to store and maintain the configuration information. There are two options to configure the clients of a WCF service: 1) use a configuration file or 2) configure the client programmatically.

For SharePoint Timer jobs you can go for second option. Here is an example : How to: Programmatically Configure a WCF Endpoint

If you want, you can avoid some hardcoding by keeping the information in a xml file which you can access in a timer job programmatically.

  • WCF configuration is not an issue. I am more concerned with how to configure a custom section as mentioned above. Any idea on how to do that programmatically? Jun 6, 2012 at 16:18

You can try to use web.config of your web application (see this post) or create file that should be stored in a SharePoint library (see this post).

  • It is not as straightforward as that. I have a custom configuration section which references a dll which add more security info to the WCH channel. Of course I can configure WCF endpoints via code but the bigger question is how I can asbtract the configuration so I can load the custom section from another location. According to [this post][1], the configuration model is pretty much locked down to the file-based approach.. was hoping someone knew of a way around this. [1]: stackoverflow.com/questions/1410189/… Jun 6, 2012 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.