I'm trying to check in changes to TFS using VS2013. When I hit the button to submit, TFS returns the following error, "TF14002: The identity {domain} \ {oldaccount} is not a member of the Team Foundation Valid Users group."
Background: my account name has been changed to {newaccount} from {oldaccount}.
When I first started working at this company I'm almost certain I set up my TFS with my old account. But I thought I deleted all that stuff related to my old account and reset everything to my new account. My lead tech has even shown me the account mngmnt screen with my new account name. And I've been able to check out items with my new account name.
I performed the following steps to try to "clean out" TFS:
• I copied all of my changed files to a back-up location.
• I undid all changes in TFS (note that TFS has been allowing me to check out files to edit).
• I deleted the TFS entry in Credential Manager per a suggestion online.
• I deleted my Workspace.
• I even deleted my TFS server.
• I Rebooted my computer.
• I reconnected to the TFS server.
• I rebuilt my Workspace.
• I restored my changed files from my back-up location.
At this point I tried checking-in my changes again but got the same error message as above.
Any suggestions?
Note that I do NOT have access to the TFS server, much less permissions to perform any sort of admin on it (and I don't know the person who would). So any suggestions beyond simply tweaking my computer will require a trip through the bureaucratic swamp.
One possible positive (related to this issue) is that we've been informed that a number of us need to downgrade from "Ultimate" to "Professional" so if your suggestion is to reinstall Visual Studio, the upside is that I'll be doing that soon anyway.
Thanks,
Doug
EDIT:
Additional Info: I deleted everything in this folder:
C:\Users\ ...\AppData\Local\Microsoft\Team Foundation\5.0\Cache
... but I'm still seeing the error.
UPDATE 1/24/2015:
I did finally "downgrade" from Visual Studio 2013 Ultimate to VS2013 Professional, but I'm still experiencing the same error. Might there be a table in the TFS database that still has an entry for my old account that could be joining to my computer name &/or new account name when TFS goes to look up my account info when I check in my changes? I am getting desperate for an answer!
An addendum: when the sys-admins changed my account name they did not update my computer itself, so I'm still using C:\Users\{oldaccount}. I can't believe that would make a difference but you never know....
UPDATE 2/27/2016:
Sorry for not updating this sooner. I resolved this issue with the help of our DBAs:
There is a table named Constants which contains the domain part and a field named “NamePart”. The resolution was to simply update “NamePart” to “{newaccount}” from “{oldaccount}”. This table also has an SID field which is the user’s SID from the computer’s Registry. You'd only change the SID if a new login to your computer was created. In my case, there was no new login account, just a change to my login account -name-, therefore, no new SID.
And a side note, for situations when one’s email is also spelled incorrectly, there is also the ADObjects table which contains a field named “MailNickName”. This field should be updated as well when a user name is misspelled. For instance, I had the DBA update that field to change “Dug#NotReal.net” to “Doug#NotReal.net”.
Updating the Constants table is imperative to making TFS work; updating ADObjects is only relevant if an alias isn’t included to forward mail from the one email address to the other.
I found a file called VersionControl.config inside of the
C:\Users\{username}\AppData\Local\Microsoft\Team Foundation\5.0\Cache\Volatile\ folder that had my old domain username in. Changed it to my new one and it started working again.
I was having the problem with shell integration, Visual Studio actually worked fine.
I should have posted my answer (update 2/27/2016) as an official Answer. I resolved this issue with the help of our DBAs:
There is a table named Constants which contains the domain part and a field named “NamePart”. The resolution was to simply update “NamePart” to “{newaccount}” from “{oldaccount}”. This table also has an SID field which is the user’s SID from the computer’s Registry. You'd only change the SID if a new login to your computer was created. In my case, there was no new login account, just a change to my login account -name-, therefore, no new SID.
And a side note, for situations when one’s email is also spelled incorrectly, there is also the ADObjects table which contains a field named “MailNickName”. This field should be updated as well when a user name is misspelled. For instance, I had the DBA update that field to change “Dug#NotReal.net” to “Doug#NotReal.net”.
Updating the Constants table is imperative to making TFS work; updating ADObjects is only relevant if an alias isn’t included to forward mail from the one email address to the other.
The above solution did not work for a developer in our company. On of my colleagues came with the simple idea to do a "undo checkout", which worked. After that the check-in en checkout worked well again.
Related
I am trying to create some local user accounts in Windows 10 on my home PC. I can go through the wizard ok, but when I try to login to the accounts I get a message similar to 'user profile service failed the logon'.
The whole story is this:
I want to add a SSD drive to my system (Dell Tower, I do not remember the model). So following some advice, it was suggested to move my user files to another drive so the SSD drive would only have the OS and programs on it. Plus this would keep my SSD required size smaller.
So I started to move my user files using the "Location" tab for the "My Documents" and similar folders to my other drive. This all appeared to work okay.
I then selected my wife's folders but I could not since I was not logged under her account, fine. I logged out of my account and attempted to log into her account (we both have administrator rights). That is when I received the 'user profile failed' message.
I have third account on the system, another admin account, and it too failed. Windows seems to be accepting the passwords, just failing further into the login process.
I logged back into my account and my desktop is completely different, there are only 3 icons there now instead of the ~20 I had before, so something with the 'move' failed? I'm not sure. I moved the files back to the default location and that did not help. I googled the 'user profile service failed' message and it seems this happens often enough that there are fairly detailed instructions about how to fix it.
The one fix was to examine the registry (this was from support.mircosoft.com) HLM\Software\Microsoft\windows nt\CurrentVersion\ProfileList and 'simply' remove the '.bak' suffix from entries that match the accounts that are broke. Set some other values to 0. In my case the values were not present in the values list.
I did this and it did not help. I did reboots at various times throughout this process, but those did not help either....
So I tried to create a new account(s), but no matter how I created the account I could never log into the account. Right now, I have only one account that I can log into.
I have not tried the "net user" command as I have just found some information about here at work. I did have to use that program to reset my account's password recently. I have used the same password at home for years, so I do not know how it changed. Luckily, my wife's account still worked at that time and it was an administrator account. So maybe that was some indication that the 'user subsystem' was failing in someway.
This PC is seldom connected to the Internet, only for Windows updates or downloading a program, like "Open Office", Paint.Net type of things. We mainly use an older XP machine for computer work and a tablet for surfing the 'net. The computer is 'new' to us and we have not migrated our files to it. In fact the PC is seldom used at all and powered off for months at a time. I am pretty much the only person that even uses the system, my wife went through a "Dummy's for Windows 10" book and decided it was too different to really bother with learning a whole new thing.
I will try 'net user' tonight to add another account and see if that helps.
Thanks for any hints or suggestions.
I'm not 100% sure what's happened, but it looks like the accounts are probably corrupted. You can do it, but Windows much prefers to have the user profiles on the same drive as the installation itself. Moving them entirely may be the cause of the issue.
(For future reference, If you want to copy user accounts across to a new SSD, it's always best to start here: C:\Users\xxxxx). xxx being your userID. If you would like to use it as your primary C:Drive for Windows - I would advise just a clean install.
You could try a couple of things at this point. (Make sure you're connected to the internet if you can)
First, try just making sure your connected to the internet and run all the updates you can. The profile service may just be corrupted and Win10 especially might just need an internet connection to sort it automatically.
Try booting into recovery mode, and run a system restore back a few days. The files may not return but it might fix the profile issues.
If you can still login to your wifes profile, use this tool (after backing up your files) to clear out all the old profiles.
Net user will likely just enable the hidden admin account, and would not be all that useful if your wife's account is already and administrator.
Newly upgraded TFS server has two user accounts created, "Project Collection Build Service" and "Project Collection Build Service (Team Foundation)". Both accounts have the same GUID (listed in the Username or Scope column). These were created by TFS and the GUID begins with "Build\" Attempts to delete either results in an error. Using TFSConfig to list user accounts, these do not show up.
To run builds, the Project Collection Build Service Accounts group must have, as a member, the Project Collection Build Service user account. Both of the accounts listed above can't be added to the group because of the matching GUIDs.
Every few hours, builds start failing with error stating
The workspace xxxx;Project Collection Build Service does not exist.
This means that the user account with the added (TEAM FOUNDATION) is in the group. If it is removed and the other one is added, builds start working again. Until a few hours later when the builds begin to fail with error stating
The workspace xxxx;Project Collection Build Service (TEAM FOUNDATION) does not exist.
Swap them again and builds start working. It appears it is applying the user account via the GUID but then doing some kind of verification based on the Display Name.
Some help pinpointing this error came from the post at http://www.codewrecks.com/blog/index.php/2016/01/15/troubleshoot-error-tf140
44-in-build-vnext-for-tfs2015/ but I can't find any other references to an issue with these accounts.
You may try to use tfssecurity /gd command to delete a server-level or collection-level group:
tfssecurity /gd groupIdentity [/collection:CollectionURL] [/server:ServerURL]
The group identity is the security identifier (SID). For more information about finding the SID of a group, see /im: Display information about identities that compose direct membership. You can also use the friendly name to delete a group.
Finally found solution at this link:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/495e59d2-d3e3-432d-be
98-1f0c358c2bc2/tf14061-the-workspace-xxxx-does-not-exist?forum=tfsbuild
After deleting all Agents and associated workspaces then adding a new agent and rebooting the server we have had no problems.
GOAL:
-To allow the manager to only view the all projects in qlikview, and not edit anything.
-Team members can only see data from projects they are in
CONDITIONS:
-Joe(Team member) can only see data from his projects only.
-Bob(Manager) can see data from all projects in the team, however he cannot edit or make changes to them.
In this scenario, there is only 1 manager, an admin, and many team members.
So I guess the process would be:
Check who the user is (Not sure what to use here. Username/password? Ideally it would be the company email, but don't know if this is possible)
Once it knows who the user is, checks if said person can access the document
If they do have access, it decides what can be accessed. (if manager, can only view all projects, if team member, can only view certain projects)
Display the dashboard.
Right now, the QVW file gets data from a database using OLEDB connection.
Sorry I've only been introduced to Qlikview about a week ago and I've been tasked to get this done so any help would be great.
Thanks.
You can find a lot about QV section access around.
Think your scenario is possible to be achieved using section access. Please read https://community.qlik.com/docs/DOC-1853 for more detailed explanation of section access methods.
Warning: Always have copy of the document without section access!
Just to be sure you are not locked out of the document because if this happens there is no way to open the document
We recently upgraded from TFS 2010 to TFS 2015. Everything appears to be fine post-upgrade, but we are getting the error "The item is locked in workspace (null);(null)." on some source control files. It looks like we have some orphaned locks that need to be tracked down and cleaned up, but the tbl_lock database table is not on the database, so the following select query won't work:
select * FROM tbl_Lock l
LEFT JOIN tbl_PendingChange pc
ON l.PendingChangeId = pc.PendingChangeId
WHERE pc.PendingChangeId IS NULL
Does anyone know how to detect and remove these locks in TFS 2015?
I also installed the TFS power tools, and neither Visual Studio 2015 nor the power tools are picking up the locks.
Updated:
BTW, when I run the SELECT query to find out where PendingChangeId is NULL, I get back no rows. I think the trick is the LEFT JOIN. PendingChangeId would be NULL when tbl_Lock also had no record for the PendingChangeId on tbl_PendingChange (and thus the lock was orphaned). So I'd still need to know where the PendingChangeId should normally be joined to in TFS 2015, to identify which files have a lock that is bad. (Or where a workspace no longer exists, which may be another possible source for the issue.)
And I also still need to know how to clean up those bad locks. I'd prefer to do this using the tools, either via the GUI or the command line, but could also do this programmatically either using the API or the TFS Object Model files for TFS 2015.
I really would rather only touch the database directly as a last ditch resort. And I would also rather use tf vc destroy on the item as a last ditch resort as well, since that would wipe out all history on the files.
Update 2
Aha! I think I found a way to identify the files, and it looks like my thinking for what happened may be correct. Unfortunately, I had to probe the database using a READ UNCOMMITTED query to find the information. I couldn't get at this information programmatically or using the tools. (They all showed or acted like the file is not checked out.) The query that I used on TFS 2015 was:
select pc.* from tbl_PendingChange pc
left join tbl_Workspace ws on pc.WorkspaceId = ws.WorkspaceId
where ws.WorkspaceId is null
This returned the three files that have the (null);(null) lock on our database, because the WorkspaceId listed on tbl_PendingChange does not exist anymore on tbl_Workspace.
How did this happen? Our CI server uses temporary TFS workspaces. I think what happened after the upgrade is that our CI server went to check out the file and apply an update to it. (For example, to increment version numbers as part of the build process.) It checked out the file, but failed to apply the update. (Our tools like working with Server workspaces, but it may have ended up with a Local workspace and thus the file was still checked in Local, but checked out on the Server. Thus the change to the file couldn't be applied.) The code that we are using performs a workspace.Delete operation when the process completes, so the workspace was deleted - even though the workspace still had the file checked out! So this created an orphan record on tbl_PendingChange that isn't linked to any Workspace, and thus the file is still locked with pending changes. But the GUI and tools aren't seeing it as such, because they're not realizing the pending change's workspace is non-existent.
So this brings me back around to how do I fix this? If someone knows of a way to get at these orphaned pending changes, I'd appreciate it. I tried using:
TfsTeamProjectCollection tfsTeamProjectCollection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(szProjectUri));
VersionControlServer versionControlServer = tfsTeamProjectCollection.GetService<VersionControlServer>();
string[] items = new[] { ... server item path ... };
PendingSet[] queryPendingSets = versionControlServer.QueryPendingSets(items, RecursionType.None, null, null);
PendingSet[] getPendingSets = versionControlServer.GetPendingSets(items, RecursionType.None);
but these aren't finding the orphans.
Update 3
I finally installed Team Foundation Sidekicks 2015 and gave it a try - status tool specifically, but then other tools. It's finding pending changes, but not the orphaned ones.
You can use Team Foundation Sidekicks to search and undo lock by following steps:
Install the tool and launch it.
Select TFS server to connect.
Select "Tools\Status Sidekick".
Set the "Search criteria" for the information you want.
Click "Search" button.
Select the locked file and click "Unlock lock" button.
You can using below command to undo the pending changes:
tf undo "file_path" /workspace:workspace_name
Or you can just use below command to delete the old workspace
tf workspace /delete /server:your_tfs_server workspace;username
From Visual Studio 2015 GUI：
File -> Source Control -> Advanced -> Workspaces...
In the dialog that came up, check "Show remote workspaces" and the locked workspace came up in the window. Then selected it and click "Remove".
Details about it, please check this blog and more ways to resolve this you can refer the similar question: What do you do if the file in TFS is locked by someone else?
Update:
According to the sql query. It's looking for .PendingChangeId IS NULL . You can use the similarly tbl_PendingChange under collection database. However, it's not a commendatory method. Since operate directly in the TFS database is not recommended.
The following command has cleared up the pending changesets that were orphaned:
tf vc destroy <itemspec> /startcleanup
After running this command, the file was able to be added back to TFS, and the file could be checked in and out and edited as normal. Running the query:
select pc.* from tbl_PendingChange pc
left join tbl_Workspace ws on pc.WorkspaceId = ws.WorkspaceId
where ws.WorkspaceId is null
also showed that the pending changeset record related to this file was gone as well.
Microsoft's documentation on this command can be found at https://msdn.microsoft.com/en-us/library/bb386005.aspx. Before using this command, you should review the documentation carefully and be sure to understand the consequences of using it.
Because this command permanently removes files and potenally all history from TFS - and does so recursively - you need to take precautions and be absolutely certain that you are targeting the command correctly. So before using this command, I would recommend taking the following additional precautions:
Stop all user and external accesses to TFS and any other software that may be running from the machine.
Make sure to run a full backup of TFS and any other databases located on the machine.
If you can, take a snapshot in time of the server.
That way if something goes horribly wrong, you will have one or more points to fall back on.
I am getting the following error in a TFS 2010 build:
The work item '59' could not be updated: 'TF237086: The work item cannot be saved because at least one field contains a value that is not allowed.'
Work item 59 is a basic task I created to associate with my changeset on check-in. I have done no customization to the "task" work item. I get no errors when opening the task up and changing values manually. There is nothing in the build log that gives any clues as to what field is causing the problem.
How can I troubleshoot this issue?
Something I would do in this case:
Check the build service account, there's a high chance that when the work item is associated, its ChangedBy field is updated with this account and the value is not valid. Somebody in MSDN forum suggested checking the list of valid TFS users for a work item (you can open a bug and try typing the name in the AssignedTo field) and see if this account is in that list.
Try a checkin by yourself with the same associated task and see what fields are updated (you should be able to see this in the History tab), from there you can figure out the possible fields, and hopefully can guess the one that is in trouble.
If none of this works, I can get some more details and try to repro it on my machine. We'll need to improve error message to specify which fields that are invalid.
Hope this helps.
[Update]
The cause was indeed that the build service account (NT AUTHORITY\SYSTEM) did not have permissions to modify work items. All my attempts to fix this by editing group memberships failed, but I did get the build working without errors by using an unused project contributor's account as the build service account. Changing build service account may require the old build workspaces to be renamed or reassigned.
I had the same issue, after restarting VS 2015 IDE and entering credentials to my account on the TFS I was able to get rid of the errror.
After changing the build service account, I got a new error
The working folder xxxx is already in use by the workspace
1_1_SSSSSSSS;NT AUTHORITY\SYSTEM on computer SSSSSSSSS.
The solution to that issue is to use the TF utility to delete the workspace(s) associated with the SYSTEM build account. I had to copy the TF utility from my Laptop over to our server to run it.
See TFS Build Service Account change causes Build Failures - “Working Folder in use” Failures
Got the error on a long running build system where the user accounts had not changed.
found the WORKSPACE ID in the build log ran
tf.exe workspaces /owner:*
to confirm the workspace was on the build server and then ran
tf.exe workspace /delete 9_1_BUILDSERVER;OURDOMAIN\TFSBuild
to delete it, queued another build and no further problem.
If you changed process type, can throw this exception. Please correct your process type. My problem solved with the action.