2

I'm currently trying to migrate and upgrade a TFS2010 instance running on a server (SERVER_A) in a workgroup to TFS2013 on another server (SERVER_B) that's on a domain. Everything seems to work ok, but when I open Visual Studio and try to connect to the new TFS instance and retrieve my workspace it's not there. I've read quite a bit of documentation on "tf workspaces" and "tfsconfig identities" but I'm still pretty confused and haven't been able to work out what's going on. What I've done...

  1. Export all SQL databases and the Reporting Services encryption key from SERVER_A and restore into SERVER_B
  2. Install TFS2013 on SERVER_B, but do not do any configuration
  3. Run TfsConfig RemapDBs /DatabaseName:SERVER_B\NAMEDINSTANCE;Tfs_Configuration /SQLInstances:SERVER_B\NAMEDINSTANCE
  4. Continue TFS2013 configuration, choose the "Upgrade" option, and get through it with no errors. There is a warning about updating the url, which I do and everything looks ok.

At this point, if I call tf workspaces on SERVER_B I see all the workspaces:

\Microsoft Team Foundation Server 12.0\Tools>tf workspaces /owner:* /collection:"http://SERVER_B:8080/tfs/COLLECTIONNAME/"
Collection: http://SERVER_B:8080/tfs/SFO 
Workspace  Owner         Computer  
---------- ------------- ---------- 
...
DEV-PC1    Administrator DEV-PC1 
DEV-PC2    Administrator DEV-PC2 
JOHND123   John Doe      JOHND123 
...

If I make that same call from SERVER_A, this is what I see:

\Microsoft Team Foundation Server 2010\Tools>tf workspaces /owner:* /collection:"http://SERVER_A:8080/tfs/COLLECTIONNAME/"
Collection: http://SERVER_A:8080/tfs/COLLECTIONNAME
Workspace  Owner                  Computer  
---------- ---------------------- ----------
...
DEV-PC1    SERVER_A\Administrator DEV-PC1
DEV-PC2    SERVER_A\Administrator DEV-PC2
JOHND123   SERVER_A\John          JOHND123
...

So, SERVER_A has local users as workspace owners, and something in the migration maps those local users to some other users, what I can only assume are a domain users. In this example (which is just obfuscated from exactly what I'm seeing) the local administrator is being mapped to "Administrator". I assumed this means the domain Administrator. If I open Visual Studio on my dev machine, enter the credentials for the domain Administrator account (different password than SERVER_A\Administrator) in Team Explorer I can connect to the new TFS2013 instance. When I go to the list of workspaces though, it displays the workspace name for my computer (DEV-PC1), there are no solutions, and if I click "Manage Workspaces..." the list is empty.

It appears as though this all boils down to an issue with the account mapping, but it's not clear to me from what I've read how to handle this. If it would be useful, I can post example output from the TFSConfig identities command from both machines as well. I have a hunch that part of the problem is that the owner for most of the workspaces is Administrator (all of this was setup before I got here), and in the TFS2013 instance there are identities for domain\Administrator, SERVER_B\Administrator, and SERVER_A\Administrator. Maybe Visual Studio is confused? Or maybe TFS is confused when it does the upgrade?

Any and all help would be greatly appreciated. I hesitate to admit that I did this migration the first time successfully as a test run, figured out all the configuration for my workspace, and then uninstalled everything on SERVER_B to start over (and so I could take screenshots for documentation of the entire process). The second time I attempted it, it didn't work. I really don't think I forgot to write down any of the steps I did the first time, but it's possible I'm missing something.

Dave Novelli
  • 2,086
  • 4
  • 32
  • 42
  • 1
    What is your hangup with workspaces? Before the migration make sure everything is checked in. Then migrate. After that everyone can remap their relevant workspaces. A workspace is simply a mapping between a source structure to a physical filesystem location for a specific user - change any one of those three and the workspace becomes invalid. Invalidating current workspaces is not a big issue, maybe just a small inconvenience. Any build scripts that use workspaces should be creating temporary ones dynamically. – slugster Mar 07 '15 at 00:25
  • I guess my "hangup" is that I'm new to TFS and don't want to screw anything up in the migration. It seems as though the workspaces *should* be able to be migrated, or at least *should* be able to be manually re-mapped to new users. If they're totally disposable that's great, but from what I understood shelvesets are stored in workspaces - is that correct?. I know the developers have shelvesets, and I'd prefer to not ask them to just commit or toss them. – Dave Novelli Mar 07 '15 at 01:01
  • Shelvesets are not stored in workspaces. Shelvesets are stored on the TFS server. – Daniel Mann Mar 07 '15 at 01:01
  • I just did a little research and found out that shelvesets are stored in the database as a workspace with type=1. That doesn't make it clear though that I can ever recover that shelveset if I have to throw away the shelveset. Also - if the shelveset is stored as a workspace with the same owner as the workspace from which it was created, then I'll still have the same issue - I need to figure out how to associate the original workgroup-based user with the new domain-based user. – Dave Novelli Mar 07 '15 at 02:30

1 Answers1

2

You'll want to follow the instructions in Move Team Foundation Server from one environment to another to do the move. The identities in the domain are different than the identities in the workgroup (the underlying unique identifiers are different). All of the workspaces, shelvesets, etc. are there but associated with identities that need to be updated.

Buck Hodges
  • 3,342
  • 1
  • 19
  • 20