1

I guess we've all been there. We want to store some settings for our WebPart / List / Custom App / Timer Job. Where do we save it?

Multiple options exist:

  • The various existing property bags (SPList, SPListItem, SPWeb, SPWebApplication, SPFarm) SPPropertyBag
  • A hidden "settings" list

These options are limited as they relate to only a specific site collection. With a dynamic URL, more site collections and maybe a timer job not knowing where the settings reside (you don't want to hardcode an URL).

Web Application / Farm wide settings can be stored in:

Both have their problems: web.config is per Web Application, not per Farm. Timer Jobs don't have it too easy to access the web.configs as they don't run in w3wp, but in owstimer.
The persisted object has the problem that you access the Farm config db with the current web application pool account. That account typically doesn't have read / write access to the Content DB. Giving the account access would mean opening the SharePoint config DB to any code running RunWithElevatedPriviliges.

What are your suggestions for saving farm wide configuration data for e.g. timer jobs or a "global web application spanning navigation"? My last idea is a custom service application with a custom database, but that somehow seems kind of over-the-top.

2

For farm level setting you can use SPFarm's property bag, so that it would be available across the farm.

SPFarm farm = SPFarm.Local;
farm.Properties["MyData"] = new test(1, 2);

farm.Update(true); //Save changes

If there are still authentication and authorization issues with this, you can use your Custom DB.

  • Yes and no. Farm Property bag has the same problem as does the SPPersistedObject - only Farm Administrators can write and read from the property bag. Of course I would like to have "regular" users be able to read the setting as well (e.g. global navigation settings). sharepoint.stackexchange.com/questions/70667/… - also some posts suggest that writing to the farm property bag might corrupt the config db which of course is less desirable. – Dennis G Sep 26 '14 at 7:16
  • Yes, security concerns will remain as it is. So to access farm level setting you need to use custom storage as you mention, in custom DB . – Aanchal Sep 26 '14 at 8:22
1

you can use the secure store service to store key value pairs inside it. It will be stored in an secure manner and can be accessed via code. The only downside to this is that once you create a target application Id it will remain hard-coded. You can follow the steps mentioned in below link for your purposes:

http://matthewyarlett.blogspot.in/2013/10/retrieving-credentials-from-sharepoint.html

  • Problem is that you can only store small things in the secure store (I don't know the restriction, but it is around 255 characters per value). Furthermore the secure store is "supposed" to be for credentials, not settings. It is a valid idea though! – Dennis G Sep 30 '14 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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