TFS 2010 Admin, Operations & Setup Improvements
Since I started with the key architectural concepts, I think the most appropriate place (though perhaps least exciting) is the setup/admin/ops feature area.
Pre-reqs
I wrote a post on pre-reqs a while ago but I’ll refresh it a bit here. To save me typing and you reading, you can assume an “and later” appears following each supported version listed below. This is a bit more detailed than the post I wrote before now that we know what the service pack landscape looks like.
Server Operating System – Windows 2003 SP3, Windows 2008 SP2, Windows 2008 R2.
64-bit – The TFS 2010 server will ship with both 32-bit & 64-bit versions. The TFS Client object model will also be support both 32-bit and 64-bit clients. But most of our client executables (like Visual Studio) will continue to run in the 32-bit subsystem of 64-bit operating systems.
Virtualization – TFS will support all virtualization environments that are approved in the Windows Server Virtualization Validation Program. A mouth full, eh?
SQL Server – SQLServer 2008 SP1, SQLServer 2008 R2
Sharepoint – WSS 3.0 SP2, WSS 4.0, MOSS 2007 SP2, MOSS 2010
Client Operating Systems – Windows Vista SP1, Windows 7, Windows 2003 SP2, Windows 2003 R2 SP2, Windows 2008 SP2, Windows 2008 R2.
Office – 2007 SP1, Office 2010
System Center Virtual Machine Manager – SCVMM 2008 SP1 (if you use the lab management features).
Compatibility
As in the past, compatibility remains a very high priority for us. At the same time, TFS 2010 represents a huge step forward and 100% seamless compatibility simply isn’t possible. However, we will be doing to work necessary to make sure people aren’t left behind.
New client/Old server – The TFS 2010 client will work with either a TFS 2005 SP1 or a TFS2008 SP1 server. Of course, some of the new client features won’t “light up” when used against a previous server version but the new clients will work fine.
Old client/New server – We will be releasing a patch to the VS/Team Explorer 2008 client that enables it to work seamlessly with a TFS 2010 server. This patch will be available before TFS 2010 Beta 2 ships to enable broader testing before our release. We will also be updating the TFS MSSCCI provider so a broad array of IDE environments will continue to work with TFS 2010 servers. When I last posted on this topic, I said that we would release a VS/Team Explorer 2005 patch as well. We have since decided not to plan for that. When we looked at the installed base data and the trend data, it indicated that very few people will still be on the 2005 clients in 2010. We’d certainly like to hear feedback if people think we are substantially misjudging.
Custom clients – There is a new version of the TFS object model being released. Custom TFS extensions that use the old object model and run in their own process will mostly continue to “just work”. Those that run in Visual Studio (or another host that loads the newer version of the object model) will need to be recompiled.
Build – TFS Build will be able to build .NET 2.0, 3.0, 3.5 and 4.0 applications out of the box. Existing MSBEE solutions will still be necessary to build .NET 1.1 applications. Unmanaged C++ 2010 projects can now be seamlessly integrated while previous versions will still require MSBuild exec tasks to build C++ targets. Build servers will need to be upgraded to 2010 along with associated TFS servers but the builds should continue to work well.
Topology enhancements
Improvements in supported topology, scale and configuration options has been another big investment in TFS 2010. Of course we still support previous topologies (like everything installed on a single server).
Application tier network load balancing (NLB) – The biggest advantage of NLB is high availability. NLB allows us to have multiple application tiers serving the same TFS farm. If one of the application tiers fails or needs to be taken out for patching/servicing/etc, the TFS farm can continue to serve users. Secondly NLB enables more scale of a TFS farm by spreading the load across the TFS application tiers. See this post for more details. We’ll support both Windows NLB and dedicated NLB devices.
SQL Server scale out – In TFS 2010, project collections can be allocated to different SQL servers and served by the same TFS farm. This significantly improves your ability to consolidate TFS operations across organizations while being able to load balance, capacity plan, isolate and manage them appropriately.
Improved Sharepoint flexibility –
- Sharepoint association with TFS is now optional
- Sharepoint sites/collections can now be shared between Team Projects
- A Team Project portal can be any URL (not just a Sharepoint site)
- Improved support for TFS using a central Sharepoint server farm (enabling separate administration, site collection creation, etc)
- A TFS farm can reference Sharepoint sites on multiple Sharepoint servers/farms
- Team Project sites can now be Sharepoint sub sites rather than entire site collections
- Process guidance can now be shared across Team Projects to make maintaining consistent guidance easier
Report Server flexibility – Reporting Services is now optional. It can also be more easily configured off box.
Zone support – Like zones in Sharepoint, TFS now can be accessed from different zones (e.g. intranet vs internet) via different urls.
Kerberos support – TFS 2010 can now be reasonably easily configured to use Kerberos authentication instead of NTLM.
Separation of TFS and SQL administration – We see a number of enterprise accounts where the SQL administrators are different than the TFS administrators and they don’t want to give SQL SA permissions to the TFS owners. In TFS 2010, we have enabled a separation so that SQL admin level operations (like creating databases) can be done separately from TFS administration/configuration. It’s a relatively small but important part of our customer base that finds this level of control critical.
Here’s a picture to help you imagine what a scaled out TFS installation might look like:
Setup
We’ve made another huge investment in setup in this version. We continue to hear from customers that installing TFS takes too long and is too error prone. We’ve made a ton of setup improvements to try to make installing TFS easier.
Separate install from configure – In 2005 & 2008, TFS configuration was integrated into the setup logic. This had a few undesirable ramifications. Among them, if a failure was encountered anywhere along the way, setup would rollback and you’d have to start over again. There was no option to fix and keep moving forward. Also, if we found a bug in the configuration logic, we couldn’t release a patch for it. Our patches only work if the software has been installed. By separating installation from configuration in TFS 2010, the first phase is simply copying the software onto the server and doing basic registration. All configuration work is done in a separate phase. Once the copy phase is complete, the software is serviceable and patches can be applied. The configuration phase can be completed one piece at a time without ever rolling back. Of course all of this is chained together in the setup UI in such a way that it feels like a unified installation experience even though it’s two very separate phases.
Improved installation wizards – There are now two TFS installation wizards (Default & Custom). Default is optimized for very simple single server TFS installs with default settings and will make installing TFS easy for many people. The custom wizard provides a new level in the ability to customize the TFS installation (SQL instances, accounts, ports, databases, etc). In previous versions many of these configuration options involved modifying .ini files or manual configuration steps. More advanced customizations are now much easier.
Optional components – In TFS 2010 Sharepoint and Reporting Services are now optional. You can install TFS without installing them and if at some point in the future you would like to add them you can.
Simplified account requirements – Previous versions required multiple accounts to configure TFS. TFS 2010 can now be configured with just one domain/local account.
Improved Reporting Services configuration – Rather than trying to hide Reporting Services configuration (and often confusing people), we now expose the Reporting services configuration wizards from inside TFS tools.
Setup consolidation – Team System Web Access has now been integrated into the TFS server setup experience. It’s no longer necessary to install it separately. In addition, Work Item Web Access (the limited CALless access to TFS) has been integrated into Team System Web Access and into the overall TFS setup. Lastly, the Team Explorer client setup has been integrated into the Team System role (Development, Architecture, Test, Suite) setups. So, if you purchase a Team System role product you no longer need to install Team Explorer separately. Of course, it can still be installed separately for users who don’t use a Team System role product.
Upgrading from previous TFS versions – We’ve invested a lot to ensure that upgrading from previous versions of TFS to TFS 2010 is smooth. First, we have enabled the upgrade experience both from TFS 2008 and TFS 2005 (and all SPs of both). We don’t want to make someone jump from 2005 –> 2008 –> 2010 to get there. Second we have taken to heart the customer feedback that major TFS upgrades are often associated with overall hardware/topology changes – single server –> dual, dual server –> single, new hardware (with new machine names), etc. We also hear that people want to do trial upgrades on test hardware before trying it in production. In previous versions, this was complicated, often involving many manual steps. In TFS 2010, we have optimized for the scenario where the target upgrade hardware/topology is different. Of course, we still support straight forward in-place upgrades too.
Improved IIS flexibility – TFS 2010 now supports use of virtual directories in IIS to improve manageability. Among other things this means that configuring TFS to run on port 80 along with Sharepoint is much easier than it was previously.
And on to some pictures…
Here’s the screen flow for phase 1 – copying/registering the software.
As you can seen this phase doesn’t really ask many questions (mostly just where you want to install the bits). Notice the little check box at the bottom of the 3rd screen. This screen is the end of “phase 1” and that checkbox is the link to “phase 2” – configuring TFS. It’s checked by default so hitting Finish will link to the configuration sequence I’m showing below. But you can also uncheck it, install patches if needed and then re-run it.
The first screen the configuration wizard is a launcher that let’s you pick what you are configuring.
I’ll show you the default configuration sequence first to show how easy that path is.
Notice the little “Test” link next to the user account. You’ll see this a lot throughout the wizards. In order to help people make sure they don’t go down bad configuration paths, we allow them to test their data entry as they go.
And here are a few screen shots from the Custom wizard to show you the kind of options can be configured. It’s not the full list but it gives you a pretty good picture of the new flexibility. The last 4 from the default wizard that I showed above are also reused in the Custom wizard.
Administration
In previous versions, administering/configuring TFS involved a mix of command line tools, config files, IIS settings, etc. In TFS 2010, we’ve made a significant investment in a comprehensive administration experience. I’m not saying we’ve solved the problem completely but it’s a big step.
Administration console – We now have a real TFS admin console that helps you understand how TFS is configured and make adjustments. Features of the admin console include:
- Review/configure TFS topology – application tiers, data tiers, databases, Sharepoint, Reporting Services, build servers, etc.
- Enumerate, create and delete team project collections
- Enable/disable Team Project Collections – individual Team Project Collections can be disabled/enabled so they can be serviced independently.
- Export/Import of TPCs (see the section on Team Project Collections for more on this)
- Consolidated access to various TFS logs
- Integration of the features from the TFSVersionDetection tool
- and more…
Consolidation of command line tools – Command line tools are still valuable in spite of the new admin console. They enable much easier scripting of admin operations for one thing. We’ve made some progress in consolidating the various admin tools (witimport, witexport, …) into a few broader admin tools – tfsconfig, witadmin, …
User rename support – In previous versions of TFS, changing a user’s name was manual. Once it was changed in Windows/AD, there were steps that that had to be run to update TFS. For a large organization, it was a repetitive task. In TFS 2010, it is totally automatic. When a user’s name is changed in Windows/AD, TFS is automatically updated.
I think a few screen shots will help make this feel more real. Please note that this isn’t final. The final version will have a few differences but it will be close to this. Also, this is just a subset of the screens because there are too many for me to show them all. Notice the actions on the right hand side that make common administrative tasks easy.
Project Collections
Read my post on key new TFS concepts for an overview of Team Project Collections. In this section, I’m just going to focus on the features/benefits rather than the architectural changes. It’s hard for me to list every scenario that Team Project Collections enables because there are so many but I’ll focus on the ones I hear asked about all the time.
Archive/restore individual project collections – In previous versions, the entire TFS server had to be backed up/restored so if you wanted to recover a specific project from a backed up state, you had to restore the entire server. In TFS 2010, you can separately backup and restore individual Team Project Collections.
Move Team Project Collections – Team Project Collections can be moved between SQL Servers within a TFS farm, between TFS farms in the same network and between TFS farms on different networks (which will be a bit harder than the first two because of no identity continuity between networks).
Server consolidation – In TFS 2010, multiple TFS servers can be merged together into a single TFS farm (a request we are increasingly seeing as organizations want to fold grass roots TFS adoption into a centralized service).
Team Project Collection Split – A Team Project Collection can be split into separate collections each containing a subset of the Team Projects. The primary scenario in which I expect to see this used is migrating from TFS 2005/2008 to TFS 2010. Because you could, essentially, only have 1 Team Project Collection in previous versions of TFS, many customers have accrued 10’s or 100’s of projects on a single server. TFS 2010 will allow them to be broken up.
Team Project Collection Isolation – Each Team Project Collection is a separate administrative entity. This means that you can reasonably do shared hosting of collections with appropriate separation of administration and operations responsibilities and without hosted teams needing to know about each other.
Misc Features
Server request cancellation – In previous versions of TFS, if you killed a command (for example, by hitting Ctrl-C on the command line) after a request had already been dispatched to the server, the server request would run to completion even though the client would stop. In TFS 2010, killing the client propagates to the server and will automatically terminate the server processing as well.
Summary
As you can see there’s a ton of stuff here. Overall, in this release, the admin, operations and setup experiences may very well have been the largest investment we’ve made. The only other area, as you’ll see in the coming weeks, that rivals it is our project management/work item tracking improvements. But, it’s a big overall release so although this may be the biggest individual section, it’s still a small fraction of the overall new TFS value.
I hope you’ll find a lot of this valuable. I realize a lot of this is more oriented towards larger customers and may not appeal to smaller development teams or individual developers. Fear not, that stuff is coming too. Just hold on and I’ll tell you about it.
Brian
Light
Dark
0 comments