Computers, Programming, Technology, Music, Literature

Restoring TFS services after host name and domain binding changes

leave a comment »


This article was originally published for and could be located at


I have a local TFS server set up for testing CI integration of certain tools. The database storage (sql server 2012 express), the application tier, the build agent, the controller everything set up in localhost. I am working with TFS 2012, which TFS services running under <<computername>>\TfsUser.


The computer was recently migrated to another domain, which involved the computer name change, and obviously the domain name change itself. That’s it. TFS services started with 503 Service unavailable. The TFS application pool was stopped, and never started again. The TFS Administrator Console was always throwing all sorts of error messages. I was not prepared for any of these changes, it took me some time to fix all of them and get the CI functionality working flawlessly again. Ironically, all these happened after I happily blogged about Migrate user profiles to new domain account in a jiffy with Profwiz. But, here I am documenting my steps one by one. If your (local) TFS server installation has incurred a domain change, you may find these steps helpful. You may be at best when you follow the steps sequentially. All the steps involve changing the old machine name to the new machine name and fixing the Windows identities.


1. Verify/Update the Application Tier web.config

Navigate to the TFS Application Tier Web Services folder, and edit the applicationDatabase appSettings value. The Data Source should be be <<newcomputername>>\databaseServer.

C:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\web.config



2. Verify/Update the TFS sql server database Logins

I use <<machinename>>\TfsUser as an admin console user. Connect to the sql server where Tfs configurations are saved, Remove the logins with the old machine names. (If the old machine name’s Login exists, then it will result in a SID conflict later during other stages). Add new logins with the new <<machinename>>. Let them have sysadmin permissions.

“TF255507: The security identifier (SID) for the following SQL Server login conflicts with a specified domain or workgroup account: <<oldcomputername>>\user. The domain or workgroup account is: <<newcomputername>>\user.  The server selected to host the databases for Team Foundation Server is: <<newcomputername>>\sql2012express.
You can resolve this issue by renaming the conflicting login.”



3. Verify/Update the Tfs Application Pool identities

Make sure the Tfs Application Pools Microsoft Team Foundation Server Application Pool, and Microsoft Team Foundation Server Message Queue Application Pool in IIS runs under the <<newcomputername>>\<<yourIdentify>>. In my case it is TfsUser.



4. iisreset at will. Couple of time during the entire troubleshooting process.


Try browsing to http://localhost:9000/tfs (or wherever your http://hostname:portnumber/tfs is),  you should be done here if you get the tfs Getting Started screen.

5. Dealing with Sync error for identity

However, If you encounter ‘The trust relationship between this workstation and the primary domain failed’, or the below errors, proceed.

TF53010: The following error has occurred in a Team Foundation component or extension:
Date (UTC): 15-05-2014 18:01:13
Machine: <<machinename>>
Application Domain: TfsJobAgent.exe
Assembly: Microsoft.TeamFoundation.Framework.Server, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; v4.0.30319
Service Host: 
Process Details:
  Process Name: TFSJobAgent
  Process Id: 3020
  Thread Id: 4640
  Account name: <<machinename>>\TfsUser

Detailed Message: TF200035: One or more errors occurred when Team Foundation Server attempted to synchronize the following identity: Administrators. Number of errors that occurred: 1.
Sync error for identity: Administrators
The trust relationship between this workstation and the primary domain failed
   at Microsoft.TeamFoundation.Framework.Common.SidIdentityHelper.ResolveSid(SecurityIdentifierInfo securityIdInfo, String& domain, String& userName, AccountType& type, Boolean& isDeleted, Boolean& migrated)
   at Microsoft.VisualStudio.Services.Identity.WindowsProvider.ResolveIdentity(IdentityDescriptor descriptor, String providerInfo, AccountSubType& subType, Boolean& migrated)
   at Microsoft.VisualStudio.Services.Identity.WindowsProvider.TrySyncIdentity(IdentityDescriptor descriptor, Boolean includeMembership, String providerInfo, TeamFoundationRequestContext requestContext, SyncErrors syncErrors, Identity& identity)
   at Microsoft.VisualStudio.Services.Identity.IdentitySynchronizer.SyncOneGroupMembership(TeamFoundationRequestContext requestContext, Identity groupToSync)





Ask your System administrator to Reset the computer account in AD. That is right click on the computer and do Reset Account.


img src –


Then, Start –> Run –> sysdm.cpl , Hit the Network ID… button. Follow the steps to join the computer to a domain. This step would require a Domain Admins account, use your System Administrator’s or AD Administrator’s help, and complete the Join a Domain or Workgroup wizard.


Doing a Reset Account on AD computer account, and Joining it again to the domain via Network ID… made my ‘The trust relationship between this workstation and the primary domain failed’ error disappear.

6. Verify/Update Application Tier’s Notification URL, Server URL, Web Access URL


In Team Foundation Server Administration Console, Click Change URLs in Application Tier Summary, and update the Notification URL, Server URL to the <<newmachinename>>.



7. Unregister/Register the Build service with new machine name

Unregister the build service that uses the <<oldcomputername>>. Register a build service with the <<newcomputername>>. And do the same for the agent and the controller.




That’s should be it. At least the steps that I did to got my TFS installation working again. If you want to check the Check in, and build service, then follow the steps below.

8. Fixing the workspace conflict in Visual Studio TFS Client

Simple solution by Anand is to remove the current workspace the solution was bound to, so the VS TFS Client would automatically create one. I did not have any pending changes.

Open Developer Command Prompt for VS2012, run

C:\Program Files (x86)\Microsoft Visual Studio 11.0>tf workspaces


to see existing workspaces, and remove the workspaces bound to the <<oldcomputername>> with

C:\Program Files (x86)\Microsoft Visual Studio 11.0>tf workspaces /remove:<<oldcomputername>>


TFS client should connect fine now, and should have created a new workspace for you. Map the source control to the local directory.


Edit your build definition to update the Build Controller: to the newly created build controller.



Check in, and see your CI working again with all tests and other configured tools.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: