Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 0 down vote favorite

I have a situation where some of the code needs to re-schedule the specific timer job and start it according to new schedule. The timer jobs actually writes (need permissions) into the SharePoint configuration database.

I know it's a bit tricky situation because the code needs to be executed and must have the Farm administrator permission for manipulation of SharePoint configuration Database. We also know that our majority of code runs under the application pool account and of course we don't wanna promote our application pool account as a Farm Administrator account (as per Best practices).

What are the alternative scenarios we have at the moment?

share|improve this question
Are you talking about restarting the timer service, or just specific timer jobs? – Paul Lucas Feb 2 '12 at 19:08
I'm talking about resetting the timer job service in general. – Falak Mahmood Feb 2 '12 at 21:02
Ok, so does the restart need to be triggered by some event in SharePoint, or could it be done on a scheduled basis? – Paul Lucas Feb 2 '12 at 21:08
actually, there is a Web part (UI) from where we are supposed to reset a specific timer job, either to reset it or set a new scheduled time. – Falak Mahmood Feb 2 '12 at 21:11
Now I'm confused. Sounds like you want to manipulate individual timer jobs, not restart the timer service. Just to clarify, timer jobs in SharePoint all run within the context of a windows service (called the SharePoint Timer Service). While you can use the SharePoint API to create/delete/reschedule individual timer jobs, it doesn't make sense to use the term 'reset' a specific timer job. – Paul Lucas Feb 2 '12 at 21:24
show 2 more comments

1 Answer

up vote 1 down vote accepted

If you have a web part UI for manipulating timer job schedules in SharePoint 2007, then I'd say the best practice would be to have the web part running on a page that is hosted by the Central administration site. After all such a task is an administrative task.

If the web part is in fact in the central admin site, and the logged in user is an administrator, then it should have the necessary permissions to write to the config db.

Note: In SharePoint 2010, this sort of functionality is already built in to central admin

share|improve this answer
You meant deploying the Web part on the Central Admin. We are supposed to deploy the Web Part to other Web application which is being used by normal users. I think Central Admin Web application pool account is also the Farm administrator and I think running the code with elevate privileges will not be an issue. – Falak Mahmood Feb 2 '12 at 21:41
That's right. Someone else may be able to offer a different view, but my opinion is that the concept of allowing 'normal users' to carry out administrative tasks would be a violation of best practices. – Paul Lucas Feb 2 '12 at 21:45
What I meant was deploying the Web part on the Central Admin. We are supposed to deploy the Web Part to other Web application which is being used by normal users. I think deploying the Web part on Central Admin and running the code with elevate privileges will not be an issue. Because, application pool account for CA is also the Farm administrator and it is easy to write to configuration DB – Falak Mahmood Feb 2 '12 at 21:47
Yes, I meant deploying the web part to central admin. Remember you are asking about best practices, and having this type of web part hosted in a normal web application, where normal users can use it would not be a best pratice. – Paul Lucas Feb 2 '12 at 21:53
Yes, I agree but there is no official documentation existing for such best practices or is there any documentation? I haven't found it myself. – Falak Mahmood Feb 2 '12 at 22:08
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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