Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Understanding upgrade types

· Differences between in-place and hardware migration–based upgrades

· Upgrading software prerequisites

· Using the upgrade wizard

· Upgrading legacy team projects

· Enabling Team Foundation Server 2013 features in legacy team projects

Instead of installing a brand-new Team Foundation Server 2013 instance, you may have an earlier version of Team Foundation Server internally and want to upgrade to Team Foundation Server 2013. Thankfully, Microsoft has provided the means to upgrade an existing server to the latest version. However, as a Team Foundation Server administrator, you will actually have several additional tasks to complete to ensure that end users are able to leverage the new features.

The upgrade wizard in Team Foundation Server 2013 allows a full-fidelity data upgrade from the following legacy versions:

· Team Foundation Server 2010

· Team Foundation Server 2010 with Service Pack 1

· Team Foundation Server 2012 Beta or Release Candidate

· Team Foundation Server 2012

· Team Foundation Server 2012 with Updates 1, 2, or 3

· Team Foundation Server 2013 Preview or Release Candidate

You may notice that Team Foundation Server 2005 and 2008 are not listed. If you still have a Team Foundation Server 2005 instance, then you will want to upgrade first to Team Foundation Server 2010 with Service Pack 1, and then you can perform the upgrade to Team Foundation Server 2013. If you still have a Team Foundation Server 2008 instance, you will want to upgrade first to Team Foundation Server 2012, and then upgrade to Team Foundation Server 2013.

In this chapter, you learn about the different approaches to take for upgrading from an earlier version of Team Foundation Server, as well as what is involved with performing an upgrade for each part.

Overview

Upgrading the software and database schema from earlier versions to Team Foundation Server 2013 could not be easier. However, you will discover that the upgraded Team Foundation Server 2013 environment containing legacy team projects will essentially work as though it were a Team Foundation Server 2010 or 2012 instance running in Team Foundation Server 2013. This is so that the upgrade itself will limit the impact on how teams have been working to continue to be productive immediately after the upgrade. It will be your job to enable, at a schedule convenient for the teams in your organization, any new features that you desire for the legacy team projects that exist before upgrade.

There are several aspects of an upgrade to take into consideration. In this section, you learn about some of those aspects to ensure that your team can go through a smooth upgrade experience.

In-Place Upgrades versus Migrating to New Hardware

The first major decision is whether you want to perform an in-place upgrade on the current hardware where Team Foundation Server is installed or move to new hardware (including any environment topology changes, such as splitting to a dual-tier configuration).

The upgrade wizard in the configuration utility enables you to connect to a set of Team Foundation Server 2010 or 2012 databases and upgrade the schema and data appropriately.

During an in-place upgrade, the former versions of the software are uninstalled, and then Team Foundation Server 2013 is installed in addition to the latest updates. You will be able to then use the upgrade wizard and input the connection information for the existing database server, and the database schema is upgraded in place.

For a hardware migration-based upgrade, the legacy databases are fully backed up and then restored to the new hardware environment. The upgrade wizard is then pointed to the new database server instance with a copy of the latest database backups restored. It will discover the legacy version of those databases and appropriately upgrade the database schema to Team Foundation Server 2013.

Difference Between Migrations and Upgrades

Moving to new hardware is considered a hardware migration-based upgrade, which should not be confused with another option that some may describe as “migrating to Team Foundation Server 2013.” Note that despite having a similar name, a migration-based upgrade is not a migration.

The approach that others have described (not recommended) would involve setting up a brand-new Team Foundation Server 2013 environment with new databases, creating new team projects, and then migrating the source code and work items using a tool such as the Team Foundation Server Integration platform.

That approach will lead to many side effects. It is considered a low-fidelity data transfer because the data has changed (such as changeset, dates, and work item ID numbers), and because this approach doesn't move over other data, such as reporting, security privileges, and build information. By taking the actual upgrade route (described in this chapter), the configuration wizard will upgrade the database schema and keep all of the data as it existed from the earlier Team Foundation Server environment. For that reason, this is considered a high-fidelity upgrade.

For more about these differences, you can read Matt Mitrik's articles about this topic at the following sites:

· http://aka.ms/TFSMigrationDefinition

· http://aka.ms/TFSUpgradeDefinition

There are several advantages and disadvantages to both an in-place upgrade and a hardware migration-based upgrade. The main disadvantage to performing a hardware migration is that you will need to acquire new hardware (whether physical or virtual machines). The nice thing, though, is that, after the upgrade is completed and verified, you will be able to retire the legacy hardware and repurpose it for some other use or completely discard any virtual machines previously used. After personally being involved with a very large number of upgrades over several years, we would overwhelmingly recommend the hardware migration-based upgrade.

Following are the advantages of performing a hardware migration-based upgrade:

· Testing the upgrade—Having a separate Team Foundation Server environment allows you to perform the upgrade steps while the production environment is still running. This allows you to perform the upgrade to test it before going through with the final upgrade run.

· Having a rollback plan—One of the main advantages of performing a hardware migration-based upgrade is that you have a rollback plan already in place in case the upgrade is not successful, or in case it cannot be verified. By keeping up the legacy hardware environment, you can have users continue to connect to the old environment (if needed) while researching any upgrade issues in the new hardware environment.

· Taking advantage of new operating system versions—If the legacy environment is using Windows Server 2008 R2 with SP1, you can take advantage of newer operating system versions (such as Windows Server 2012) by ensuring that the new hardware has the latest versions installed. Otherwise, the final upgrade plan would require you to upgrade the operating system as well, which can affect your rollback plan.

· Taking advantage of a 64-bit application tier—Earlier versions of the Team Foundation Server application tier software supported installation only on 32-bit operating systems. If you are planning to use a Windows Server operating system, then Team Foundation Server 2013 supports only 64-bit versions.

· Installing new copies of prerequisite software—As discussed later in this chapter, you will end up needing to ensure that SQL Server and SharePoint are upgraded to newer versions for Team Foundation Server 2013. Acquiring new hardware allows you to install each prerequisite software fresh, instead of worrying about having to upgrade the software during the final upgrade.

· New built-in backup and restore functionality—You do not even have to worry about performing the database backup and restoration in a separate tool. To make the process easier for moving to new hardware during the upgrade, Team Foundation Server 2013 introduces two new utilities to help ease with the process: TFSBackup.exe and TFSRestore.exe.

Planning Upgrades

There are additional considerations to account for with the upgrade process that are different from a fresh Team Foundation Server 2013 installation. Let's take a look at a few of those.

Connection URL

Let's hope that the person setting up the earlier version of Team Foundation Server used fully qualified, friendly DNS names for each of the subsystems of Team Foundation Server, as described in Chapter 2. After the upgrade is complete, you should ensure that the friendly DNS entries are changed to point to the new hardware environment. When users start connecting to the Team Foundation Server environment using the friendly DNS entries, they will automatically be pointing to the new environment fully upgraded without having to make any additional changes. The Visual Studio and other clients will continue to work without any additional changes.

If friendly DNS names were not used in the previous setup, then we recommend that you use the concepts described in Chapter 2 to allow for smoother upgrades in the future. Future Team Foundation Server administrators and your team members will thank you for it. A blog post about using friendly DNS names in a Team Foundation Server environment is available at http://aka.ms/FriendlyDNSTFS.

Also, remember that some legacy versions of Visual Studio clients and other tools that connect to Team Foundation Server 2013 may need to include the Project Collection name and the virtual directory in the connection URL. Chapters 4 and 21 provide more information about these changes.

Other Servers in the Team Foundation Server Environment

Remember that there might be other servers that should be upgraded before they can be fully used. For example, all of the build servers will need to be upgraded to the latest version, as well as proxy servers, test controllers, and test agents.

Update 2 of Team Foundation Server 2012 added support for Team Foundation Server 2010 build servers, and that support has carried over to Team Foundation Server 2013. You can safely connect Team Foundation Server 2010 and 2012 build servers to Team Foundation Server 2013.

After testing the upgrade in a separate environment, you will want to establish downtime for the Team Foundation Server environment to be unavailable to end users while the upgrade wizard is upgrading the schema for the databases. The amount of time necessary depends on the amount of data currently stored in the legacy databases as well as the version of the database schema in the legacy databases. For example, if you are upgrading from Team Foundation Server 2010, then the upgrade process will take more time because there are more schema upgrade steps necessary. The amount of time is also extremely variable and dependent on hardware, disk speed, available memory, and so on. This is also another great reason for doing a hardware migration-based upgrade.

When the predetermined cutoff time for your team arrives, make sure that users are no longer using the environment and take a full backup of the database. Any changes made to the legacy environment after the full backup occurs will not be available on the upgraded server.

After the upgrade has been successfully completed, a different set of databases will be used by the Team Foundation Server 2013 environment, if you were upgrading from Team Foundation Server 2010. Legacy SQL Server backup plans may be looking for the legacy database names, so you will want to ensure that any relevant backup plans are reviewed and modified accordingly.

Note

Chapter 23 provides more information about disaster recovery with Team Foundation Server.

Upgrading Prerequisites

Team Foundation Server 2013 drops support for several pieces of prerequisite software formerly supported with earlier versions of Team Foundation Server. Before running the upgrade wizard, you will want to ensure that all prerequisite software has been upgraded to the supported versions because the upgrade wizard will block you from continuing if those conditions have not been met.

Like Team Foundation Server 2012, Team Foundation Server 2013 does not support 32-bit Windows Server operating systems. The following Windows Server operating system versions are supported with Team Foundation Server 2013:

· 64-bit version of Windows Server 2008 R2 with SP1 (Standard, Enterprise, or Datacenter editions)

· Windows Small Business Server 2011 with SP1 (Standard, Essentials, or Premium Add-on editions)

· 64-bit versions of Windows Server 2012 (Essentials, Standard, or Datacenter editions)

· 64-bit versions of Windows Server 2012 R2 (Essentials, Standard, or Datacenter editions)

Additionally, Team Foundation Server 2013 supports installing Windows client operating systems, although the reporting and SharePoint integration features will be disabled if you install on any of the supported client operating systems. You will also be unable to run a TFS proxy if you are using a client operating system. The following versions of the Windows client operating systems are supported with Team Foundation Server 2013:

· 64-bit or 32-bit versions of Windows 7 with SP1 (Home Premium, Professional, Enterprise, or Ultimate editions)

· 64-bit or 32-bit versions of Windows 8 (Basic, Pro, or Enterprise editions)

· 64-bit or 32-bit versions of Windows 8.1 (Basic, Pro, or Enterprise editions)

SQL Server

Several changes were made in this release for the requirements for SQL Server. The following versions of SQL Server are supported with Team Foundation Server 2013:

· SQL Server 2012 with SP1 (Express, Standard, or Enterprise editions)

· SQL Server 2014 (Express, Standard or Enterprise editions)

You will notice that SQL Server 2008 is no longer supported with Team Foundation Server 2012. You will also notice that Microsoft has confirmed support for the next version of SQL Server. This is unusual, but is helpful to know for teams who always want to be using the latest and greatest versions of software.

Team Foundation Server 2013 supports using the Express version of SQL Server 2012, if you would like to take advantage of a lighter-weight version of SQL. The Reporting Services and Analysis Services features are not available if you use SQL Express. This configuration is common if you choose to use the Basic configuration wizard or use Team Foundation Server Express. However, if you are upgrading a server, you will be using the Upgrade configuration wizard.

Warning

Despite offering only a single (current) option for SQL Server support, there are some caveats and warnings to be aware of. These include choosing the correct collation settings, installing updates in certain cases, and being aware of feature availability for different editions.

We recommend that you familiarize yourself with these details to ensure your upgrade succeeds. You can find these details at http://tinyurl.com/SQLTFS2013.

Warning

Virtualization of the server that has SQL Server installed is not recommended without the proper hardware and disk performance outputs because it can lead to data loss and severe performance problems. If you choose to use virtualization of the SQL Server machine, be sure to configure the virtual machine for top performance when working with Team Foundation Server. See the discussion about virtualization in Chapters 2 and 21 for more information.

SharePoint

Team Foundation Server 2008 supported Windows SharePoint Services 2.0 for the team project portal sites. Unfortunately, if you are still using Windows SharePoint Services 2.0, you must upgrade to one of the following versions of SharePoint products and technologies supported by Team Foundation Server 2013:

· Windows SharePoint Services 3.0 (no licensing cost)

· Microsoft Office SharePoint Server 2007

· SharePoint 2010 Foundation (no licensing cost)

· Office SharePoint 2010 Server

· Office SharePoint 2013 Server

Note

For more information about upgrading the SharePoint products and technologies for a Team Foundation Server 2010 environment, see the related information and step-by-step instructions available on MSDN athttp://aka.ms/TFSUpgradingSharePoint.

Project Server

If you integrated with a Project Server instance in Team Foundation Server 2010, then you will not need to worry about upgrading the Project Server software before upgrading your Team Foundation Server instance. The following versions of Project Server are supported with Team Foundation Server 2013:

· Project Server 2010 with SP1

· Project Server 2013

System Center

If you have set up the Lab Management functionality in Team Foundation Server 2010 with System Center Virtual Machine Manager, then you do not need to make any changes to your System Center 2008 R2 instance. That version is still supported in Team Foundation Server 2013. You can later upgrade that instance to use System Center Virtual Machine Manager 2012 with SP1, but that does not need to occur during the upgrade. If you are going to install System Center 2012, be sure to also install Service Pack 1 which adds support for Windows 8 and Windows Server 2012.

Using the Configuration Utility

The latest version of the Team Foundation Server 2012 Installation Guide and the MSDN Library have step-by-step lists of instructions and checklists that detail how to upgrade using either upgrade approach (in-place upgrade or hardware migration-based upgrade). You will want to make sure that you follow each part of the checklist to ensure the smoothest upgrade possible. The latest version of the step-by-step walkthroughs and checklists are always available on the MSDN library at http://aka.ms/UpgradeTFS.

If you are following the hardware migration-based upgrade approach, you will essentially back up the databases on the old database server instance and then restore them on the new database server instance. Once you have upgraded all of the prerequisite software and restored a full backup of all of the Team Foundation Server databases as listed in the Installation Guide, you are ready to go through the Team Foundation Server upgrade wizard.

As mentioned in Chapter 3, the setup configuration process is split into two parts. There is an installation phase that puts all of the necessary software on the application tier server. You will also want to make sure that you have installed the latest Team Foundation Server 2013 update released from Microsoft before moving forward.

Once the software and updates are installed, you configure them with a separate configuration utility. This segmented approach resolves the legacy issue introduced in earlier versions of Team Foundation Server (an installation that was successful but whose configuration failed). In those cases, all of the software was removed from the server, even though it was correctly placed. Now you are able to get everything installed, and a rich user interface (UI) can let you know if there are any problems during the configuration phase, instead of it occurring inside of an installer.

Interestingly, another benefit of this two-phase approach is that Microsoft can release service packs and updates that will easily fix problems with the configuration utility. This became particularly important starting with Team Foundation Server 2012 because Microsoft has committed to providing more frequent updates that include new features along with performance and bug fixes. The faster release cadence means you can expect three or four major updates every year for Team Foundation Server.

Upgrade Wizard

Instead of installing a new server as described in Chapter 3, you will need to run the upgrade wizard once to get the database schema upgraded to the version used by Team Foundation Server 2013. The Upgrade wizard option is available in the configuration utility, as shown in Figure 27.1.

Figure 27.1 Upgrade wizard option

If you will be including multiple application tier servers in a Team Foundation Server application tier farm, you must run the Upgrade wizard only once for the first application tier server. You can then use the Application-Tier Only wizard for each additional application tier server to connect them to the already upgraded databases.

Note

Chapter 22 provides more information about scalability options for Team Foundation Server using network load balancing to create a Team Foundation Server application tier farm.

Follow each of the upgrade wizard pages at this point and enter the information requested. The latest version of the Installation Guide, or the MSDN Library upgrade articles mentioned earlier, has step-by-step directions and information about each option displayed within the upgrade wizard.

Before the upgrade process begins, all of the options and information that you input will be validated to ensure that there are no issues. If you see any errors listed, you must resolve them before continuing. For several errors that may occur, you are able to restart the verification process without leaving the wizard.

Once you are ready, you can begin the upgrade process. This will kick off several upgrade jobs that will run through the upgrade steps necessary for each subsystem of Team Foundation Server. The upgrade wizard will show you the progress of each set of upgrade jobs, the configuration instance, and each of the project collections.

Verification of Upgrade

After all of the upgrade jobs have completed for project collections, you will get a confirmation. If there were any issues, you can restart the job using the Team Foundation Server Administration utility. If you did receive a successful confirmation that the upgrade has completed, you can try out any or all of the following verification items to ensure everything is working properly:

· Check to ensure that any existing version control workspaces still exist and are configured the same as before the upgrade.

· Open the version control repository and check to make sure shelvesets and pending changes for your workspace still exist.

· Check the maximum changeset in the version control repository and ensure that it is the latest expected changeset that occurred before the cutoff time and the full backup.

· Open and create work items.

· Run work item queries to check that all of the expected work items are returned.

· View existing builds and queue new builds with legacy build definitions.

· Navigate and open SQL Reporting Services reports. (It may take several hours before the new warehouse has been populated with data.)

· Ensure that you can navigate to the SharePoint team portal sites and that the Documents node shows all document libraries from the associated team portal sites.

· Navigate to the Team Web Access site to verify that it loads successfully and displays the correct information.

· Ensure that test plans and test cases can be accessed through Microsoft Test Manager.

· Check to make sure that environments created using Lab Management are listed in the Lab Center of Microsoft Test Manager.

Additionally, to ensure that the entire environment is healthy, you should run the Best Practices Analyzer for Team Foundation Server 2013 (as introduced in Chapter 21), available in the latest version of the Team Foundation Server 2013 Power Tools. This will run a full set of rules to check the entire environment to make sure everything is working as expected. You can also start monitoring the environment using the techniques you learned in Chapter 25.

Upgrading Legacy Team Projects

Now that you have a working Team Foundation Server 2013 instance based on the upgraded legacy version of the databases, you will notice that the legacy team projects will be working exactly the way they did in the earlier versions of Team Foundation Server. This means that several of the new features introduced in Team Foundation Server 2013 will not be available for team members. This will also be the case for some features introduced in Team Foundation Server 2012, if you were upgrading from Team Foundation Server 2010.

One way that you can start using the new features is to create new team projects that use the latest version of the process templates included with Team Foundation Server 2013, then to perform a version control move operation into the new team project.

However, existing build definitions and work item tracking do not have standard tools available for moving to the new team project. For work item tracking, you could potentially use the Team Foundation Server Integration Platform tools; but, again, this would be a low-fidelity data transfer, as previously discussed.

The upcoming sections primarily focus on the steps necessary to enable Team Foundation Server 2013 features for team projects created using the standard process templates available in Team Foundation Server 2010 or Team Foundation Server 2012.

Feature Enablement

One of the exciting improvements that was introduced in Team Foundation Server 2012 was the new Configure Features Wizard. The Configure Features Wizard helps you enable the new features available in Team Foundation Server for team projects created using one of the standard process templates available in earlier versions.

To clarify, the Configure Features Wizard will not change the process template or upgrade those team projects to new versions of the corresponding process templates, but it will help by enabling some of the new Team Foundation Server 2012 and 2013 features. This is primarily to save you time that would normally be needed to perform manual steps. The features that can be enabled by the Configure Features Wizard are:

· Portfolio backlogs (including Feature work item type and Category)

· Code Reviews

· Stakeholder Feedback

· My Work

· Planning tools (product backlog, Iteration planning, and task boards)

· Storyboard integration

· Hidden Types work item category

The first time that you navigate to the Team Project administration section in Team Web Access, you will see a message indicating that features are available for that team project, but they must be configured before they can be used, as shown in Figure 27.2.

Figure 27.2 New features available for notification from the administration section of Team Web Access

By clicking on the link in that message, you can start the Configure Features Wizard for this team project, as shown in Figure 27.3.

Figure 27.3 Configure Features Wizard

The Configure Features Wizard will attempt to inspect the process template currently being used by that team project and see if it can detect a newer version that can be partially applied. If it is not able to detect the appropriate process template, it may allow you to manually choose a new Team Foundation Server 2013–based process template registered with the server.

If you are satisfied with the choice, you can click Configure and the wizard will enable as many features as possible. A confirmation page that lists any additional steps that you need to take will appear. If the process does not complete successfully, you must either manually update the team project or attempt to run the Configure Features Wizard again after updating a registered process template.

You can find out more about the Configure Features Wizard, as well as other manual methods for enabling the features introduced in Team Foundation Server 2013, by visiting this MSDN article: http://tinyurl.com/EnableTFS2013Features.

If you have a team project created from a heavily customized process template, manual instructions that you can follow to enable the features introduced in Team Foundation Server 2013 are available at http://aka.ms/UpdateCustomTFSProcess. One of the options for those with customized process templates is the ability to manually add the necessary functionality to your custom process template and upload and register the compatible process template. You can then run the Configure Features Wizard and use your updated custom process template. This can be extremely beneficial if you have several team projects to update.

Configuring Features for Many Team Projects

If you need to configure features for several team projects at once, running through the wizard for all of your projects one at a time can be very time consuming. With Team Foundation Server 2013, you have the ability to programmatically configure features.

Ewald Hofman has a great blog post that walks readers through the process of automating this configuration. The post relates to Team Foundation Server 2012, but with some minor changes it will work with Team Foundation Server 2013. You can find it at http://tinyurl.com/MultipleTFS2013Features.

Allowing Access to Premium Features

As previously discussed in Chapter 24, Team Foundation Server 2013 includes premium features in Team Web Access that should be available to use only by team members with certain editions of Visual Studio licensed to them. Those Visual Studio editions are as follows:

· Visual Studio 2013 Premium with MSDN

· Visual Studio 2013 Ultimate with MSDN

· Visual Studio 2013 Test Professional with MSDN

You control this access by setting the licenses for users in the Team Web Access Administration pages. Three types of license groups are available for Team Foundation Server 2013, which enable certain features:

· Limited—Can include all users in your organization who need the ability to create work items. Does not require a Team Foundation Server CAL.

· Standard—Includes all users that have a Team Foundation Server CAL or Visual Studio Professional with MSDN.

· Full—Includes all users with one of the Visual Studio editions mentioned previously that have access to all of the features in Team Web Access.

Licensing Groups and Permissions

Adding a user or security group to one of the Licensing groups mentioned in this section does not give those users the permissions required. Those users still need to be granted the appropriate permissions necessary to use the features that are enabled for each team project. More information about security and permissions can be found in Chapter 24.

After you upgrade to Team Foundation Server 2013, the default licensing group is set to Standard, which would include administrative users such as your account. When navigating to a team site in Team Web Access, you will see a notification similar to Figure 27.4that indicates that some features are not visible to you.

Figure 27.4 Features Not Visible notification from Team Web Access

To enable the full set of features for users that have a license to access them, you should go to the Team Web Access Administration site for managing the license groups, as shown in Figure 27.5. You can find that site by opening an Internet browser and navigating to the URL for your Team Web Access site in the format of http://yourtfsservername:8080/tfs/_admin/_licenses and replacing it with the appropriate settings for your Team Foundation Server instance.

Figure 27.5 Managing the licensing groups

Add the appropriate users or security groups to the Full licensing group, or if you know that all users who will be accessing this Team Foundation Server instance will be licensed appropriately, you can set the Full licensing group as the default web access licensing group for all users.

Automated Builds

Build definitions that existed in Team Foundation Server 2010 before upgrading that used the default workflow-based build process template will continue to work after the upgrade. If you have an opportunity, especially if you do not have any build process template customizations, you can switch your build definitions over to using the new default build process template that was added to each of the team projects during the upgrade process. This will ensure that you are using all of the latest updates included in the latest version.

If you had any custom build process templates that included custom build workflow activities, you will need to take an additional step: Update the references to the latest version before recompiling your customer workflow activities and making them available for deployment to the build controller and agents, as explained in Chapter 19.

We highly recommend taking the new default build process template from Team Foundation Server 2013 and applying all of your customizations appropriately so that you can take advantage of all of the new features included in the new version of the build process template. You can then use that newly customized build process template going forward.

Note

Chapter 19 includes more information about how to customize the build process and create custom build workflow activities.

Enable Local Workspaces

Local Workspaces, which you learned about in Chapter 6, are one of the features that make developers more productive. For new Team Foundation Server 2013 installs, Local Workspaces (as opposed to server workspaces) are enabled by default for any new workspaces that are created. However, for backwards compatibility reasons and because it is a new paradigm shift for those that might have worked with Visual SourceSafe or earlier versions of Team Foundation Server in the past, the default remains set to server workspaces whenever you upgrade from an earlier version of Team Foundation Server.

We highly recommend that after your server is upgraded you change the default to Local Workspaces. The next time one of your developers connects to the server, she will even get an option to “upgrade” her legacy workspace into a Local Workspace. That notification to the developer is only shown if the default is changed in the server settings. A step-by-step walkthrough is available for how to update the default at http://aka.ms/SetTFSWorkspacesDefault.

Deploying New Reports

The data warehouse schema for Team Foundation Server 2013 has been updated and no longer works with the reports included in Team Foundation Server 2008 or earlier. If your migration involved an upgrade from Team Foundation Server 2008 (via either Team Foundation Server 2010 or 2012), you can deploy a new set of reports using the new process templates (assuming you have performed all of the “morphing” steps to get your team project up to the latest process template version) by using a tool available from the latest version of Team Foundation Server Power Tools. It is available from the command line by using the following:

tfpt.exe addprojectreports /collection:http://tfs:8080/tfs/

DefaultCollection /teamproject:LegacyTeamProject /

processtemplate:”MSF for Agile Software Development 2013” /force

This command will download the specified process template and deploy all of the reports included in the process template appropriately to the reporting site associated with the specified team project. The /force option allows you to overwrite what already exists if there is a report with the same name. You can modify the reports, upload the updated process template, and repeat this process as necessary.

Deploying New SharePoint Team Portal Site

Team portal sites that exist in legacy team projects do not take advantage of all of the SharePoint dashboard features as described in Chapter 15. This is one of the toughest options because there is no way to convert an existing site and enable the dashboards on a portal site template.

In this case, the best option would be to archive the document library content from the legacy team portal site, create a new team portal site using the latest process template, and then add the archived document library content. There may be other types of features that were used that may not be able to migrate over successfully. You will have to weigh the options appropriately.

The latest version of the Team Foundation Server Power Tools also includes a command-line tool for creating a new team portal site and associating it with a team project. The following example command could be used to perform this step:

tfpt.exe addprojectportal /collection:http://tfs:8080/tfs/

DefaultCollection /teamproject:LegacyTeamProject /

processtemplate:”MSF for Agile Software Development 2013”

You can specify additional options if you want the team portal site to be created in a different location from the default location specified for the team project collection.

Upgrading Lab Management Environments

You need to make sure that you upgrade any test controllers that you have configured for your Team Foundation Server instance to the Visual Studio 2013 version of the test controller software. Be sure to also install any of the relevant updates that might be available for the Visual Studio 2013 test controllers.

After upgrading from Team Foundation Server 2010, all of the environments created using Lab Management (available from the Lab Center in Microsoft Test Manager) will be marked as needing to be upgraded before they can be used again. The Visual Studio agents installed in each of the machines in the environment need to be updated.

Thankfully, you can leverage the agent auto-install and auto-configure features in Team Foundation Server 2013. These will automatically uninstall the old agents and install and configure the new test agent software for you. Be sure that you have installed any of the latest updates for the Test Controllers so that the most up-to-date version of the Visual Studio 2013 Agents is installed.

If you do decide to also upgrade to System Center Virtual Machine Manager 2012, be sure to also upgrade the System Center Virtual Machine Manager 2012 Administration Console software on each of the application tier servers. You will also likely be prompted with an informational message that indicates that Team Foundation Server has detected a newer version of System Center, similar to Figure 27.6.

Figure 27.6 New System Center version detected

You will want to perform the step indicated in that informational message, which is running this one-time command on any of the Team Foundation Server 2013 application tier servers:

TFSConfig.exe Lab /UpgradeSCVMM

Summary

As you learned in this chapter, the upgrade wizard will allow you to move all of your data from a legacy version of Team Foundation Server to Team Foundation Server 2013, using a high-fidelity upgrade method. In this chapter, you learned about the two types of upgrades—an in-place upgrade and a hardware migrated-based upgrade.

Additionally, you learned about the preparation steps necessary for a successful upgrade, including taking care of any prerequisite software. Finally, you learned about the features not available on legacy team projects until they are enabled in Team Foundation Server 2013.

Chapter 28 introduces the issues that come up whenever you have geographically separated teams that need to use the Team Foundation Server environment. The chapter explores the different options available to resolve those issues, and it provides methods for ensuring a smoothly operating worldwide environment for all of the geographically separated teams.