Restoring TFS services after host name and domain binding changes
This article was originally published for www.prowareness.com and could be located at http://www.prowareness.com/blog/restoring-tfs-services-after-host-name-and-domain-binding-changes/
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.
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.
Ask your System administrator to Reset the computer account in AD. That is right click on the computer and do Reset Account.
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
to see existing workspaces, and remove the workspaces bound to the <<oldcomputername>> with
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.