Last week I upgraded our TFS 2012 Server to TFS 2013. I read the MSDN documentation first and I also followed the documentation as I performed the upgrade. Everything seemed to go ok.
After the upgrade I ended up with 7 or so Team Projects that the wizard couldn't configure, for whatever reason, and needed manual configuration.
I noticed this week that ALL of the work items under one of my Team Projects are missing. Gone. Like even if I select Team|Go To Work Item and enter in a known Work Item Id, I receive an error that the item is either missing or I do not have permission to view it. I'm an Administrator on the TFS server and I'm the TFS Admin, so I highly doubt permissions are the issue.
I remoted into the server and launched SSMS to explore the raw data. I know for a fact Work Item 450 is missing (it's the only Id I remember at this point). I selected the TOP 1000 from WorkItemsAre, which seems to be the table that holds the Work Items (?). There is a gap in the Ids, I see 1-448, then the numbering picks up again at 457. So, somehow my Work Items appear to have been deleted. I stopped there, I assume there are more gaps since I'm missing more than 9 items.
Now I haven't gone through every one of our Team Projects. I've only touched 3 of them since the upgrade. Thankfully the largest, most active Team Project, with the most work items/version history seems to be intact. I'm not sure if any other Team Projects are missing their Work Items too.
Has anyone else experienced this? Does anyone know if there's some "secret squirrel" way to recover these missing work items, or have they been hard deleted and are gone for good (other than looking through tape backups of the server).
Any advice would be appreciated.
I already migrated to TFS 2013 from TFS 2012.
The problem of manual configuring the project may occur when you have customized work item types in TFS Project Templates. Did you customize your project templates?
Although, I can hardly believe that work-items getting hard deleted from TFS. This issue may occur probably because of archiving during migration. The workitems that TFS upgrade wizard may not have "understood" during migration/upgrade, might be archived and moved to another table in database Tfs_DefaultCollection.
You may want to consider that. I am not sure if that may be the case, but this happened when we migrated from TFS 2010 to TFS 2012 because we had many custom work items in TFS 2010. Hence we had to standardize templates before migration using powershell. But we lost some amount of history.
Hope that sparks some idea.
Related
The date of Team foundation server changed to the year: 2023 and after that non of the defined work items can be found at the board. Neither they're accessible by querying. As it seems they're lost for only a certain project. All of the other projects are alright.
They didn't appear even after correction of the date.
How can I get the disappeared work items back?
Please check the work items not only in VS but also through web portal.
If you could also not find the work item by entering a known Work Item Id. Suggest you remote to your TFS database server and launched SQL Server Management Studio to explore the raw data. Double check if the workitems are still stored in database.
If not you may have to restore your last back-up TFS database. Otherwise suggest you clear TFS and VS cache.
I am currently trying to solve an issue with our current on-premise TFS 2010 Server where I have 2 collections and both of my project collections were set to offline due to some tinkering with trying to upgrade to on-premise TFS 2015.
Whenever I try to activate the desired collection, I am getting the following error:
TF253021:The following team project is duplicated in at least two team
project collections: ProjectName. The collection cannot start while
the duplication exists. You must delete this project from all but one
of the collections before the collection can be started. The project
exists in the following collections: CollectionA, CollectionB.
I also had a look at each of their settings, and apparently the database connection string for both collections are pointing towards the same SQL Server instance and the same database. Both collections also have the same number and names of all team projects too.
I'm thinking of deleting one of the collection and its projects, but I fear that if I do it, it may delete the same collection and settings for the second project collection that I'm trying to set online.
I'm wondering if anybody has encountered this issue and what steps have he/she has done to fix it.
Many thanks!
You've gotten yourself in a remarkable situation, which may need Microsoft support to chime in. Even with creative backups I'd be unsure whether you'd get yourself in an unsupported end-situation.
If you have a backup of the whole situation before you started this experiment, I'd recommend going back to that.
You may find yourself in a catch-22 situation, since TFS 2010 has passed it's support lifecycle. Mentioning it happened while preparing for a TFS 2015 upgrade may convince them.
You can find the contact details here:
https://support.microsoft.com/en-us/contactus/
I'm using TFS 2015 on-prem and I'm using the standard SCRUM template. I have 1 Team Project and I'm using the team field to segregate work. I have created a few build definitions and ran a few builds over the last few weeks.
When I installed TFS I did not install or configure Reporting Services straight away as I had planned to do that later. I have since done this and I now have my Tfs_Warehouse which is updating with most things but NOT FactBuildProject or FactBuildDetails. Some of my other facts are pulling over, such as FactCurrentWorkItem and even FactBuildCoverage. I have rebuilt the warehouse in the TFS Admin Console.
As this is a standard process template and standard reports I expect that the required fields should be set to reportable.
How can I get data in my FactBuildProject table and where can I look for issues with it? I'm not sure where to start and I can't find anyone else in the world with a similar problem.
If you are using the new task-based build system, then you are out of luck, since that data is not being propagated to the data warehouse.
Check the comments on this blogpost: http://nakedalm.com/create-a-build-vnext-build-definition-on-vso/
I’m beginning to consider moving an on-prem TFS 2012 installation to Visual Studio Online. So, one of the first things I started investigating was how we might export our content back out of VSO in the future if we ever decided we needed to. The more I’m looking, the less I’m finding. It seems there was a temporary time period when VSO first went GA that Microsoft offered that capability if you asked to have it done (http://www.visualstudio.com/en-us/news/2014-apr-3-vso.aspx). By implication, that would seem to mean that this isn’t something that is a planned feature of VSO.
Making a commitment to house all of my source and ALM data in a repository I’d effectively be barred from leaving doesn’t sound particularly appealing. Am I missing something, or does Microsoft really not have export capabilities on their VSO product roadmap? It would seem that this would be a show-stopper for many organizations from coming onto VSO, which is a perfect application to put into the cloud IMHO.
For code you can use Git. Even if you start with TFVC, you can use Git-TF. Clone with the --deep parameter to get the full history in a new Git repo, then push back to a new project (Git or TFVC).
For work items the TEAM tab in Microsoft Excel is a very capable export facility for work items, though you don't get links (other than parent child), or attachments.
In the original project, create a query that lists all your work items.
Open Excel, go to the TEAM tab and click 'New List', you should get the option to select your project and the query you just created.
In the Work Items tab select the 'Choose Columns' button and select all the columns you want to migrate.
If migrating to another TFS / VSO project, create that project, open another list in Excel connected to the new project.
Cut and paste all the work items from the original project list to the new project list (excluding the Id column).
Publish.
voilà.
You're right there's no good solution for this yet. However, if you're using Git as the source-control back-end (instead of TFVC), you can easily pull down the entire repo then push it up into any other source control server (non-VSO) with full history.
For TFVC source-control, or work items (or builds, test results, etc), things aren't so easy.
The answer is not black and white: with the TFS Client API you can connect to both platform and read/write as you please. It is not a trivial task, so someone has created tooling, like Brian says. Another option is using the open source TFS Integration Platform: it is complex but with some help you can do it.
What you really must consider and plan is the data model: moving from an ALM Platform to another is never trivial and the complexity lies in the difference of the underlying model and any customization you made.
As long as you do not customize you on-prem TFS, it is very doable, with a reasonable effort to move to VSO and back. In this context customize means: custom workitems fields, types or workflows, server-side plugins; shortly anything that requires code or schema change. Note that you can still customize builds as this is properly managed.
I expect to see more solutions arriving thanks to the new REST API, but it will take time before we see solid products.
So your original question has a positive answer (TFS on-prem -> VSO) using OpsHub, but know what you are doing and, as I write, it is practically a one way journey.
We have recently migrated to TFS 2010 using the MSF For Agile process template and we make use of such reports as the Burndown, User Stories progress etc. Up until 13/10/10, our warehousing worked perfectly and all our reports displayed upto date data. However, after this date, the reports started displaying old data and on looking at the status of the warehousing jobs using the GetProcessingStatus() method on the WarehouseControlWebService, we can see that the Work Item Tracking Sync job seems to be stuck in the 'Running' state.
Indeed, when you put a profiler on the database, you can see the same stored procs being called again and again, with the same parameters, as if it is stuck in a loop. While this is happening, the CPU usage is 50% and above. It stayed in this state for over 24 hours before I decided to kill it.
There is nothing particularly crazy about our setup - we did a clean TFS install and imported work items from TFS 2008 using Excel. We also have a custom work item template 'Support Ticket' which our support team use to log calls from customers. All importing was done with the proper TFS command line tools or Excel.
Has anyone experienced anything like this before? I have seen a couple of posts where people have had similar issues but not seen an answer.
I am delighted to inform everyone that we managed to fix it! The issue was a rogue work item (Bug) which had a link to a Task which did not exist. I am not quite sure how this happened but can only assume it happened during our work item import from TFS 2008.
We only noticed this because, as a last resort, we were going to create a brand new Team Project Collection and Team Project, and import all our work items into it and see if the warehousing worked there. However, when we viewed the 'All Work Items' query as a tree view in Team Explorer prior to the import, one of them was highlighted in red with an exclamation next to it saying the referenced item does not exist. We simply deleted them item using 'witadmin destroywi /collection:http://tfs2010:8080/tfs/<> /id:1571' and then magically the warehousing worked again. Marvellous!
If this post helps even one person then I am a happy man as this has caused us much heartache over the past week. Although we have managed to overcome the issue, it can't be denied that Microsoft's error handling in TFS leaves a lot to be desired.
Yours
Dan