Maybe my google-fu is failing me, but I cannot seem to find any information on the following:
My Windows user account was recently moved, accidentally, to another domain in my company's Active Directory. While in the other domain, I was unable to access my data stored in TFS 2008 (e.g. shelvesets, pending changes, workspaces, etc). I assume this was because it was associated with my ORIGINALDOMAIN\userId account, rather than NEWDOMAIN\userID account.
My account has now been moved back to ORIGINALDOMAIN, however I still cannot see any of my data in TFS. In fact, it appears that all of my data (all my shelvesets!) have been deleted. It is almost as if TFS saw that my userId had disappeared from ORIGINALDOMAIN and assumed that I had been "deleted" and thus deleted all my data.
Has anybody else encountered this? Is there hope for my data or am I royally stuffed?
Thanks in advance,
Steve
Update: I have now managed to track down some of my old shelvesets by doing a search for "*". Oddly, the shelvesets are now associated with NEWDOMAIN\userId. If I do an explicit search for shelvesets belonging to NEWDOMAIN\userId (or ORIGINALDOMAIN\userId) nothing is found. Still no trace of my pending changes or workspaces though...
So, I think I have (partially) got to the bottom of the problem. It appears that my data has been assigned to a user id of the form DOMAIN\userid:number, instead of simply DOMAIN/userid as might be expected.
This means that I can now find my shelvesets by searching for the fully qualified id. I still don't see any solution for resurrecting my previous pending changes or workspaces, however at least I can now retrieve the shelvesets back into my correct id.
Panic over for now.
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.
We're having some serious issues with the mfbclient.exe tool that is part of the feedback platform of VSTS. Basically, our stakeholder's uploads are not being sent.
This is extremely frustrating as you can imagine, as the ability to take screenshots etc is a major benefit of using the tool.
Members of the development team who have VS2017 installed on their machines as well as the feedback tool, can access the feedback request via the email that is automatically sent out when you click on "Request Feedback". Everything works perfectly.
If we send the request to a stakeholder, they can click on the link and it opens up the tool correctly, they can step through the items and make notes etc., and when they submit, their responses come through into VSTS. However, none of their attachments come through. They all say '(Uploading) filename.png' in VSTS.
Upon looking at one of the stakeholder's machines, I can see the mfbclient.exe tray icon says '0MB of 10MB transferred'. Restarting the machine doesn't change this - the attachments don't get uploaded.
Upon further investigation, under %localappdata%\microsoft\team foundation\x.0\testmanagement\ i can see an XML file which contains the list of all the screenshots / attachments etc that are to be loaded. The screenshot files themselves also exist (so, the files aren't missing/deleted). For some reason, the files just aren't uploading.
If I remove the XML file, it clears the attachment 'queue', but as soon as more feedback is entered and a screenshot added, the same issue occurs.
I noticed there was an mfbclient.exe.config file, which I edited on one of the stakeholder's machines and changed the trace level to '4' (verbose), which I thought would shed some light on the issue. However, I can't see anywhere that the logs might be. Does anyone know?
I have tested this with the stakeholder being part of the exact same security group as myself and the team (as I thought perhaps it was a permissions error), but this doesn't change the behaviour.
The only real differences I can think of between myself and team, and the people who are having the issues (and there are quite a few users who have the same issue so it's not just 1 person's problem), is that these people are stakeholders rather than subscribers (shouldn't make a difference), and they don't have Visual Studio installed on their machines (also, shouldn't make a difference).
Can anyone please shed any light on this issue? Has anyone else had the problem? Can someone from MSFT help?
Just as Sebastian mentioned, the solution is changing the Access Level from Stakeholder to Basic.
Basic provides access to most features, except for Test and other premium features. Stakeholder access to those users who need to
enter bugs, view backlogs, boards, charts, and dashboards, but who
don't have a TFS CAL. See About access levels for details.
Basic provides most features, Stakeholders can use the Feedback Client since TFS 2013 Update#5 based on this user voice. Can't attach pictures seems a permission limitation for Stakeholders.
Whatever seems it's by design or a feature missed or an issue on current version of TFS and VSTS based on the Stakeholders license limitation. However the requirement make sense and I have submitted a new user voice here to suggest the feature, you can go and vote it up to achieve that in future.
UPDATE:
I agree with your point of view, it's more inclined to be a bug. And you have submittetd a feedback here: Feeback Client - Upload fails for Stakeholder
Whether user voice or bug, development team will take care of them. So, let's wait for the response. And for now, you can change to the Basic Level to upload the pictures.
I have the same problem with our VSTS.
The problem really is because of the Stakeholder-License.
If I submit a feeback with a stakeholder account the upload stays at 0%. When I change the user then to Basic in VSTS, the upload starts automatically and completes.
EDIT: this issue has been fixed, as per this forum post: Feedback Client - Upload fails for Stakeholder
I have one folder in TFS and I have given rights as Contributor that's mean they can do check outs/check in/locks etc. But I would disallow them to delete any file or subfolder belonging to main folder. Please let me know if you have any idea in this regard.
You cant, but on the other hand a delete of a file only hides the file. In order to 'permanently delete' a file you need to run tf destroy on the file , and that requires the user to be a part of the tfs administrator group .
Read more here
You can't. I think this is something you will have to manage by process and not technology I'm afraid.
Any operation (excluding a destroy) can be undone.
As was already said, this can't be done with permissions. If you absolutely need a way to prevent this (and rolling back the delete afterwards is not enough), you have two possibilities:
use a Checkin Policy to warn the user that he should not delete elements. This can be overridden by the user, so it's not an absolute, but they know they may only do this with your permission. If they still check in without permission, you can still roll back. Biggest drawback: You need to distribute a dll file to all client PCs everytime the policy is changed, because the checkin policy is executed on the client.
set up a serverside pre-Checkin check. You can write against TFS API to react to different events, such as pre-Checkin, post-Checkin etc. In those event handlers you may perform checks, e.g. "is a delete operation contained in the changes the user wants to check in?" and make the operation fail if that's the case. This cannot be overriden by the user, but is a lot more effort to implement and maintain imho.
That said, I would propose setting up "checkin conventions" the users are supposed to adhere to, and roll back any changesets where they don't. Possibly supported by variant 1. to remind the user that what he is doing is not permitted.
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.
I have some users in bit bucket cloud who left organisation, I want to remove them from my account so I can save billing.
My question is if I remove access will there be any problem with commits and work they have contributed to the projects or repositories over the time?
I have already tried checking on their site, but there is nothing mentioned specifically.
Commit history will not be affected (unless you, or somebody else on your team, rewrites it). The users in question will still have any previous copies of the repo they'd cloned or downloaded, but they will no longer be able to connect to push or pull or read code in the GUI.