SharePoint Timer Jobs And Feature Receivers Accessing the Term Store (Service Applications)

When working with timer jobs, feature receivers, and other SharePoint assets that use the service application architecture components you may encounter the error:

UnauthorizedAccessException: “The current user has insufficient permissions to perform this operation”

even when leveraging a highly privileged accounts such as domain administrators. While the focus of this post is just going to use the Term Store as an example, this can happen with anything that subscribes to the 2010 services architecture.

Consider the below sample code which will attempt instantiating a few objects from the Term Store:

[csharp]
TaxonomySession session = new TaxonomySession(site);
// can also be a Metadata Term Store Name
TermStore store = session.TermStores[1];

// Bad news bear happens here
GroupCollection groups = store.Groups;

// Or other actions can cause this error
Group group = store.CreateGroup(“Group”);
TermSet set = group.CreateTermSet(“Term Set 1”);
set.CreateTerm(“Term 1”, 1033);
store.CommitAll();
[/csharp]

The second sample is just there for posterity, assume the first example piece of code because it is a pretty simple collection hydration. TaxonomySession is the entry point to accessing all data associated with TermStore objects as can be seen with the use of the TaxonomySession.TermStores property following. You can pretty much do whatever after those proxy objects are set in place.

Due to service application interaction in SharePoint 2010, services architecture process accounts running things like timer jobs and feature event sinks still lean on a proxy for connectivity. In 2007 this was a lot different because it was more blanket, timer process accounts were more liberally leveraged across processes. In 2010, it becomes increasingly important to ensure that accounts are specifically designated for particular services.

Under these pretenses, it is necessary to determine what is being used for the SharePoint\System account (your app pool and farm account, I know you can mask in a similar format ala policies) and add it to the Term Store Administrators or whatever service group you need. Should run just fine afterwards.

Share

Mirroring TFS – Consider Index Rebuilds When Using TLog Backups

Mirroring a TFS DT is a very common action within large environments for a variety of reasons, redundancy and failover obviously being the primary catalysts for such an implementation but there are also a variety of other reasons why this is a beneficial action.

At a current client of mine where I was setting up initial, trial mirroring for the TFS instance, it because evident that the TfsIntegration Maintenance Job was causing issues with a long completion time which eventually resulted in TFS to respond uncharacteristically slow. Now this job does two things, firstly it re-indexes the TFS databases (TFSIntegration, TfsWarehouse, TfsWarehouse, TfsWorkItemTracking and TfsVersionControl) by calling the Re-indexing:TfsIntegration stored procedure. This is done by calling exec TfsIntegration.dbo.Prc_OptimizeTfsDatabases. As well, it also removes deleted process templates by calling exec TfsIntegration.dbo.prc_deleteTemplates. The first of these is the culprit though for this issue, and if you run the stored procedures directly you will see a Stop Request being issued which will result in the re-index has not being executed.

9 times out of the ten, because Index rebuilds and Defragmentation generate very hefty transaction logs, it is because a transaction log backup job (TLog backup job) is running while the re-indexing is executed. While calling TLog may help in log file reduction, it can also cause these issues when executed simultaneously with the index rebuild.

Share