Installing a TFS 2013 build agent on another machine in a seperate domain

Question

We have two Windows domains that do not have trust in between. On the main domain, we have a simple TFS server 2013 setup and in the development domain, we'd like to set up an additional build agent. This build agent will be added to the existing build controller on the TFS machine (the TFS machine already contains a single build controller and agent).

So far I've added the same local user account to both the TFS and development machine. In other words, there is a shadow account with the same name and password on both VM's. I'm running the TFS build service installer under that user and all goes well until it gets to the Configuration step.

This step fails with a "TF400106: Failed to register the build service" and the following stacktrace in the log:

Exception Message: User account DEV\machinename$ not found (type Exception)
Exception Stack Trace:    at Microsoft.TeamFoundation.Build.Config.BuildServiceHostUtilities.CheckServiceAccountMembership(TfsTeamProjectCollection tfsCollection, String serviceAccount)
   at Microsoft.TeamFoundation.Build.Config.BuildServiceHostUtilities.UpdateCollectionPermissions(TfsTeamProjectCollection tfs, String userName)
   at Microsoft.TeamFoundation.Build.Config.BuildServiceHostUtilities.UpdateAuthenticatingAccount(TfsTeamProjectCollection tfsCollection, String fromUser, Boolean canTranslateFromUser, String toUser, Boolean canTranslateToUser)
   at Microsoft.TeamFoundation.Build.Config.BuildServiceHostUtilities.Register(IBuildServiceHost serviceHost, String serviceAccount, String serviceAccountPassword, X509Certificate2 serverCertificate, String authenticatingUserName, Boolean canTranslateAuthenticatingUserName)
   at Microsoft.TeamFoundation.Admin.TeamBuildInstaller.RegisterWithApplicationServer(IAuthenticatedCollectionProvider authenticatedConnectionProvider, IBuildServiceHost host, String collectionUri, Int32 port, AccountInfo serviceAccount, AccountInfo authenticatingAccount, Boolean useHttps, BuildControllerOptions controllerOptions, List`1 agentListOptions, Boolean cleanOldResources, String certificateThumbprint, Boolean requireClientCertificates, ITFLogger logger)
   at Microsoft.TeamFoundation.Admin.ConfigureRegisterBuild.Run(ActivityContext context)

What does that stack trace mean? And is there any chance of this setup working? I did read around the web that it's not well supported but there are also a couple of success stories.

Yes, the "Dev" domain is our development domain. The stacktrace comes from a machine within the "Dev" domain. — Vincent
and exists this useraccount? You can specify the useraccount in the configuration wizard or later in the BuildConfiguration in the Team Foundation Server Administration Console — Oswald
Specifying the shadow user account in the configuration wizard does not change the outcome. And I'm running the TFS Administration Console as the shadow user. — Vincent

Vincent Vincent · Accepted Answer · 2014-01-16T08:15:04

It turns out the above is indeed possible but only with a few hacks. First you need to run through the install by entering a domain account at the point where it asks for "an account to run the service under". The wizard will be happy with a domain account from the DEV domain and complete. The domain account is one from the Dev domain and there is no equivalent in the main domain.

At this point you are left with an error in the eventlog stating "You are not authorized to access ...". Now the hacking begins. You have to go to the services console (start->run->services.msc) and manually change the "Log On As" account for the "Visual Studio TFS Build Service Host 2013" service to your shadow account (i.e. the local account that exists on both the build server and the TFS server with the same name and password). You will need to restart the service for it to take effect. This should stop the error from showing up in the eventlog.

Lastly, you can go to the TFS Administration Console and add an agent. And now you should be able to send builds it's way.

The reason you can not configure the account through TFS Administation Console is because it does not allow a local account to be specified at "Connect to TFS as". This of course makes sense since normally a local account is not recognized outside of the box. The checkbox of "Use the same identity as Windows Service" is checked by default so it will use whatever account was specified as the "log on as service" account.

I hope this saves someone out there some serious head scratching.

Installing a TFS 2013 build agent on another machine in a seperate domain

1 Answers