By: Robert Christ

The Problem

Timer Jobs are fickle creatures, even in SharePoint 2010.  Some of the problems you may experience when new to SharePoint development are as follows:

1. I deployed a new version of my timer job to the SharePoint farm, but now it no longer appears in the list of Job Definitions on the SharePoint Server. 
2. I deployed a new version of my timer job to the SharePoint farm, and now even though it no longer appears in the list of Job Definitions and / or Running Jobs, it still appears to be running in the background.
3. My timer job is running and seems to be running correctly, but is not running the same code as the most recent version I deployed.
4. My timer job is no longer logging to the ULS logs.
5. My timer job is running, but is throwing an impossible to reach error that doesn’t appear to be related to my code.

In all of these instances, the problem is most likely that the version of the timer job that SharePoint has loaded “into” the SharePoint Timer Service does not match the compiled code you most recently deployed to the SharePoint farm.

Normally, this issue is solvable by following the steps Kathryn published last January.  (See here http://www.thesharepointblog.net/Lists/Posts/Post.aspx?List=815f255a-d0ef-4258-be2a-28487dc9975c&ID=55)

Unfortunately, when working on SharePoint farms that include server redundancy (such as multiple front ends or application servers) one has to be careful about performing the correct steps on every necessary server.

As such, here are the updated steps to get SharePoint to run your most recent timer job version, and thereby resolve the errors listed above.

The Solution

Step 1) Deactivate every feature in the solution that utilizes that Timer Job.  This only needs to be done once, on one SharePoint front end server, as these settings should propagate throughout the farm.  After this is done, however, go to each server in the SharePoint farm, and check that the feature is in fact deactivated on each SharePoint server in the farm.

Step 2) Retract the solution that includes the SharePoint Timer Job.  This can be done either through Central Administration, or by running stsadm –o retractsolution –name Solutionname once in the console.  Once this is completed, check that the solution is shown as “retracted” on every server that runs a copy of Central Administration.   The solution should state that it is not currently deployed on ANY web application or globally.

Step 3) Remove the solution from SharePoint either via stsadm –o removesolution –name SolutionName or through the Central Administration UI.  Again, check that this change has propagated to each SharePoint server that hosts a copy of Central Administration.

Step 4) Ensure that the Timer Job has been successfully removed from the SharePoint farm by using SharePoint Manager 2010.

If you don’t have SharePoint Manager 2010, you can download it here.  Upon opening SharePoint Manager 2010, all Web Applications should all be expanded.  For every web application, expand the Job Definitions branch and attempt to find your timer job.  If your timer job is listed there, right-click it and select “Delete”.

To be safe, you should repeat this process locally, on each of the SharePoint servers in the farm.

Step 5) Check that the .dll files for the solution were removed from the GAC on every single SharePoint server in the farm.

This is accomplished by navigating to C:\Windows\assembly on the file system.  If your solution is still listed in this folder on any of the SharePoint servers, then the problem may not be isolated just to Timer Jobs.

Step 6) Restart the SharePoint 2010 Timer Service

Click Start, and then type services.msc into the “Run” box.  Scroll to the service “SharePoint 2010 Timer”, right-click it, and select restart.

This needs to be done on Every Single SharePoint server.  SharePoint timer jobs run within the OWSTimer service process, which in turn may run on any of the SharePoint servers.  Therefore, if you forget to restart the SharePoint 2010 Timer Service on even a single server in your SharePoint farm, you may still fail to resolve your issue.

Step 7) Run an IIS Reset on each of the SharePoint servers in the farm.  This is accomplished by opening the windows command console (cmd) on each SharePoint server (as an administrator), and simply typing iisreset.

Optional Step 8) Reboot each Web front end and Application server. 

Step 9) In Visual Studio, change the name of the project assembly file.  We want to ensure that on your next deploy there is no possible conflict within SharePoint with the old assembly code, and this step helps ensure that.  Due to the manner in which SharePoint works, simply ensuring that the old assembly file is no longer in the GAC (C:/windows/assembly) is not necessarily enough to ensure that the code is no longer stored somewhere within the SharePoint farm.

If you are unfamiliar with this process, open the solution in Visual Studio.  Right click on the project in the solution explorer, and then click Properties.  In Visual Studio 2010, you should be greeted by the following screen.

Simply change the textbox here labeled “Assembly Name” and then save your changes.

Step 10) Open the AssemblyInfo file in your Visual Studio project, and change one of the assembly attributes.  After you deploy the project, these values will be viewable in the GAC by right clicking the file, and selecting properties.  Changing them here, now, will allow you to double check that you deployed the correct version of this solution to SharePoint in a few minutes.

Step 11) Timer Jobs are traditionally configured via the use of an event receiver. 

When you create a new feature event receiver, you are shown the default options of FeatureActivated, FeatureDeactivating, FeatureUpgrading, FeatureInstalled, and FeatureUninstalling. 

What you might not know, is that if you fail to implement one of these options, SharePoint 2010 will NOT resort to default behavior should that method be called.  Instead, it will simply not run this command behind the scene.  As such, you should make sure that at the very least, you have defined your timer job event receiver to include the FeatureActivated, FeatureDeactivating, and FeatureUpgrading overrides.

Step 12) Redeploy your new version of the Timer Job to the SharePoint farm. 

Optional Step 13) Once the solution is deployed, check the GAC to ensure that the assembly is the new version of your project. 

If your timer job does not now work with the expected behavior, please feel welcome to respond in the comments.  I hope this helps, and good luck out there!

By: Robert Christ