Sunday, February 02 2014
Keywords: TFS 2010, Backgroud Job Agent, Active Directoy Sync job, Refresh Identity, Security Cleanup job
Undocumented TFS 2010 Background Jobs that perform Clean-ups, Refresh Identity, AD Sync etc
As a TFS administrator you would want to know about these internal jobs for two reasons:
- There are some situations such as disaster recovery or migration of a production TFS server where you do not want internal jobs to run and interfere with the process until you are done.
- TFS permissions are out of sync with Active Directory, or TFS Groups are out of sync.
I have included the scripts for this article on the bottom of this page.
All scripts are applicable to TFS Configuration database, and not to any specific collection where you save your source code or work items. The name of TFS Configuration database could vary from one server to another, since it's customizable.
TFS ships with a dozen of internal jobs, found in tbl_JobSchedule table. But to queue them you would need one more piece of item: Collection ID. TFS also calls collections "Hosts", and their ID "HostID".
There is only a very limited amount of info given to us on the internal jobs, with absolutely no description of what they perform. The only two columns of importance for us in tbl_JobSchedule table are JobID and Interval.
Interval represents the number of seconds between two identical job type instances automatically scheduled to run by TFS Backgroud Job Agent Service.
The only two TFS internal jobs of interest to me have been:
- JobId '544DD581-F72A-45A9-8DE0-8CD3A5F29DFE' : Active Directory Sync (aka Refresh Identity). Applies the latest AD changes to your TFS, including explosion of hierarchies etc.
- JobId '63A78C70-8FE0-4743-BA2D-A00CF8C20FDF' : Security Identity Cleanup job...If users and TFS groups go out of synch, it wouldn't hurt at all if you queue a job of this type.
Looking up these two jobs in the tbl_JobSchedule table gives you an idea of how often they run on your specific server.
You could modify the interval value. For example I set this once at 1 minute, because I was doing tests with permissions and groups etc...but I reset it afterwards to its default value. You could also set a very long value in order to delay a specific job type from being queued until you are done doing a DR or AD modification task.
Queuing these two jobs does not hurt at all...do not forget that these jobs must run every day or hour anyways, and do not take much time to run neither. So if you are ever unsure or suspect an out of synch user or group...feel free to queue either or both of these jobs. A job is not server wide...it is collection-wide, you will need to queue one job per collection.
tbl_JobQueue shows you all jobs that actually queued to run on the server...some could be scheduled to run immediately...some in many hours from now.
tbl_JobHistory will show you exactly what it says...including which job ran for which collection, how long it took, was it scheduled manually or automated, and if it was successful at completion time.
If you are a DBA, one thing you will notice and definitely dislike seeing (once you open the entire table with a select *) will be the fact that this table is huge and will contain hundreds of thousands of records in a year in a busy server containing multiple collections....old historical info occupying lots of place...after all you will not need to know if a job ran 3 years ago.
How to stop a job? You could stop a specific job by altering its interval value in tbl_JobSchedule and then making sure there is no instance of this job running in tbl_JobQueue . And finally restoring the default interval value back.
Perhaps a more supported way, as suggested in MSDN, would be to stop the Windows service in charge of running all these jobs...in fact you are recommended by Mirosoft to stop this service in times of DR or Migrations.
Written by Montreal DBA Team