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
- Download the relevant version, in this case version 2.1 from the Visual Studio Gallery.
- Run the TFSIntegrationTools.msi installation, whereby you will need admin rights.
- 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.
- In this case I opted for the following:
- Use SQL Server Express
- Not to install the service or Rational adapters
- What we will find is a new Program Files node “Microsoft Team Foundation Server Integration Tools” and two shortcuts:
- Documentation … the infamous index we mentioned in TFS Integration Tools – Where does one start? … part 1 (documentation).
- UFS Integration User Interface, which we will run shortly.
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.
- Start the TFS Integration User Interface, mentioned above, running it with administrative rights.
- 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.
- Select Create New” configuration and select the VersionControlAndWorkItemTracking.xml configuration template.
- Configure the source and the target version control and work item tracking sessions.
- Save the configuration to the database.
- 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 😐