We are running TFS 2012. Our organization is currently creating new accounts for everyone as part of a migration.
What I know is that everyone will have two accounts listed in AD for a while:
OldDomain\DoeJ
NewDomain\DoeJ
This brings me to believe that SID will be different, among other things.
My question is, how would this affect our TFS environment? Will we lose any history associated with particular users? Will I have to go through each work item and reassign it to the new Windows account? Is there any way I can preserve this data?
Thanks
You could use Identities Command which lists or changes the security identifier (SID) of users and groups in your deployment of TFS. You might need to change or update the SID for users and groups in one of the following scenarios:
changing the domain of your deployment
changing from a workgroup to a domain or from a domain to a workgroup
migrating accounts across domains in Active Directory
Even though it's a powerful tool, but it has certain limitations. To help ensure a successful move, make sure that you understand the following requirements:
Once a user account is present in TFS, it cannot be removed or have another account mapped to it. For example, if you are moving
DomainA/UserA to DomainB/UserB, the Identities command would only
work to migrate the user if DomainB/UserB is not already present in
TFS.
Because the members of the local Administrators group are automatically added to TFS, make sure to remove any accounts that you
want migrated from that group before you change the domain or
environment.
Suggest you read up about this tutorial as part of planning your move. You could also take a look at this blog : Migrating TFS Server or Collection to another domain. Be careful do not add the user such as NewDomain\DoeJ to TFS first, after upgrade SID, the history will keep without any problem.
Moreover, TFS use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). You can force the job to run using any of these techniques.
Related
I have been converting access to Team projects using Active Directory groups.
I am a project collection admin and we host around 40 odd team projects.
On all the other proects everything is fine, I have been able to add all the AD groups I needed to the Various TFS groups that exist in a Team Project (Contributors, Readers etc).
When I come to the problem project I can see the add button, and I am able to search for and select the AD group I want, but when I click save, I see a red banner message with the text:
Unable to add members to this group.
Failed to resolve the specified groups to join.
You do not have sufficient permissions to add members to the following groups:
[Team Project]\Build Administrators
I have looked at the oi and all I can see around the time of the issue are activities reporting a 200 response.
I am looking at the api and the database to see what I can do but not sure where to start. I thought I might be able to see something about security but it is asking for a guid that I am not sure how to get hold of.
Looking at the database I thought there might be a security table, but not sure where to start.
I'm going to keep looking at what to do, so I am going to keep this updated
update 2019-03-27
We have a support call open with Microsoft, I still have issues managing the teams, but I have been able to update the team via the Apis, I even found a useful little CLI tool to help with the tasks I needed to do.
In my case, I was trying to add someone to a group that I was in - which I don't need since I'm a Project Administrator. Once I took myself out of the group, I was able to add others again.
Got the answer and the fix worked.
After a lot of back and forth, sending files and running some tfssecurity queries, they were able to determine the problem.
What I had done was add the domain User AD containing our project collection admin account in as a project reader, as the security on tfs works on a least level principle it was then applying a deny permision on my Project collection admin account, by simply removing the AD group from the reader level, which I was able to do, the ablity to manage the securities came back.
I havent been able to find the specific group that I belonged to that then set the deny, but there is no denying that removing the AD group from the reader level fixed the issue.
I am trying to migrate source control only from a TFS2013 system to VSTS and I have a question about how to manage user migration.
We have been using TFS since it was released and have a >250000 changeset history that we would like to preserve.
We have linked our Azure AD to the VSTS project and I have added in a relevant group that contains most of our current users, but these are not showing up in the user mapping screen presumably as they are not 'proper' users until they have logged on and applied their MSDN license. Is there an easy way of adding around 200 users to the system and applying a license?
Most of the other users that require mapping have long since left the company but it is useful to see which person made which changeset. This class of user will never have an active account on TFS but the current system would force me to remap these users to a current account losing that information. Is there any way of keeping this data?
Not exactly like this - How to publicly share a Visual Studio Online Repository? - I am trying to share the source code repository (Git) from Visual Studio Online to registered stakeholders. They need to get at the latest stuff at the Master branch to eval it along with work items. How can I do that?
Thanks.
If you have people with a Stakeholder license they won't be able to see the code. The Stakeholder license only gives access to:
View team dashboards and portfolio backlogs
View, add, and modify items on the backlog
View, create, and modify work items such as stories, features, and bugs
View, create, and save queries
Create and receive alerts when changes are made to work items
Submit, view, and change your feedback responses.
For people to see the code, they will at least need a Basic license. If you then want to restrict their access, you can do so by creating a TFS Group and setting the correct permissions. In this case, you want to limit the Code permissions to only Read so they can't modify the code.
See Permission reference for Team Foundation Server for more information.
This means there is no free way to allow users to read your code. You do start with 5 free basic licenses however, so if that's enough you can assign those to your users.
We have a situation where TFS was taken into use when we all had 2 user accounts. We started using TFS with account A but, after a while, found out that account B was better. In the end we want to use the A accounts only for RDP sessions. We would now like to remove all the A accounts from TFS so that we don't make mistakes in assigning tasks to a person.
Deleting the old accounts from the AD is not an option, we still use those accounts for RDP sessions. What we did was migrate all the WI's from account A to account B. Thereafter I removed all permissions for the old A accounts, with in mind that TFS would clear those accounts since they are no longer in use. The double account in the assigned-to field
Unfortunately the old accounts are still visible despite they are no longer involved in any project or group. No rights for the (development) user
How can we remove those accounts from TFS? Maybe there is somekind of cache that needs to be cleared somewhere, or a rebuild of the warehouse?
Thanks in advance!
By Default the Assigned To field shows the list of all Valid TFS Users (this is a specific TFS Group). So if you don't want somebody to show up in that list you have to make sure they are not in the Valid TFS Users group. If you inspect this group in the TFS Admin interface you can see which other groups are members of it. Now it's just a matter of tracing through the many TFS security groups to make sure that those user accounts are not included anywhere that would result in them being part of TFS Valid Users.
Does anyone know if it is possible to prevent a work item from being assigned to a specific user account in TFS?
After migrating a TFS from one domain to another, some of my team members have two user accounts, the original one from the old domain, and a new one from the new domain. I'd like to stop work items from being assigned to the old account.
Most process templates restrict username fields with the rule. (If yours doesn't, you should do so.) Then all you need to do is remove the invalid accounts from TFS Valid Users group.
Unfortunately, you can't do this directly -- TFS manages this group automatically based on ACLs found throughout the rest of the system. You have to hunt them down. See these threads for more details:
http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/6e5af2ab-1cbc-4d12-9078-454147926316
http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/1ce8b5b0-9924-45ed-919b-49a6a61bb7c7
Once you find all instances where the old domain is being referenced, the general strategy for cleaning up orphans is to add a new ACL, wait for TFS to sync (or iisreset), then remove everything.
However, this may not be possible if you've taken the old domain offline, or there's no trust relationship between the two domains, etc etc. At some point it becomes easier to edit TfsIntegration manually. I usually don't recommend mucking in the TFS databases since it's unsupported and subject to change with every patch. For optimum safety, I'd still strongly suggest using stored procedures rather than trying to interpret the schema relationships (and make sure you hold the necessary locks, etc). prc_security_delete_identity is your best entry point: all you need to know is the old account's SID.