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/
Related
I have a TFS 2015 installation where we have a rather big number of projects. Currently there are old projects, that aren't used anymore but need to stay available as an archive (read only).
I'd like to make a workspace or something in TFS so that these projects normally don't come up in the normal view.
One way I found out is to set the TFS offline, make a copy of the database, bring the copy of the database online and then delete all projects that are still active and rename it. After that bring back online the original database and delete all archived projects.
This can be done once. Maybe once a year, but it will result in a large number of databases. This will make it worse than leaving the inactive projects in the workspace.
Does anyone have better idea? Or: What do you do with old projects?
First, there currently is no archiving function on TFS. However you can use something else as a workaround. To do this, you can either create a project designated as archived that you then have to assign permissions to and so on or move the project into another collection using the TFS Integration Toolkit.
Set the Read permission to Deny of contributor group will hidden the collection to come up in the normal view.
Below are some related blogs for your reference:
How to: Archive Team Foundation Server Team Projects
completely archive a TFS2012 project
Moreover, there has been a feature request in UserVoice, you can also vote up it to get more attention.
The process you are using (cloning a collection) would be the only method to achieve an archive as you describe it.
I would start by understanding why you have so many projects! Prefer larger Team Projects that contain many Products, Projects, Teams that are easier to manage.
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/
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.
Is there any focused documentation on achieving the following with TFS. I find myself having to read through tonnes of documentation on MSDN and I find nothing is listed under topics as such or maybe I don't know what to look for. I have no experience in TFS other than checking files in and out and I am still trying to understand what each of these mean and how to find it in the docs, without much luck.
Gated check-in + continuous build for select projects.
Gated check-in + scheduled builds for other select projects.
Dashboards and reporting to select individuals or groups
Access for testing team members to only selective work item creation of the TFS project they are assigned to. They
should be able to get the latest version of the code and be able to log a workitem-bug, workitem-issue, workitem-testcase but they should not be able to create for eg. workitem:use case.
Testers should not be able to modify code.
Sending mails to persons who have a work item assigned to them, with
select persons in copy.
Sending of emails to anyone against whom a bug is assigned. When bug
is closed the person who raised the bug should get notified via
email.
Sending mails to key persons of a project defined somewhere in TFS,
on build failure of that project.
If anyone has already done something like any of the points listed above then can you please let me know the steps? Somehow the documentation jumping too many links and going in various tangents.
Thanks for your time and patience..
In order:
Go to the Microsoft TFS site at http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx. Look for the training videos. Most of the stuff you want is covered.
The Visual Studio Team Foundation Server Branching and Merging Guide at http://vsarbranchingguide.codeplex.com/ is an excellent guide.
The Introduction to Visual Studio Team Foundation Server 2010 Training Kit at http://www.microsoft.com/en-us/download/details.aspx?id=27152 is helpful.
We're starting to user Team Foundation Server and my boss would like some way to "archive" projects. Meaning after they are completed, remove them from an "active" state so that only "active" projects are visible.
Does anyone have any experience with this?
I've thought of 2 options.
1) Create 2 base projects. 1 for active projects and 1 for achived projects
2) Remove all users from the archived projects.
Thanks,
Sam
I would personally recommend waiting for TFS 2010 when more functionality will be introduced that will assist you in the ability to "archive" Team Projects.
In TFS 2010 you will hopefully be able to move a team project to a new Team Project Collection. Actually you do this by duplicating your "active" project collection and then deleting all the team projects from it apart from the one that you want archived. In this active project collection, delete the archived project that you have a copy of in the duplicated project collection. This archived team project will then live in it's own project collection which means it has it's own database etc which can be easily backed up / archived etc.
The archived team project project collection can then be left as it is as it doesn't slow down the server any if not being used - or it could even be detached from the TFS Application instance so that it doesn't show up at all and re-attached at any time.
An advantage of using project collections in TFS 2010 is that full Version Control and Work Item Tracking history will be maintained.
I would use it just as you normally do, but when you are done with the project then you remove it from the visible list. (In Visual Studio you can right click on a project in the team explorer and say remove.)
If you are worried about changes after the project is done, then remove the users from the contributors list. If you really want to boot the users out (so they cannot even see it) then you can deny them rights to the project.
This way you don't have to see it, but you can keep all your projects on the base level.
I would NOT recommend having just 2 base project for active and in-active. A TFS project should not be based on a state.
We created an "Archive" team project and we regularly move unused source code to that team project. It has worked out well for us, the history is preserved so we can always reference the archive project for old code or information on past changes. We also limit access such that developers have read access but only TFS administrators have write access. I haven't checked to see how these moves impact the association of check-ins with work items - mostly because everything we archived was checked in before we moved to TFS.
As for the one active team project, I was led to believe by knowledge experts and online documentation that this wasn't the best way to organize team projects. I think ideally you group projects/solutions together into a single team project if they are related (i.e. by line of business or dependencies).
I'm sure you've already done your research, but there is plenty of documentation out there that might assist (especially if your team maintains a single application or a handful of applications). I would suggest starting with patterns & practices: Team Development with TFS.