One major scenario for most of our customers who are using Visual Studio 2005 Team Foundation Server is moving to Orcas and leveraging the new features around WSS3.0. The upgrade path to this is very simple and straight forward. This post is focused on performing in-place upgrade of WSS. That means you upgrade WSS2.0 to WSS3.0 on the TFS server itself.

As I mentioned in my last post related to Upgrade. We want you to make sure you have a working Whidbey before trying to upgrade to Orcas. We don't want you to change the configuration of the server.

The steps to upgrade are as follows.

• Run Orcas TFS installer to upgrade your VS2005 TFS server. At end of this process you should have Orcas server with WSS2.0 configured.
• Next Run WSS prescan.exe tool to verify if you can upgrade WSS from 2.0 to 3.0
• Run WSS3.0 Installer and select the upgrade option
• The installer will ask you for new Administration Port. You cannot use the old port(17012). You need to select new port number.
• Complete all the installation and upgrade steps for WSS3.0
• Now you should have Orcas server with WSS3.0. You still cannot use the system as you still need to tell TFS about the new URLs for WSS and also upload the new site templates for WSS3.0
• Run Share Point Extensions for TFS setup. This should be located at InstallMedia\WssExt directory. This will upload the new site templates for WSS3.0.
• The upgrade changes the WSS admin site URL. To make this change in TFS you can use TFSAdminUtil . Following is the command you can use.
  • TFSAdminUtil configureconnections /SharepointAdminUri:http://wssserver:adminport  

Note: You can use TFSAdminUtil to update all the different URL's for WSS. Following is the syntax for updating all WSS related attributes in TFS.

• TFSAdminUtil configureconnections
  • /SharepointURI:http://wssserver:80 
  • /SharepointSitesUri:http://<wssserver:80/sites
  • /SharepointAdminUri:http://wssserver:adminport
  • /SharepointUnc:\\wssserver\sites

Hope this post is helpful. Please let me know your experiences.

Orcas supports Named Instances of SQL Server. In VS 2005 we only supported default instance of SQL Server this was a major pain point for customers using SQL farms. We fixed this in Orcas and now you can use named instances of SQL. This post is about how to upgrade from VS 2005 TFS using default instance to Orcas using Named Instances.

As I mentioned in my last post related to Upgrade. We want you to make sure you have a working Whidbey before trying to upgrade to Orcas. We don't want you to change the configuration of the server.

The steps to upgrade are as follows.

• Run Orcas TFS installer to upgrade your VS2005 TFS server using Default Instance. At end of this process you should have Orcas server with default instance.
• Next take full backup of all the TFS Databases. You can refer to http://msdn2.microsoft.com/en-us/library/ms253070(VS.80).aspx for the process of taking backup. Easiest way is to use SQL Management studio.
• Restore all these backed up databases on Named Instance of SQL Server you want to use with TFS. Now you should have all the databases moved to new instance. You can refer to http://msdn2.microsoft.com/en-us/library/ms252458(VS.80).aspx for more details on restoring databases.
• We have some information in sysmessages table in masterdb and SQL jobs in MSDB. These are not restored by previous step. To get these you can either run repair or you can run tfsdb.exe from your tools directory
  • TfsDb.exe install /server:"<servername>\<instancename>" /property:"TFS_SERVICE_ACCOUNT=<TFSSERVICEACCOUNT>;TFS_REPORTING_ACCOUNT=<TFSREPORTSACCOUNT>;LCID=1033" /log:d:\logfile.txt
• At this point TFS is not going to work as TFS AT does not know anything about the new location of the databases.
• You can use TFSAdminUtil to update the system with new SQL Instance information.
  • Command: TFSAdminUtil RenameDt NewDTServerName\InstanceName

Now you should have your TFS configuration ready to go. You can also refer to Renaming TFS Server topic.

Orcas Beta2 release of Team Foundation Server will enable support for Analysis server flexibility. Many customers want to install SQL Analysis services on a different machine than SQL Database Services. One primary reason is load balancing. We have enabled this scenario in Orcas. The experience is not very great but the solution works. We will improve the experience going forward in next release.

To setup TFS with Analysis services on different machine than the SQL Database services you need the AS machine name(ASMachineName) and SQL Instance Name(ASInstanceName). If you want to avoid taking dependency on SQL Browser service you require the Port(ASPortNumber) on which AS is running.

Steps to install Orcas with AS Flexibility:

1. Open the MSIProperty.ini file located under InstallMedia\AT directory
2. Change VSTF_AS_INSTANCE property to provide information about your SQL Analysis services. You can use any one format mentioned below
   1. For Default Instance: VSTF_AS_INSTANCE= ASMachineName
   2. For Named Instance: VSTF_AS_INSTANCE= ASMachineName/ASInstanceName
   3. For Named Instance with no dependency on SQL Browser or fixed port: VSTF_AS_INSTANCE= ASMachineName:ASPortNumber

Next Run TFS Setup

After V1.0 we got a lot of feedback around SharePoint. Following are few things we heard a lot

1. Why can't you install WSS for us?
2. Why can't you just use my existing WSS farms? Why do I have to dedicate a WSS installation for TFS?

We heard you all. We fixed these 2 major issues for you. Orcas Beta 2 installer will have support for WSS 3.0. Following are few things we support.

1. Orcas TFS setup can install WSS3.0 for you. We ship WSS 3.0 on our media therefore you don't have to worry about anything. We will install it, Provision it and upload the site templates we need for TFS.
2. We also support use of existing Share Point Farms. You can either use WSS2.0 farms or WSS3.0 farms. The only thing we expect from you is
   1. Have a pre-provisioned WSS environment. That means you should have configured your WSS. Have it up and running.
   2. We require the Sites URL and Admin URL for your existing farm. Make sure you can get to these URL from your browser.
   3. If you are using WSS on any other machine than your TFS Server you also need to run setup for Share Point extensions for TFS. This setup has to be run on your WSS server.

Orcas Setup will ask your preference on WSS page and you can choose one option, either install or use exiting WSS. We really did not want to tell you how to configure your WSS environment and therefore we are not going to document the provisioning steps for WSS on TFS MSDN site. Finally who are we to tell you how to setup and configure your environment? Having said that I can share with you the steps we follow to provision our test WSS environments. These are scripts which we use to provision WSS for internal testing of TFS installer.

This is not guidance just a sample of what we do…

Provisioning of WSS3.0

• SETLOCAL
• SET WINFXPATH=WINFX_INSTALL_PATH
• SET WSSINSTALLPATH=WSS_INSTALL_PATH
• SET WSSTEMPPATH=%USERPROFILE%\Local Settings\Temp\wss.tmp
• SET WSSBINPATH=C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin
• SET WSSOWNERLOGIN=WSS_SERVICE_ACCOUNT_DOMAIN\WSS_SERVICE_ACCOUNT_USER
• SET WSSOWNERPASSWD=WSS_SERVICE_ACCOUNT_PASSWORD
• SET WSSDBINSTANCE=DATABASE_SERVER
• SET WSSWEBSITEDESC=Default Web Site
• mkdir "%WSSTEMPPATH%"
• CALL "%WINFXPATH%\DotNetFX3.exe" /q /norestart
• "%WSSINSTALLPATH%\SharePoint.exe" /extract:"%WSSTEMPPATH%" /quiet
• "%WSSTEMPPATH%\setup.exe" /config "config.xml"
• "%WSSBINPATH%\stsadm.exe" -o setconfigdb -databaseserver "%WSSDBINSTANCE%" -farmuser "%WSSOWNERLOGIN%" -farmpassword "%WSSOWNERPASSWD%"
• if NOT %ERRORLEVEL%==0 then goto eof
• "%WSSBINPATH%\psconfig.exe" -cmd adminvs -provision -port 17012 -windowsauthprovider onlyusentlm
• "%WSSBINPATH%\stsadm.exe" -o extendvs -exclusivelyusentlm -url http://%COMPUTERNAME%:80 -ownerlogin "%WSSOWNERLOGIN%" -owneremail "admin@localhost" -sitetemplate sts -description "%WSSWEBSITEDESC%"
• if NOT %ERRORLEVEL%==0 then goto eof
• "%WSSBINPATH%\stsadm.exe" -o siteowner -url http://localhost:80 -secondarylogin %userdomain%\%username%
• if NOT %ERRORLEVEL%==0 then goto eof
• iisreset
• ENDLOCAL

Provisioning of WSS2.0

• SETLOCAL
• REM Variables you need to set are here:
• SET StsAdm="D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Bin\Stsadm.exe"
• SET ServiceUser="ServiceAccountDomain\ServiceAccountUser"
• SET ServicePassword="ServiceAccountPassword"
• SET DataTierInstance="DataTierInstance"
• REM DataTierInstance can also be "Machine\Foo" or "Machine,1234" for named instances
• REM Set the admin port to the value we typically use:
• %StsAdm% -o setadminport -exclusivelyusentlm -port 17012 -admapcreatenew -admapidname TFSWSSADMIN -admapidtype configurableid -admapidlogin %ServiceUser% -admapidpwd %ServicePassword%
• if NOT %ERRORLEVEL%==0 then goto eof
• REM Create/assign the config database:
• %StsAdm% -o setconfigdb -databaseserver %DataTierInstance% -databasename "STS_Config_TFS"
• if NOT %ERRORLEVEL%==0 then goto eof
• REM Create the Virtual Server:
• %StsAdm% -o extendvs -exclusivelyusentlm -url http://localhost:80 -ownerlogin %ServiceUser% -owneremail "admin@localhost" -dn "STS_Content_TFS" -apcreatenew -apidname TFSWSS -apidtype configurableid -apidlogin %ServiceUser% -apidpwd %ServicePassword% -sitetemplate sts
• if NOT %ERRORLEVEL%==0 then goto eof
• REM Delete and recreate the SQL RS path exclusions
• REM Note, the deletes will error if they don't already exist – you can ignore those errors:
• %StsAdm% -o deletepath -url http://localhost:80/ReportServer
• %StsAdm% -o addpath -url http://localhost:80/ReportServer -type exclusion
• if NOT %ERRORLEVEL%==0 then goto eof
• %StsAdm% -o deletepath -url http://localhost:80/Reports
• %StsAdm% -o addpath -url http://localhost:80/Reports -type exclusion
• if NOT %ERRORLEVEL%==0 then goto eof
• REM Force the Virtual Server instance to the correct version (of ASP.Net etc.)
• %StsAdm% -o upgrade -forceupgrade -url http://localhost:80
• if NOT %ERRORLEVEL%==0 then goto eof
• ENDLOCAL

Hopefully this information is useful. Please let me know if you need any additional information.

As I mentioned earlier we now support running TFS service as network service. The primary advantage of using network service is, you don't have to worry about managing the password for the account. If you are using VS 2005 TFS running under domain account and want to move to Orcas with TFS Service running under Network Service following are the steps.

Steps to upgrade TFS 2005 with Domain account to Orcas with Network Service

• Run Orcas TFS installer to upgrade from VS 2005 TFS to Orcas TFS. At end of the setup you will your TFS environment upgraded to Orcas with TFS service running under the service account used in Orcas.
  • We do not recommend you to change the service account at time of upgrade
• After the upgrade is over you can use TFSAdminUtil to change the service account. The command to change the service account is as follows
  • TFSAdminUtil changeaccount OldDomainAccount "NT Authority\Network Service"

Now you should have your Orcas environment up and running with Network Service.

Please give us your feedback. Is this good enough solution or do you want us to improve this experience.

We have put in a lot of effort on getting our Upgrade experience right. It is not perfect but I think it is great. This post is first in the series of posts around upgrade. You can have so many scenarios around upgrade; I will take one scenario at a time to provide more details. For now let's talk about basic upgrade from VS 2005 TFS to Orcas Beta 2 or higher. The experience for you should is same as new setup. Our upgrade is completely integrated into setup. Setup will ask for your database server name. We probe the database server to check if it is a existing database from VS 2005. If it is we upgrade it to Orcas. You can either have VS2005 RTM or SP1 version.

We also realized some customers may uninstall VS2005 before running Setup for Orcas and therefore we have made sure the Orcas setup can handle that scenario. Following are few pre-requisites for upgrade to work flawlessly.

1. You should have had a running VS 2005 before you started the upgrade process. It does not matter if you uninstalled VS2005, but before you uninstalled the VS2005 TFS server must be in healthy and running state.
2. You are not allowed to change the service accounts at time of upgrade. You have to use the same TFS service and data sources account that was used to run TFS before upgrade.
   1. You can change the accounts after upgrade is successful using TFSAdminUtil tool.
3. You should not try to change the name of TFS servers or database location at time of upgrade all this can be done after the upgrade is successful.

Having spoken about limitation now let's talk about some key scenarios you all will be interested in. You all want to use the new features provided in Orcas. How do you get your VS 2005 TFS Server to run with all the new features of Orcas TFS? Following are the major scenarios

1. How do I upgrade from VS 2005 with default instance of TFS to Orcas with SQL named instance?
2. How do I upgrade from VS 2005 with WSS2.0 to Orcas with WSS3.0?
3. How do I upgrade from VS2005 with WSS3.0 to Orcas with remote (existing) WSS3.0 farm?
4. How do I upgrade from VS 2005 with domain account for TFS service to Orcas with Network Service?

I will try to explain each of these scenarios in next few posts. The key here is the standard upgrade will only upgrade you from VS 2005 TFS with WSS2.0 to Orcas TFS with WSS2.0. We have to perform some extra steps to achieve above 4 scenarios. It is not difficult but just few more steps.

You should see additional posts soon…

Please read http://blogs.msdn.com/sudhir/archive/2007/08/03/upgrade-tfs-2005-with-wss2-0-to-tfs-2008-orcas-with-existing-wss3-0-farm.aspx if you want to upgrade to existing WSS3.0 farm.

This topic is very similar to the previous topic(http://blogs.msdn.com/sudhir/archive/2007/05/31/upgrade-2005-with-wss2-0-to-orcas-wss3-0.aspx). The primary difference is how will you move to WSS3.0 on remote machine.

The steps remain same. In short

1. Run Orcas Installer to upgrade the VS 2005 TFS server to Orcas
2. Create your WSS 3.0 environment on remote machine. Migrate your TFS sites to new environment. You can find details on this topic at http://technet2.microsoft.com/windowsserver/WSS/en/library/91046a84-57a1-40cb-a32c-ff3395073dc91033.mspx?mfr=true.
3. Now you have Orcas TFS and Remote WSS3.0 setup. But you still have to link them up to work together.
4. You can do this by using TFSAdminUtil command. Following is the command to perform this task.

• TFSAdminUtil configureconnections
• /SharepointURI:http://wssserver:80 
• /SharepointSitesUri:http://<wssserver:80/sites
• /SharepointAdminUri:http://wssserver:adminport

/SharepointUnc:\\wssserver\sites

In Orcas you can also install TFS on ports other than 8080. Again you will have to specify the port in MSIProperty.ini file. You still cannot use a port number that is already in use. We also don't try to merge sites for you. We do expect you to have a dedicated port for TFS.

Following are steps you can take to install TFS on non default(8080) port.

1. Open the MSIProperty.ini file located under InstallMedia\AT directory
2. Change following property to provide information about the port for TFS server.
   1. VSTF_WEBSITE_PORT=NewPortNumber
3. Next Run TFS Setup

At the end of setup you should have TFS server up and running on non 8080 port. You may have to open the NewPortNumber in your firewall to make things work.

Lot of customers wanted us to support network service as the service account for TFS. Some people said it was not secure enough and therefore we should not support it. The challenge we face is balancing between simplicity vs. security. Lot of customers feel Network service is pretty safe and is better because it need less maintenance. You can secure the environment using other techniques and having domain accounts for every service is too cumbersome. Following is a link to a security guidance document I found on MSDN. The document is very well written and provides very valuable information. Following is the explanation around Network service account from the document

Network Service account

The Network Service account is a special built-in account that has reduced privileges similar to an authenticated user account. This limited access helps safeguard the computer if an attacker compromises individual services or processes. A service that runs as the Network Service account accesses network resources using the credentials of the computer account in the same manner as a Local System service does. The actual name of the account is NT AUTHORITY\NetworkService, and it does not have a password that an administrator needs to manage.

Having given you the background let me hash out what we support in Orcas. In Orcas we accept 3 different accounts while setting up TFS.

1. TFS Service account: This is used to run TFS services.
2. Reporting Data sources account: This is used to access reporting data
3. WSS account: Used to run WSS services/application pool. This is optional and required only if TFS setup installs WSS for you. If you are using existing WSS we do not require this account.

We only support running TFS Service as Network Service. You cannot use network service for Reporting data sources or WSS services. The reason in both cases is security. In case of reporting data sources if you use network service suddenly every report will have access to all the data in SQL Server and therefore it is a huge risk. Similarly WSS does not allow you to use network service.

You atleast don't have to worry about changing TFS service account password every few months. J

Note: You can use the same domain account for TFS Service, Reporting data sources and WSS installation.

Few days back I wrote a post about using SQL Named instances with TFS Orcas Beta 2 release. Link: http://blogs.msdn.com/sudhir/archive/2007/04/23/sql-named-instance-support.aspx.

Some corporations do not want to keep SQL browser service running for security reasons. SQL browser service is responsible for mapping DBServerName/InstanceName into a specific server and port number. If you want to stop SQL browser service you need to run all the services on fixed ports and then install TFS with these specific ports. If you want to install TFS in such environment you will have to take few extra steps than normal.

Before we get into the actual process let me give you a bit more background. TFS uses both SQL Database Services and Analysis service. Both these run on different ports. When we use named instance with SQL browser service the service can map the name of instance to correct ports for both database service and analysis service. When you decide not to run browser service you need to give us all the ports. These ports are specific to the SQL instance you want to use. Therefore before you begin you need to gather following information

1. Machine running SQL database services: SQLDBMachine
2. Port on which your SQL Database service is running:SQLDBPort
3. Machine running SQL Analysis service: SQLASMachine
4. Port on which your SQL Analysis service is running:SQLASPort

Steps to follow:

1. Open the MSIProperty.ini file located under InstallMedia\AT directory
2. Change following property to provide information about your SQL Analysis services.
   1. VSTF_AS_INSTANCE= SQLASMachine: SQLASPort
3. Next Run TFS Setup
4. On the Database page enter the database information in following format.
   1. SQLDBMachine, SQLDBPort

Note: Please note the separator is different in both cases.

This should setup your TFS without any dependency on SQL Browser service. Please give us your feedback on this.

Feature List for Orcas

1. New Orcas Setup: Consolidation of multiple Setup SKUs into one single Setup SKU. You don't have to worry about different setups for AT vs DT vs ATDT.
2. Upgrade from VS 2005 TFS to Orcas.
   1. Customers can upgrade from RTM or SP1
   2. If you uninstalled Whidbey before starting Orcas setup. Orcas setup will still be able to upgrade your environment.
   3. We have verified working of Upgrade on SQL Cluster
3. Support for WSS3.0
   1. Orcas setup will automatically install and configure WSS3.0 for you.
   2. You can use existing WSS farms. We support both WSS2.0 and WSS3.0 farms.
   3. You can also use existing MOSS 2007 infrastructure
4. Supports Network Service so customers don't have to change their TFS Service account passwords every few months. You still need to use domain accounts for Reporting data sources for security reasons.
5. Named Instance. You don't have to depend on default instance of SQL Server any more. I have already blogged about the options available to you.
6. Port Flexibility: We have verified that TFS works on non 8080 ports.
7. Longhorn support: Customers will be able to run TFS on Longhorn server

Analysis services flexibility: It is possible for customers to move Analysis services to different box than TFS DT machine.