When a normal (non-admin) users click my custom-made ribbon button in a document library, I would like to write the document library's information to some persistent farm-wide store (or at least a content database-wide store). A farm admin could later view this information in a custom central admin page. Something like this:

// In a Document Library (can be anywhere in the farm)
if user clicks myRibbonButton in DocumentLibrary
    PeristentStore["DocumentLibraries"].Add(this DocumentLibrary.ID);

// This is what a farm admin would see in a custom CA page
foreach entry in PeristentStore["DocumentLibraries"]
    listBox.Add(entry);     // list all saved document libraries' IDs in a list box

Is there an out-of-the-box way to store such information, or should I deploy a custom database?

I've read about numerous options SharePoint offers to store custom application data, however - assuming a least-privileged configuration - each has severe limitations:

  • SPPersistedObjects would be perfect but can only be written by farm admins, which renders them useless for this purpose (as pointed out in this question);
  • SPWeb property bags can be used to achieve this, but they create a new problem: how would the central admin feature know which SPWebs to scan? So I'm back at the beginning: I'd need some farm-wide place to remember which SPWebs have had their properties filled with the desired information. Same is true if I create a list.
  • A custom database solves all this as one can simply read/write anything into it. However, it introduces a potential nightmare that are security/permissions, deployment and backup/restore inconsistencies. In my specific case, it would be enough to create a custom table in an already existing content database, but I don't believe this is a good idea (potential updates breaking everything etc.).

Am I missing something or does SharePoint really not offer anything to solve such a common problem?

1 Answer 1


There’s two parts to this. Both the ability to save, store, the information as well as being able to later review the information in central admin.

Without any detailed knowledge about what type and amount of information you would like to store I would recommend a SharePoint list. Maybe stored in a central site collection or within the central administration. A SharePoint list is the natural place to store information within SharePoint. The list also makes the information available to administrators without having to build an interface.

Use elevated privileges to write the information to the central list.

Good luck!

  • 1
    With elevated privileges you will use the the web application app pool’s identity. If the list is created in any central site collection, then RunWithElevatedPrevileges may not be able to write in that list from a site collection of a different web application until both use same app pool. Same holds true if the list is stored in CA. Mar 26, 2014 at 13:24
  • Good and valid point! Work with the permissions of the application pool accounts on the central list. Mar 26, 2014 at 14:17

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.