index > Team Foundation Server - Administration > TF53010 / TF14055 error

TF53010 / TF14055 error

I upgraded our TFS environment from RC1 to RTM last week and have to say that it went extremely smoothly. The entire upgrade (Dual Tier environment) took around 1.5 hours. Much nicer than my B3R to RC1 experience :)

I did run into a few "glitches" that I've been working through. Two seem to have been preexisting issues, another was apparently a change in a developer's directory structure that I had to "help" troubleshoot.

The final hurdle I'm trying to overcome appears to be some kind of authentication issue. Here's a sample of what I'm seeing in the event log on the AT machine (names changed to protect the innocent )

Event Type: Warning
Event Source: TFS Version Control
Event Category: None
Event ID: 6008
Date: 5/17/2006
Time: 11:08:18 AM
User: N/A
Computer: <ugly server name>
Description:
TF53010: An unexpected condition has occurred in a Team Foundation component. The information contained here should be made available to your site administrative staff.
Technical Information (for the administrative staff):
Date (UTC): 5/17/2006 6:08:18 PM
Machine: <ugly server name>
Application Domain: /LM/W3SVC/3/Root/VersionControl-1-127923603863294614
Assembly: Microsoft.TeamFoundation.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; v2.0.50727
Process Details:
Process Name: w3wp
Process Id: 10720
Thread Id: 10612
Account name: <AD\tfsservice>

Detailed Message: TF14055: The identity <AD\developer> is not a recognized domain identity.
Web Request Details
Url: http://<ugly server name>:8080/VersionControl/v1.0/integration.asmx [method: POST]
User Agent: Team Foundation Version Control Alert Security Filter 1.0
Headers: Content-Length=540&Content-Type=application%2fsoap%2bxml%3b+charset%3dutf-8%3b+action%3d%22http%3a%2f%2fschemas.microsoft.com%2fTeamFoundation%2f2005%2f06%2fServices%2fLinking%2f03%2fFilterPaths%22&Accept-Encoding=gzip&Accept-Language=en-US&Expect=100-continue&Host=vsts-poc1-vs2k3%3a8080&User-Agent=Team+Foundation+Version+Control+Alert+Security+Filter+1.0&X-TFS-Version=1.0.0.0
Path: /VersionControl/v1.0/integration.asmx
Local Request: True
Host Address: 10.9.176.174
User: <AD\tfsservice> [authentication type: NTLM]

Exception Message: No mapping between account names and security IDs was done (type Win32Exception)

Exception Stack Trace: at Microsoft.TeamFoundation.NativeMethods.SidToName(IntPtr sid, String& domainName, AccountType& accountType)
at Microsoft.TeamFoundation.NativeMethods.UserSidToGroups(Byte[] sid)
at Microsoft.TeamFoundation.NativeMethods.QueryGroupMembership(String userName)
at Microsoft.TeamFoundation.VersionControl.Server.IntegrationInterface.BulkFilter(IPrincipal userPrincipal, String[] users, String[] versionControlUriList, Int32 alertChangeLimit, ArrayList& restrictions)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Has anyone else seen anything similar? I'm not even sure exactly what it is breaking. One of the developers mentioned that their triggered build process is not functioning so it may have something to do with notification.

Suggestions?

tomf

fieldhouse

Are you still seeing this event in the log? I wouldn't be too surprised if it cleared itself when the TFS Group Security Service next synchronized with AD.

This looks like a user SID that had a subscription associated with it was known to the TFS Group Security Service when the event was fired, but that the UPN for that user could not be resolved to a SID by the Version Control notification filter.

Bill Essary MSFT

It isn't fixed but I found a workaround after opening a case with PSS.

The issue seems to be related to the TFS server sitting in an AD which has a one way trust with the AD that the user accounts are stored in. The error is caused by a SOAP subscription to notifications of build check ins. Any time a build is checked in a SOAP notification is supposed to be sent to a web service to kick off a build for Continuous Integration (using the sample code off MSDN).

As long as an AD account out of the user AD is used, the notification fails. If the subscription is created using a local machine account on the TFS app tier server the error goes away.

tomf

fieldhouse

Thank you for following up with the details.

Was it the case than any AD account out of the user domain caused the problem? It seems to me that this should work as long as the AD user has basic read permissions within TFS.

Bill Essary MSFT

The same behavior happened with different user accounts from the user AD. You can check out the case if you're interested: SRZ060531002128

tomf

fieldhouse

The Version Control notification filter is responsible for the failing call to SidToName in the callstack you provided. While the SidToName call works in many cases, we have had reports from a few other users that make it clear that it does not work in all. The filter should be looking to the TFS Group Security Service for this conversion instead of going directly to AD. We will make that change for an upcoming release. In the meantime, please continue to use the local machine account for the subscription to work around the issue.

Bill Essary MSFT

I'm having the same problems as described.

Could you please provide detailed information on how to solve the problem?

I've tried to subscribe as a local user (tfsservice on local machine) but I still get the error.

We have all TFS services and app pools setup as a domain user. What do I need to change and what needs to be restarted to solve the problem?

Thank you.

/Oyvind

OyvindA

I didnt' have to restart anything.

I unsubscribed from the existing subscriptions (there were two to two different web services) and resubscribed logged into the console of the App server as a local machine account. If you're seeing errors after this process I'd guess there's something else wrong.

tomf

fieldhouse

Thx for the reply.

Yes. After resubscribing I got rid of the warning, so that is ok now