some existing users cant be found in TFS2018 workitem 'assigned to' field. even they are added to team project

0
votes

My customer are using TFS2018 update2 version. and AD is used to manager TFS user. there are about 1000 users right now. and about 10 to 20 users reported that their user account can't be found in TFS workitem "Assigned to" field. so strange and confused!

1) we did check the 'AssignedTo' field of the workitem setting, is is of default setting, which allows existing user and valid users. 2) the users are even added to the team project, however, they can't be found when using search in 'assigned to 'field.

3) tried other type of workitems, any projects. same issues.

Generally speaking, such users can be added to team project successfully.and they can't be found in 'assigned to' filed of all workitems in all projects. so we doubt it is some kind of user account sync issues?

and we did do more investigation and debugging. and we found a para named operationScopes,and its value is 'ims';and if we add value 'ad' to this array. the users can be found! and we noticed the returned value bdifference between such 'bad users' and 'good users' are of the 'Local directory'and 'localId' field. the value is null here, for good user, neither local directory nor LocalID is null. hope this clue works. http://TFS2018server:8080/tfs/TFSCollection/_apis/IdentityPicker/Identities enter image description here

and add more clues, we updated the Web Services_static\tfs\Dev16.M122.5_script\TFS\debug\VSS\Identities\Picker\Services.js; by adding queryScopes.push("ims") in the OperationScope.IMS switch, then the users can be found. and I know, it is not a good way to update TFS code, it is just to do debugging. hope it is useful. update the Services.js file

2
tfsazure-devops
Seems it's a permission or identify scoping issue. Have you set any rules to restrict the user scopes? Related article: blogs.msdn.microsoft.com/devops/2016/01/13/… – Andy Li-MSFT
There is no rule to restrict the user scope in the workitem setting, it is the default value. Since it works if we changed the TFS javascript code to add 'ad' to operationScopes. I doubt it is something with the user cache? – zhuang
add more clues, we updated the Web Services_static\tfs\Dev16.M122.5_script\TFS\debug\VSS\Identities\Picker\Services.js; and add queryScopes.push("ims") in the OperationScope.IMS switch, then the users can be found. and I know, it is not a good way to update TFS code, it is just to do debugging. hope it is useful. – zhuang
I don't think it is easy to reproduce this issue. it is really rare. even on the customer environment, 20 among 3000 users reported this problem. so to make it simple, I want to check the below questions 1) with default workitem setting. when enter user name to query user, will operationScopes equals to ims? I think it should be 'ad', right? 2) check the user identity, if local id, local directory is null, is it normal? during which situation, it is null? thanks. – zhuang
Have you resolved the issue? I tried several environments but still cannot reproduce this issue. However based on the investigation, it seems a sync issue, see my answer below. – Andy Li-MSFT

2 Answers

0
votes

Based on the investigation and testing, seems it's the AD sync issue. That means the missed users may not be synced to TFS.

So when you query the missed user in AD you can find it (Add value 'ad' to operationScopes), but in TFS you can not find them.

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: How to synchronize TFS users with AD

It could be that you still do not see the user or name listed in the UI even if synchronization is working. The synchronization job does not automatically creates a user profile in the database for every user or group in the database, to avoid useless growth in big enterprises.

In such a case, the first time you use a new AD account (user or group), you must refer to it using DOMAIN\account syntax so that TFS look up in AD on the fly and insert a profile record in the database for the account.

Further Troubleshooting Mr. Hinsh has a good troubleshooting guide if you still have troubles. It's still apply to TFS 2018 Update2

0
votes

I have the same issue in Azure DevOps Server 2019 (Version Dev17.M153.3) when I tried to add a user to a security group it shows the user but it cannot retrieve the scopeName such that if there is any other user in other domains with the same username it raises the following error

Multiple identities found matching 'theusername'. Use the unique name to specify one of the following identities:

  • fullname1 (unique name: domain1\theusername)
  • fullname2 (unique name: domain2\theusername)

but the same user in other collection is working.

in C:\Program Files\Azure DevOps Server 2019\Application Tier\Web Services_static\tfs\Dev17.M153.3_scripts\TFS\debug\VSS\Identities\Picker\Services.js queryScopes.push("ims") was already there.

after some investigation i could reduce the problem to the following powershell code 

$url1 = "https://tfsserver/CB/_apis/IdentityPicker/Identities?api-version=5.1-preview.1"
$Body = '{"query":"mydomainname\\myusername","identityTypes":["user","group"],"operationScopes":["ims","ad","wmd"],"properties":["DisplayName","IsMru","ScopeName","SamAccountName","Active","SubjectDescriptor","Department","JobTitle","Mail","MailNickname","PhysicalDeliveryOfficeName","SignInAddress","Surname","Guest","TelephoneNumber","Description"],"filterByAncestorEntityIds":[],"filterByEntityIds":[],"options":{"MinResults":40,"MaxResults":40,"ExtensionId":"F12CA7AD-00EE-424F-B6D7-9123A60F424F","ProjectScopeName":"ateamprojectname","CollectionScopeName":"badcollection","Constraints":[]}}'
$x= Invoke-Webrequest $url1 -Method POST -ContentType application/json -UseDefaultCredentials -Body $Body
$y = $x.Content | ConvertFrom-Json
Write-Host "badcollection->", $y.results.identities.scopeName

$url1 = "https://tfsserver/CB_TestCollection/_apis/IdentityPicker/Identities?api-version=5.1-preview.1"
$Body = '{"query":"mydomainname\\myusername","identityTypes":["user","group"],"operationScopes":["ims","ad","wmd"],"properties":["DisplayName","IsMru","ScopeName","SamAccountName","Active","SubjectDescriptor","Department","JobTitle","Mail","MailNickname","PhysicalDeliveryOfficeName","SignInAddress","Surname","Guest","TelephoneNumber","Description"],"filterByAncestorEntityIds":[],"filterByEntityIds":[],"options":{"MinResults":40,"MaxResults":40,"ExtensionId":"F12CA7AD-00EE-424F-B6D7-9123A60F424F","ProjectScopeName":"ateamprojectname","CollectionScopeName":"goodCollection","Constraints":[]}}'
$x= Invoke-Webrequest $url1 -Method POST -ContentType application/json -UseDefaultCredentials -Body $Body
$y = $x.Content | ConvertFrom-Json
Write-Host "goodcollection->", $y.results.identities.scopeName

the output result for the first write-host is "badcollection->" but the output result for the second write-host is "goodcollection->mydomainname"

the questions are: Why does it depend on collection? How can i force tfs to sychronize that user account for the badcollection as well as the good collection.