I have been working on site that has had to do a disaster recovery of their TFS application tier (AT) due to hardware failure. For a short period they have had to use a spare PC as their AT. Due to the hast required to get the developers working this AT was only configured to for source control and work item editing.
So I was onsite to put the proper replacement AT in place. All seemed to go OK until we added a new Iteration to a team project. It did not appear in the IterationPath field for work items.
This problem actually manifested itself for us in the inability to add a new sprint from inside eScrum. Unlike most team process templates the eScrum front end creates sprints by creating an iterations and an associated work item (to hold extra information) all in one go. This was failing as after the iteration was created it’s creation was not propagated to allow a work item to be associated with it.
After checking the ATs event log we saw TF53010 and TF51338 errors. I then ran the TFS Best Practice Analyser (BPA) and this showed two issues:
- the MyDomainTFSService account not being in the TFS [Server]Service Accounts group**.** I think this was due to fact that the temporary AT system had used using different accounts and the installation of the new AT had left some behind.
- due to this the TFS Scheduler was not running reliably, this would explain why the new iterations were not being propagated.
We fixed this using the tfssecurity /g command to add the MyDomainTFSService account to the TFS [Server]Service Accounts group and then restarted the server.
Once this was done we checked the configuration was right using the BPA again, and finally checked we could create sprints in eScrum.