A few days ago I wrote about How to start custom SharePoint timer programatically. In this post, I talked about the problems that we could find before starting a Sharepoint timer programatically.

Today, I want to expand on this topic with another post. First, I want to talk about instruccions that we need for starting the timer.

Below, there is a piece of code to start the timer programatically.

public staticvoid StartJob(thisSPSite Site, string JobName, Dictionary<string, object> properties)

{

SPSecurity.RunWithElevatedPrivileges(delegate()

{

   using (SPSite elevatedSite = newSPSite(Site.ID))

{

     SPSite site = elevatedSite;

     SPJobDefinition myjob = FindJob(elevatedSite,JobName);

foreach(string k in properties.Keys)

{

myjob.Properties[k] = properties[k];

}

myjob.RunNow();

}

});

}

It’s nothing special. Maybe the way that we can find the timer job instance is a bit important to know how to avoid problems.

public staticSPJobDefinition FindJob(thisSPSite elevatedSite, string JobName)

{

 SPJobDefinition myjob = null;

 foreach (SPJobDefinition job in elevatedSite.WebApplication.JobDefinitions)

{

   if (job.Name.Equals(JobName, StringComparison.OrdinalIgnoreCase))

{

myjob = job;

      break;

}

}

 return myjob;

}

In timer job, also, there is a way to bypass parameters by properties. This properties could be persistent or not, it depends on how you declare it in timer job.

It’s very common that a timer job is instantiate in site level and we need to execute to web level. This kind of problem can be resolved using properties. You can see an example on this lines.

Dictionary<string, object> properties = newDictionary<string, object>();

properties.Add(“isManual”, true);

properties.Add(“force-web-id”, SPContext.Current.Web.ID);

SPContext.Current.Web.Site.StartJob(JobDefinition.Name, properties);

And what about its status? Reading the status of timer job could be a little complicated. You need to reiterate the status list and get the last log written by the job. For example if job is running:

public static bool IsJobRunning(thisSPSite Site, string JobName)

{

 bool isrunning = false;

 InformationJob ijob = newInformationJob();

 SPSecurity.RunWithElevatedPrivileges(delegate()

{

  using (SPSite elevatedSite = newSPSite(Site.ID))

{

    SPJobDefinition myjob = FindJob(elevatedSite,JobName);

    if (myjob.IsDisabled)

{

isrunning = false;

}

    else

{

      try

{

         var e = myjob.HistoryEntries.OrderByDescending(i => i.StartTime).First();

isrunning = e.Status ==SPRunningJobStatus.Initialized;

}

      catch

{

isrunning =false;

}

}

}

});

 return isrunning;

}

I recommend creating another list to register your own log and to set one mark for knowing when it begins and another for knowing when it finishes. Here you can see an example of the list:

So, in this way, you only need to read your own log and find the mark that tells you what the status of your job is. For example if  job is finished:

private bool IsJobFinished()

{

  bool isFinished = false;

InformationJob ijob = newInformationJob();

SPSecurity.RunWithElevatedPrivileges(delegate()

{

using (SPSite elevatedSite = newSPSite(SPContext.Current.Site.ID))

{

SPJobDefinition myjob = FindJob(elevatedSite);

if (myjob.IsDisabled)

{

isFinished =false;

}

     else

{

        try

{

          SPList listLog = SPContext.Current.Web.GetListByUrl(JobDefinition.LogListUrl);

          if (listLog.Items.Count == 0)

{

isFinished =true;

}

          else

{

            var joblog = listLog.Items.OfType<SPListItem>().Where(i =>

i["TypeMessage"].ToString() == TypeMessageLogJobs.End.ToString() &&

((DateTime)i["Timestamp"]).CompareTo(listLog.Items.OfType<SPListItem>().Max(ii => (DateTime)ii["Timestamp"])) == 0 ).First();

isFinished =true;

}

}

catch

{

isFinished =false;

}

}

}

});

   return isFinished;

}

When you need to start a timer job in SharePoint you can do it from Central Administration with a cool web interface.

There, you can see all timers Jobs in your farm and control their status and logs. But, sometimes we need to start a timer job from a Sharepoint front-end interface. I mean, a simple user wants to start a process that runs in background.

Yes, we have a timer job as a class, you can instantiate and call its RunNow method for starting the process. But, we need to do something else before that.

For security reasons, users can’t start timer jobs in front-end interface. In fact, you must write this Power Shell sentence in the application server or write in your feature activation method in feature receiver class.

PowerShell script

$snap = Get-PSSnapin | Where-Object { $_.Name -eq “Microsoft.SharePoint.Powershell” }
if ($snap -eq $null)
{
Add-PSSnapin “Microsoft.SharePoint.Powershell”
}
# get content web service
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
# turn off remote administration security
$contentService.RemoteAdministratorAccessDenied = $false
# update the web service
$contentService.Update()

C# code

// SET THE REMOTE ADMINISTATOR ACCESS DENIED FALSE
SPWebService.ContentService.RemoteAdministratorAccessDenied = false;
SPWebService.ContentService.Update();

Remeber that any timer job in Sharepoint is started by SP Timer and you need to restart that service in all farm servers when any change in your custom job are made.

Without modifing RemoteAdministrationAccessDenied to false when you try to start a job programatically a Access denied exception is thrown.

More information:

Custom SPJobDefinition and “Access denied” Error

Custom job and System.Security.SecurityException: Access Denied