On Cloud Computing, Integration Technology, Mobility, RFID, ERP etc...
Sr, Program Manager at Microsoft and MBA from UNC Chapel Hill.My small world includes my beautiful wife Swati and our awesome twin boyz Arni and Abhi.
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.
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.
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.
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:
Next Run TFS Setup
After V1.0 we got a lot of feedback around SharePoint. Following are few things we heard a lot
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.
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
Provisioning of WSS2.0
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
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.
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
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
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.
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.
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
Steps to follow:
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
Analysis services flexibility: It is possible for customers to move Analysis services to different box than TFS DT machine.