Orcas Beta 2 refresh is now available for download. Please read the post by Brian that provides more information on Beta 2 refresh at http://blogs.msdn.com/bharry/archive/2007/09/28/updates-to-tfs-2008-beta-2.aspx

You can download the refresh bits at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=053E83D0-DEB4-4EBB-B4C8-CBFFE928B4AA&displaylang=en

You can send us your feedback at tfsb2sup@microsoft.com.

Some of you may have read by previous post on Mirroring with TFS at http://blogs.msdn.com/sudhir/archive/2006/10/30/using-sql-mirroring-with-tfs.aspx. This post is for Orcas or VS2008 release.

TFS leverages SQL Server for storing data. This allows our customer to leverage various failover options that come with SQL Server. SQL Mirroring is a great option. You can use clustering if you need automatic failover but if a small downtime is acceptable Mirroring is a good solution. TFS does not support automatic failover with mirroring. Few manual steps need to be executed when the primary server fails with mirroring in TFS. Following are the high level steps required to use mirroring.

The process of configuring a TFS deployment for mirroring can be defined in following steps

1. Backup databases from the main Data Tier Server(Principal server)
2. Restore backed up databases on mirror server.
3. Setup Mirroring for each database between Principal and Mirrored servers
4. Perform manual Failover to enable Mirrored Server as principal server.
   1. Manual failover when primary server is available can be performed using Management studio
   2. Manual failover when primary server is unavailable(Forced service Failover) can be performed using ALTER DATABASE command in TSQL Statements.

      ALTER DATABASE database_name SET PARTNER FAILOVER, where database_name is the mirrored database.

5. Map Application Tier to talk to new Data Tier(Mirror Server) using TFSAdminUtil RenameDT
6. Now you have the databases active but we store some messages in sysmessages table in Master DB and we also have few SQL jobs which will not get created by just restoring the databases. To restore these you have couple of options
   1. You can run repair on Application Tier machine which will fix the Data tier
   2. You can run TFSDB utility which is in Tools folder for TFS. This is quicker and much faster.

      TfsDb.exe repair /server:<servername> /property: "TFS_SERVICE_ACCOUNT=<TFSServiceAC>; TFS_REPORTING_ACCOUNT=<TFSReportingAC>; LCID=1033; VSTF_AS_INSTANCE=<ASInstance>; VSTF_AS_DATABASE=TfsWarehouse;VSTF_AS_ACCOUNT="

TFS Databases: TfsBuild, TfsIntegration, TfsVersionControl, TfsWarehouse, TfsWorkItemTracking, TfsWorkItemTrackingAttachments, TfsActivityLogging

Team Foundation Server 2008 can be deployed in different configurations. In 2008 release we have made the product very flexible from deployment perspective. That means now you will have many components to think about in fail over or redundancy. In this post I will focus on TFS only components for SQL Reporting services and WSS you can follow on line MSDN docs for TFS or SQL RS/WSS.

TFS can be deployed in Single server configuration or dual server configuration. We do not provide any fail over options in single server configuration (MSDN Doc: http://msdn2.microsoft.com/en-us/library/ms316473(vs.90).aspx)

In dual server scenario you have 2 machines Application Tier and Data Tier:

Data Tier: All TFS data is stored in SQL Server. Therefore you can use any of the standard SQL fail over or high availability options. You can use Clustering, SQL Mirroring or Log shipping. The failover in case of Mirroring and Log Shipping cannot be automatic. We need to perform couple of steps before mirrored databases are activated. I will have posts on Mirroring and Log shipping coming soon.

Application Tier: TFS provides warm standby Application Tier support. If you run a TFS Orcas install and if databases are already present and mapped to different application tier we automatically setup a Warm Standby server for you. Warm standby will be non functional server deployment of TFS. If your primary application tier server fails you can use TFSAdminUtil ActivateAt to activate your Standby Server.

Hope this information was helpful.

TFS can be deployed in single server or dual server deployment. Dual server is when your application tier and data tier are on 2 different physical machines. Single server deployment is when everything is on same machine.

My last 3 posts covered recovery in various scenarios of dual server deployment. Let's take a look at single server deployment now. What happens if the machine hosting TFS in single server configuration dies? Following are steps you can follow to recover in that situation. All this information is only round TFS and does not include SQL Reporting services and SharePoint, if you need details on everything you should access online MSDN documents.

1. Reinstall TFS on single server machine. You can use the install guide to do this. At end of this step you should have a running TFS single server configuration.
2. Install any service packs or patches you had installed on the crashed machine
3. Now recover the databases from your backup
4. If your machine name remained same you should be ready to go.
5. If you changed your machine name you need to rum TFSAdminUtil with RenameDT and ActivateAT options

In my last post I blogged about recovering from a crashed AT. TFS also supports a warm standby of AT. This helps you fail over to the warm standby AT when the primary AT fails. This is really great as it reduces the recovery time. You can setup a warm standby by running TFS 2008 setup and provide existing DT machine as input. TFS setup will detect the primary AT is different machine and automatically install a warm standby for you.

If you have warm standby and your primary AT machine crashes you can activate the standby AT and make it the primary AT by running TFSAdminUtil command line tool with ActivateAt option.

• TfsAdminUtil ActivateAt <standby server>

Team Foundation Server can be deployed in dual server environment with Application Tier and Data Tier on 2 different servers. In my last post I wrote about recovering from a DT crash. Now let's look at how we can recover from crash of AT machine.

In case of AT crash, the easiest way to recover is to reinstall TFS 2008. The best part about our TFS 2008 Setup is you can reinstall TFS with existing databases without any problems.

• What does that mean?

  Basically you can run the TFS installer and point it to use existing databases. We check the version of databases and if it is VS 2008 (Beta 1, Beta 2 or later) or VS 2005(RTM or SP1) our setup will use the databases and install the AT and if required will upgrade the database to correct version.

Steps to perform:

1. Install Pre-requisites as defined in Install Guide
2. Run TFS Install and provide existing database server as input.

Team Foundation server can be setup in dual server environment with application tier running on one machine and the data tier running on different machine. We use SQL Server as our backend and we support named instances for SQL Server in VS2008. We also recommend taking regular backups of your TFS databases. In VS2008 you can use existing WSS and SQL Reporting Services. This post is going to summarize the steps you can take to recover just the TFS part of data.

In VS 2008 unlike 2005 we just have 1 SKU for all types of install. You can install TFS on single server or dual server from 1 setup that runs on the application tier machine. In case your Data Tier machine crashes you can follow following steps to recover your environment.

• Install the base OS and SQL Server as per the guidance in Install guide
• Restore the backed up databases on the newly installed environment
• Now you have the databases restored but we store some messages in sysmessages table in Master DB and we also have few SQL jobs which will not get created by just restoring the databases. To restore these you have couple of options
  • You can run repair on Application Tier machine which will fix the Data tier
  • You can run TFSDB utility which is in Tools folder for TFS. This is quicker and much faster.

    TfsDb.exe repair /server:<servername> /property: "TFS_SERVICE_ACCOUNT=<TFSServiceAC>; TFS_REPORTING_ACCOUNT=<TFSReportingAC>; LCID=1033; VSTF_AS_INSTANCE=<ASInstance>; VSTF_AS_DATABASE=TfsWarehouse;VSTF_AS_ACCOUNT="

Now your system should be ready for use. If you changed the name of the DT server while recovering the new system you will have to run TFSAdminUtil renameDT command.

Let's start this post with good old Murphy's Law "Anything that can go wrong will go wrong". Therefore we need to figure out how we can fix things once they have gone wrong. In TFS there are few scenarios that come to mind when you think about disaster recovery

1. Recover from Data Tier crash
2. Recover from Application Tier Crash
3. Recover from Application Tier Crash when you have Warm Standby
4. Recover from whole system crash(AT & DT on same machine)

I feel there are few areas of TFS deployment which don't have enough guidance or documentation. We are always working on improving the documents but I want to take a stab at these areas and provide some guidance on these. Please give me feedback on other areas you would like to know more about. The areas are

1. Disaster recovery
2. Redundancy or Fail Over
3. Move: There are MSDN documents available on this topic. I will cover the high level options in this blog but for more details you should follow MSDN docs.

We have put in lot of efforts in Orcas. There were many features we thought we would not be able to achieve but we finally squeezed them in. One such feature which customers have been asking for is flexibility with how we use SQL Reporting Services. Many customers want to move SQL Reporting services to other machines that TFS AT or use existing Reporting infrastructure. We have added lot of flexibility in how you use Reporting Services. First of all we were not able to get all the changes required into the UI so you will have to fall back to the MSIProperty.ini file. Sorry about that.

Steps:

1. Open MSIProperty.ini from InstallMedia\AT
2. Change following properties to set Reporting information

• VSTF_RS_SERVER=[ComputerName]
• VSTF_RS_REPORTS_URI=http://<reportserver>/<somepath or reports>
• VSTF_RS_REPORTSERVER_URI= http://<reportserver>/<somepath or reportserver>

1. Run setup and install TFS

Scenario we have tested:

1. Running Reporting Services on DT machine. This was not supported in Whidbey and now this is something we have made sure it works.
2. Running Reporting services on machine anywhere on the network.
3. Running Reporting services and WSS on remote machine

Requirement:

To configure reporting on remote box we make WMI calls that require us to have remote admin rights on the machine. I hope this is not a big problem to our customers. I know in large enterprises all ports and access rights are secured and this maybe an issue. I hope customers can work around this problem.

Few customers have seen failures in upgrading WSS2.0 to WSS3.0. When they run the upgrade utility the process fails after step 2. It is helpful to take a look at the log file but in many cases the upgrade has succeeded if you run the upgrade with forceupgrade option. Here is a command that was tried by one customer and they were able to successfully upgrade the WSS server.

In place upgrade:

%commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\Bin stsadm -o upgrade -forceupgrade -url http://companyweb – inplace

Side by Side Upgrade:     

%commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\Bin stsadm -o upgrade -forceupgrade -url http://companyweb – sidebyside