Freigeben über

TFS Integration Tools – Where does one start? … part 2 (try a simple migration)

  • Artikel

We continue from TFS Integration Tools – Where does one start? … part 1 (documentation) and in this post go through the steps of finding, installing and “trying” a migration.

“Find” the TFS Integration Tools

To find the TFS Integration Tools we need to decide whether we want the latest supported tools, the latest available tools or special builds for the tools.

  • For the supported tools go to the Visual Studio Gallery and search for “TFS Integration Tools”, which brings us here:
  • For the latest or a special build of the tools go to Codeplex and search for “TFS Integration Tools”, which brings us here:
  • Under downloads you will then find either the standard download bits (1) or the special builds (2), which should only be used when requested by the product team:

NOTE: We use the “search” mechanism, instead of sharing URLs, as these may change from release to release.

“Install” the TFS Integration Tools

  1. Download the relevant version, in this case version 2.1 from the Visual Studio Gallery.
  2. Run the TFSIntegrationTools.msi installation, whereby you will need admin rights.
  3. Step through the wizard, accepting all the recommended defaults … we are trying to simulate the most likely install pattern, although we recommend that you plan the installation parameters, for example whether to use SQL Server Express or a beefier instance, before you repeat this exercise.
  4. In this case I opted for the following:
    • Use SQL Server Express
    • Not to install the service or Rational adapters
  5. What we will find is a new Program Files node “Microsoft Team Foundation Server Integration Tools” and two shortcuts:

Question: “Which credentials are used to perform the migration”? Answer … in our case we will use the credentials of the currently logged in user. Had we installed he service, we could set the service credentials and we could use one of Grant’s nuggets to set the credentials when targeting remote servers: TFS Integration Platform – Cross Domain Migration … now what? Question & Answer 11

Question: “What permissions are needed for the one-way migration we are planning?” On the source you need enough rights to read the data, on the machine on which you are running the TFS Integration Tools you need admin rights and on the target you need to be a member of the Project Collection Service Accounts group and have write access to the target team project.

Now that everything seems installed, we can start the countdown and get ready to hit the migration button … can we really?

“Try” a migration

Our environment is simple … we have a team project, based on the Scrum process template, running on a Team Foundation Server 2010 (source) and a team project, based on the Scrum process template, running on a Team Foundation Server 2010 (target).

The servers are both living on the Extranet, which is irrelevant in this case, both are based on the same version of TFS and both are the hosts for team projects using the same process template. With this in mind, we decide that we can simply do a migration, without any field or value mapping and using the adapters out-of-the-box.

  1. Start the TFS Integration User Interface, mentioned above, running it with administrative rights.
  2. Accept (yes) the suggestion to add the credentials of the current user to the TFSIP Worker Process Group.

    Input from Bill Barnett: A user of TfsMigrationShell needs to be in this group in order to run a migration. This dialog comes up when you are not a member of the group and allows you to join the group, if you can, without having to take the normal steps to manually add yourself to the group.
  3. Select Create New” configuration and select the VersionControlAndWorkItemTracking.xml configuration template.
  4. Configure the source and the target version control and work item tracking sessions.
  5. Save the configuration to the database.
  6. What the heck … click START!

… in the next blog post we will review the hiccups, the exceptions and do a quick validation if target == source. See you in validation/troubleshooting/peruse-log-file world … which, by the way, will not be a walk in the park :|

Comments

  • Anonymous
    August 17, 2011
    Great post. I fall at an early hurdle. If, like you, I choose localhostSQLEXPRESS for the serverinstance setting it's fine. But if I use localhostMSSQLSERVER it throws an error: Error connecting to database localhostMSSQLSERVER. A network-related or instance-specific error occured while establishing a connection to SQL Server. The server was not found or is not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 25 - Connection string is not valid)

  • Anonymous
    August 18, 2011
    I have just created a test VM with SQL Express and SQL Server installed locally. I can install the TFS Integration Tools using the following: Install against SQL Express

localhostSQLExpress Install against SQL Server Default Instance (MSSQLServer)

localhost . Install against SQL Server Instance TestInstance

localhostTestInstance MSSQLSERVER is the typically the default instance which is not specified by name when connecting to the SQL Server.

  • Anonymous
    February 05, 2013
    I have tried all these steps. I want to ensure I migrate only limited data from source to destination. If I choose right query from source (which results only 10 records for eg) then I expect 10 results should be migrate. Moreover there I have two columns in source which are different in destination (name and value), can I assume empty data will be moved if I initiate migration. please confirm.

  • Anonymous
    June 25, 2014
    Super Thanks