Blog Stats
  • Posts - 63
  • Articles - 0
  • Comments - 6
  • Trackbacks - 0

 

Monday, January 23, 2012

Copy a Team Foundation Server 2010 Collection to a Different Network/Domain


The Objective

Three of the 6 development teams using TFS are moving to a different network and domain. There is no on-line connection between the old (source) and new (target) networks.

The objective was for the teams to come in Monday morning, bring up their development machine on the new network and have everything as it had been on the old network.

Failed Approaches

  1. Clone the data tier and move the data tier to the new network. This failed because the procedures for moving the hardware to a new environment did not work.
  2. Use the TFS Integration Tools. We had experience with the tools, and after a couple of tries with the 1st approach we decided we wanted a totally new and clean installation of TFS on the new network. However, I found that the tools do not support the migration of test cases and labels.  This was unacceptable unless there was no other possible way to do the move.

Successful Approach

I looked into doing a collection move and my initial tests were successful.  This approach:

  • Allows you to setup a totally new and clean TFS target instance
  • Brings much more over than the Integration Tools

Procedure

Don’t attempt this unless you know what you’re doing and have experience with SQL Server and administering all the components of TFS (i.e. SharePoint integration, reporting services, analysis cub processing, source control, work items, etc.…)

The first thing you need to do is install and configure TFS in the new environment. I also suggest moving a small “test” collection first before moving the production collection.

NOTE: My machine names in the source and target environment were identical. This may have helped in some cases simplify the updates to the TFS console in the target environment after attaching the cloned collection.

Be sure to reference the Microsoft procedure as well as the following steps:

  1. Note down all the team project team members and which security group they belong to
  2. Apply the latest SPs and updates to all the machines in both networks. Make sure SQL Server is the same version and TFS is the same version in both environments (see TFS console and SQL Server Management Studio)
  3. Export all your SSRS report definitions (RDL) files. Since we had only 3 team projects to move that used SSRS reporting, I used a PowerShell Script to export the RDL files and then manually uploaded and configured them on the target environment. There is a tool that might be able to automate this, but I was not familiar with it and initial automation attempts were not successful.
  4. On the source environment:
    1. Do a full TFS backup
    2. Stop the warehouse jobs
    3. Stop the transaction backup job (mine runs every 15 minutes)
    4. Remove all team project team members from all team project security groups.  I’m not sure if this is needed, but I wanted to keep as much data as possible out of the collection that would be invalid in the target environment.
    5. Detach the collection using the TFS console
    6. Clone the collection database
      1. Stop all SQL Server services except the data engine
      2. Take the collection database offline
      3. Copy the .MDF and the .LDF files of the collection database
      4. Bring the collection database back online
      5. Start all the SQL Server services you stopped
    7. Attach back the collection (using the TFS console)
    8. Add back all team project team members to the correct group (using the TFS Power Tools Team Members feature in the Team Explorer makes this really easy)
    9. Start the warehouse jobs
    10. Start the transaction backup job
    11. Verify TFS operations using the TFS Best Practices Analyzer. I also used Grant Holliday’s TFS Administrative Reports Pack to help ensure that cube processing was working correctly.
  5. On the target environment:
    1. Copy the database .MDF and .LDF files to the appropriate folders on the database machine
    2. Attach them to SQL Server to bring the collection database online
    3. Attach the collection using the TFS console (* see problem below)
    4. Set the web application on the TFS console SharePoint view to the correct one for the new environment. This will automatically create the collection site for the TFS collection you attached
    5. Manually create the SharePoint site for each team project in the collection (for team projects that use SharePoint). Create these under the collection site that was created in the prior step.
    6. Run IISRESET /NOFORCE on the SharePoint machine
    7. Update the Team Portal settings for each team project from Team Explorer, Team Project Settings
    8. Make sure all the team project and collection parameters on the TFS console are correct for the new environment
    9. Update all collection level security groups to ensure members is correct
    10. All all team members to the team projects security groups
    11. Rebuild the warehouse from the TFS console
    12. Import, configure and verify the SSRS reports. Note: I had to configure the data sources for each report even thought the data source name had not changed.
    13. Process the analysis cube manually
    14. Setup your backups
    15. Verify TFS operations using the TFS Best Practices Analyzer and the TFS Administrative Reports Pack reports

Other things I had to do in my specific situation

  1. Deleted all the build workspaces. This was required to avoid TFS from thinking there was a workspace mapping conflict since the build machines names were the same on the source and target environments
  2. I remapped the user workspaces to the new owner, changed the computer name portion of the workspace name to match the new name of the users computers (their computer names did change) and provided scripts for them to change the computer name for their workspace.
  3. I provided scripts for them to replace their shelve-sets to have the correct owner name
  4. I swapped out the display name in the assigned-to field for all work items with the correct display name (the account IDs were the same in both environments but the display name was not: first last vs. last, first)
  5. Dropped in a custom assembly we use for setting builds to never be deleted based on build quality

That’s it Smile

Problems

The only glitch I had was that the collection failed to attach. the error message:

“TF246091: The team project collection cannot be attached because its version ID is higher than the ID for the configuration database. The collection has the following version: Tfs2010.SP1.KB2564498.P#5. The Team Foundation Server is at the following version: TFS2010.SP1.KB2580221.P#4.”

This baffled me at first because from the TFS console and from SQL Server Management studio, the versions of TFS were shown to be the same and the version of SQL Server were shown to be the same. 

However, after some digging I found a blog post saying how the TFS version could be inconsistent between the application and the database machine. The resolution was to run:

TFSConfig Updates /Reapply on the application machine.

After doing this, the attach worked fine.

 

 

Copyright © Bob Hardister