1

We have (evolved historically) about 50 "local" user accounts on the old server for external users.
These users add Backlog Items and see work progress on subordinate elements (like tasks).

Old Windows Server 2008 R2 with SQL 2014 and TFS 2017.
New Windows Server 2016 with SQL 2017 and TFS 2018.
Both servers are joined to the same domain.

I plan to migrate these user accounts to our Active Directory and map these AD users to the new TFS 2018 server.

Is there a way to map the new AD users on the new server, so the new users see their appropriate backlog items / tasks etc.?

In the migration phase we would like to test this. So both systems (old with local users, and new with AD users) should work parallel.

StefanK
  • 125
  • 1
  • 2
  • 8

1 Answers1

1

The scenario you'd like to do is not possible. You can only map users from one domain or workgroup to another as long as the target user isn't known in TFS. So your desire, to be able to run new users and old users side-by-side, is technically not possible.

It is not possible to merge two existing users that are known by TFS.

Your only option is to do this as part of the migration/upgrade procedure and is only possible as long as the new identities are not known by TFS in your case that means that the target users cannot be part of Active directory before the migration and must be part of active directory after the migration of TFS.

After you've completely shut down TFS (usually after uninstalling the Application Tier for the older version), you can use the following command to map an existing identity to a new and to the server unknown identity that should exist after migration:

TfsConfig identities /change /fromdomain:<D1> /todomain:<D2>
                           [/account:<N1> [/toaccount:<N2>]]
                           [/sqlInstance:<sqlInstance>
                            /databaseName:<databaseName>]

You may need to run this command for each individual account. The fromdomain can be name of the server that is hosting the current local users.

Once all the mapping is done, create the exact same users in active directory and restart/install+start the (new) Application Tier. During the servicing steps these users should now be synced to Active directory and all of their "possessions" in TFS should be migrated over to the new user.

Note: Make sure you have a backup database available that doesn't yet know the target users so you can perform this step a couple of times, should you not succeed the first time.

Note: this procedure will likely cause some downtime during the upgrade and requires synchronized activities between the TFS admin and the domain folks. Unfortunately, that's the way it is.

jessehouwing
  • 289
  • 1
  • 12
  • I think my posting could be misunderstood. I want to leave the old server with the old local users. And for "initial testing" of the workflow I want to install a new server where the new domain users are mapped. If everything works as expected the old server with the local users will be shutdown after a live migration to a "second new server". Since the domain users aren't known on the new TFS servers, this should be possible? – StefanK Mar 18 '18 at 12:03
  • If they've never been synced to the old and never to the new, then the tfsconfig command should work. – jessehouwing Mar 18 '18 at 15:17
  • What exactly do you mean with "synced"? I plan to migrate the databases of old TFS server on the new TFS server. Then use the tfsconfig on the new server to map the domain users on new server. And leave the old server online in production (with the old local users) until our tests with the new server are complete. Will that work? – StefanK Mar 18 '18 at 19:31
  • Do the target users already exist in Active Directory at the moment? If that's the case, then the target users will already exist in the old server. The issue isn't on which server you perform this user change. The issue is whether the users are already created in the tfs_configuration database by the active directory sync job that runs hourly in tfs. – jessehouwing Mar 18 '18 at 19:53