Share →
Buffer
Dan Wood (Mugshot)

Well, mostly…

We had the opportunity to perform an upgrade/migration from TFS 2008 to the RTM version of TFS 2012 this last week. The install was being done for a fairly small team so we went with a single-server configuration. Everything but the build and proxy service would reside on a single Windows Server 2008 R2 instance, including SQL Server, Analysis Services, Reporting Services and SharePoint.

 The initial installation worked as advertised with only one surprising message announcing the need to perform an immediate reboot due to the installation of the .NET 4.5 framework.

Oh! OK. We can do that.

To get ready for the migration we gave the development teams a 90 minute warning to check in all their code and then stopped IIS on the TFS 2008 server. While the DBA backed up the TFS 2008 databases we installed SQL Server 2012 on the new TFS 2012 server using the default installation. Once the installation and database backups were complete we copied the database backups over to the new server. We have seen instances where the databases were detached and moved during an upgrade. That’s fine as long as the detached databases are only copied and NOT moved. The upgrade process is destructive to the existing database schema. If something goes wrong, those databases will be of no use to anyone. Use caution. That may seem pretty obvious, but sometimes the eagerness to complete an installation can cloud our judgment and cause us to make silly mistakes. J

The 2008 databases; tfsVersionControl, tfsBuild, tfsWarehouse, TfsWorkItemTracking, TfsWorkItemTrackingAttachments and TfsIntegration were restored using the script below.

In TFS 2008 multiple databases were used to store the TFS data. In TFS 2010 the data was combined in to a single database with the exception of the warehouse database. The upgrade process will perform the same function, moving all the data in to the appropriate single-database schema.

 USE [master]

RESTORE DATABASE TfsActivityLogging

FROM DISK = N’D:Old TFS Backups20120808_TfsActivityLogging.bak’

WITH MOVE N’TfsActivityLogging’ TO N’D:SQLDATATfsActivityLogging.mdf’

    ,MOVE N’TfsActivityLogging_log’ TO N’D:SQLLogsTfsActivityLogging_log.LDF’

,STATS = 5

GO

RESTORE DATABASE TfsBuild

FROM DISK = N’D:Old TFS Backups20120808_TfsBuild.bak’

WITH MOVE N’TfsBuild’ TO N’D:SQLDATATfsBuild.mdf’

    ,MOVE N’TfsBuild_log’ TO N’D:SQLLogsTfsBuild_log.LDF’

    ,STATS = 5

GO

RESTORE DATABASE TfsIntegration

FROM DISK = N’D:Old TFS Backups20120808_TfsIntegration.bak’

WITH MOVE N’TfsIntegration’ TO N’D:SQLDATATfsIntegration.mdf’

    ,MOVE N’TfsIntegration_log’ TO N’D:SQLLogsTfsIntegration_log.LDF’

,STATS = 5

RESTORE DATABASE TfsVersionControl

FROM DISK = N’D:Old TFS Backups20120808_TfsVersionControl.bak’

WITH MOVE N’TfsVersionControl’ TO N’D:SQLDATATfsVersionControl.mdf’

    ,MOVE N’TfsVersionControl_log’ TO N’D:SQLLogsTfsVersionControl_log.LDF’

    ,STATS = 5

GO

RESTORE DATABASE TfsWarehouse

FROM DISK = N’D:Old TFS Backups20120808_TfsWarehouse.bak’

WITH MOVE N’TfsWarehouse’ TO N’D:SQLDATATfsWarehouse.mdf’

    ,MOVE N’TfsWarehouse_log’ TO N’D:SQLLogsTfsWarehouse_log.LDF’

    ,STATS = 5

GO

RESTORE DATABASE TfsWorkItemTracking

FROM DISK = N’D:Old TFS Backups20120808_TfsWorkItemTracking.bak’

WITH MOVE N’TfsWorkItemTracking’ TO N’D:SQLDATATfsWorkItemTracking.mdf’

    ,MOVE N’TfsWorkItemTracking_log’ TO N’D:SQLLogsTfsWorkItemTracking_log.LDF’

    ,STATS = 5

GO

RESTORE DATABASE TfsWorkItemTrackingAttachments

FROM DISK = N’D:Old TFS Backups20120808_TfsWorkItemTrackingAttachments.bak’

WITH MOVE N’TfsWorkItemTrackingAttachments’ TO N’D:SQLDATATfsWorkItemTrackingAttachments.mdf’

    ,MOVE N’TfsWorkItemTrackingAttachments_log’ TO N’D:SQLLogsTfsWorkItemTrackingAttachments_log.LDF’

    ,STATS = 5

GO

Databases safely restored. Now comes the fun part, running the upgrade wizard.

 

 

 

 

 

 

 

 

 

This should be very straightforward and easy…, right?

Listing the available databases shows the 2008 tfsIntegration database. I found it amusing that the wizard insisted I acknowledge that I had a current backup!

 

 

 

 

 

 

 

 

The rest of the steps are very straightforward. First identify a service account. The built in NETWORK SERVICE can be used, but specifying a user account is generally preferable, especially when installing assets on different servers. NTLM Authentication is the default, but Kerberos is available (albeit, more complicated as the dialog warns)

 

 

 

 

 

 

 

 

 

The application tier settings are the typical with port 8080 and tfs as the virtual directory. You can get fancy and do anything you want here, but in our experience using the default ports and names makes things simpler in the end.

 

 

 

 

 

 

 

 

 

Yep, we want to configure Reporting as part of our install. No job is complete without documentatio

More defaults for the reporting, which was configured earlier when installing SQL Server

 

 

 

 

 

 

 

 

 

Same goes for Analysis Services

 

 

 

 

 

 

 

 

 

Next comes the reader account. It’s a good idea to use a different account than the service account.
No need to put all your eggs in one service account basket and the reader account needs very limited and specific access.

 

 

 

 

 

 

 

 

 

We want to use SharePoint, so we choose that option and configure where we will be putting our TFS project portals. Additionally the SharePoint extensions were installed earlier and a root site collection created for TFS. The TFS Agile template feature was enabled at the collection level as well. The root site location is chosen as well as the central administration site

 

 

 

 

 

 

 

 

 

The last step is to set the properties of the collection. Do yourself a favor and DON’T use “DefaultCollection.” Choose a name that readily identifies the collection and gives it a much more distinctive and important presence. Default anything doesn’t sound very impressive…

 

 

 

 

 

 

 

 

 

TF255361? No worries. SharePoint wasn’t really being utilized with the 2008 installation. This just means we will have to configure the portals after we are done.

Awesome. Everything looks good!

Everything configured and upgraded, with no errors, although the warning about the missing project portals is raised again. We can safely ignore that. It took about 35 minutes to complete the upgrade process with approximately 25GB of 2008 data to upgrade.

The 2008 databases upgraded great and we immediaetly had access to the source control library and could navigate the team projects with both Team Explorer and Team Web Access.

However, Team Web access can catch you off guard. Exactly what does this message mean?

 

 

 

 

 

 

 

 As it turns out, Team Web Access in 2012 comes with three distinct views, Full, Standard and Limited.

Martin has a great blog (http://blog.hinshelwood.com/tfs-2012-issue-some-features-of-team-web-access-are-not-visible-to-you/) that explains it all so I won’t repeat or plagerize him here!

Next we will take a look at enabling all those cool 2012 features like code review, my work, feedback, planning tools and storyboarding. For out of the box 2010 or 2012 projects, it’s a piece of cake. For higly customized “Franken-Templates” or upgraded 2008 projects, it can be much more complicated.

Stay tuned!

Print Friendly