• Team Foundation Server Planning Checklist
• This covers everything from hardware requirements to domain considerations, backup/restore planning, security requirements, and more
• Team Foundation Administration Walkthroughs
• This includes scenarios such as "Setting up Groups and Permissions", "Customizing Check-In Policies and Notes", and "Setting up Team Foundation Server to Require HTTPS and SSL"
• Customization
• There are topics for customizing Work Item Types, Process Templates, and the Build System

These are just a few of many topics. If you're about to deploy a Team Foundation Server, or want to get more out of the server(s) you already operate, this is a great resource.

Is it bright where you are?

Some folks are new to the concepts (e.g. many folks familiar with labels, sharing, and pinning in SourceSafe, but want to step up to TFS). Others have a system in place that they're unhappy with. Others have a system that is working, but they wonder (or even hope) that there is a better way they could be going about it.

First, the bad news: There is no silver bullet. There isn't a "right way" to go about this that applies to everyone. Even the solution we use internally has merits and drawbacks.

Now the good news: There ARE some general trends and associated best practices; odds are good one of these will be similar to your unique situation. We also have a lot of resources, examples, and experience that we can share. Finally, we're always open to feedback on what needs we aren't meeting, so if it sounds like you have needs that we can't yet meet, please let us know.

Before I go farther, one disclaimer: I am not an expert of this particular problem space. But, hopefully I know enough to get you started and point towards the experts.

The first resource I suggest everyone check out is the TFS Branching Guidance on Codeplex. This content covers branching and Team Project structures, physical layout, some "anti-patterns", and includes a comparison to SourceSafe.

I'll point to some previous blog posts that relate to this, but first, let me put my own spin on the topic.

In my opinion, there are two fairly common models that a lot of users will fall into (one or the other, sometimes some of both):

1. You produce one (or a small number) of products, releasing and maintaining various versions over time (be it a website, shrink-wrap software, etc.)
2. You have a lot of projects going on at once, and most of them have a finite lifecycle. Once it's "released", it goes into maintanence, but typically it makes more sense to spin up a new project than to keep working within the existing one.

For people in the first category, a three-branch model (typically called "dev-test-production" or something similar) works well. Some of the details vary; for example, if you publish to a website, you might re-use your test and production branches constantly, whereas, for shrink-wrap releases, you'd probably create separate versions of these branches for each major release, and potentially additional ones for minor releases. In either case, your ongoing feature work happens in the main branch (or development branches off of it); you branch (or merge into) the test branch when you're ready to stablize for a release, and you branch (or merge into) the production branch when it goes live. On the merge side, you'd take fixes as needed in each branch, and merge them back up (from prod to test, and from test to dev) as needed.

For the second category, a branch per project makes perfect sense. If a given project has a formal release process, you might create the same dev-test-production structure underneath these branches as well. The key here is that the project-specific code and other artifacts are each in their own branch, while in the first model everything lives together.

A frequent variation to this scenario is where there's a set of shared tools or code that spans many or all of the projects. In the SourceSafe world, these are frequently shared, but you can't do that in TFS. Instead, I'd probably recommend a separate branch (and/or project) for the shared components. They probably have their own release cycle - so you make that tools branch the "master" and branch it into each project that needs them. You can then roll out versions to each consuming project in a predictable way. You might also consider limiting (or even preventing) changes to these components from ever merging BACK into the parent from the project branches, but either approach can work depending on your situation.

If neither of these scenarios sounds like your team, please leave comments/feedback - we can probably find a model that works for you.

Finally, here's a few posts that talk about branching and merging:

• Buck
• More on branching and merging vs. sharing and pinning
• A simple example using branch and merge
• Branching, Merging, and Shelving
• Chris
• Branching
• Shelving vs. Branching/Merging vs. Labeling: Which should I use?

There are several other posts out there, but I think this are good places to start - if nothing else, to turn a few general questions into lots of specific ones! :)

I have a smile...stretched from ear to ear...

Over the course of the week, several topics emerged as common questions and themes. Over the next several blog posts, I'll try to address each of these.

In rough order of popularity (measured by how many times the questions were asked in my hearing):

1. Branching and Merging in TFS
   Example questions: "How should I do it? Is there a better way than...? Why should I use branching instead of labels in VSS?"
2. Moving to TFS (specifically, version control) from existing systems
   Examples: "What's in TFS? Why should I move? How do I move? What is there besides version control?"
3. TFS Upgrade
   Examples: "I want to move from TFS 2005 to TFS 2008. Anything I should know? Does TFS upgrade also update my databases?"

I have commentary on each of these areas, and I'll include links to relevant resources for each as I go. If there are other topics you'd like me to address, just let me know and I'll add to the list.

We're just two lost souls swimming in a fishbowl...

 I'll be at the Team Foundation Server booth in the Technical Learning Center most of the week.

Here are some follow-up thoughts and further questions based on the received data:

1. I apologize for the survey closing after 100 responses were received. I didn't know the survey mechanic I chose had that limitation. If you weren't able to submit a response and still wish to do so, please let me know via comments or the contact link and we'll get your data (somehow).
2. Some folks want to use SharePoint 3 but are forced to use SharePoint 2. Just to clarify - there's no technical reason you shouldn't be able to move to SharePoint 3. I'm assuming these folks meant 'forced' as in 'due to corporate IT policy' or something like that. Similarly, a few other folks didn't know you could modify TFS 2005 to use SharePoint 3. MS produced a couple whitepapers on this subject; if you're interested in modifying your Whidbey TFS this way, take a look at this blog post to get started.
3. A few folks hesitate to modify their TFS because they wanted to be sure they were running known/tested configurations. I completely understand this sentiment. To help address those concerns, we'll work on describing the configurations we test in more detail going forward. Feel free to describe a config you're interested in and I'll tell you if (and how often) we test it or one close to it.
4. The Web Client is very popular, and several people would like to host it on a machine other than the AT. The good news here is that with the Rosario release, setting up the web client should be easier than ever, and we at least hope to support it being off the AT (but I can't promise anything!).
5. I didn't ask any questions about how your Build or Proxy components fit into your TFS deployment (if at all). These may deserve a separate survey, but I wanted to focus on the TFS AT and DT this time around.
6. Several 'other' responses and comments took the form of feature requests, which is a welcome bonus to the data I was seeking. To that end:
1. 64-bit support for the AT (including Single Server) should be in Rosario (barring some as-yet-unknown significant technical challenge).
2. Advanced backup is something we're looking at, but I don't have any details right now.
3. A couple folks want to know about scaling plans. I don't have a lot I can share but it's definitely an area we're looking at.
4. Several folks want to be able to run TFS on their DC. This is a restriction we'd like to relax and we're looking at the technical challenges we'd have to overcome to support it (it has to do with identity management).

That's all for now...

I'll give up everything just to find you

• All on one box - App Tier, Data Tier, SharePoint all on one machine
• Typical 2-box - AT and WSS on one box, and the DT on another box
• "Explosion" - AT, SQL RS, SQL AS, DT, WSS all on separate machines (you can take this even farther by moving databases to separate SQL machines/instances)

There are about two dozen variables that define a configuration, and there are nearly a hundred possible values spread across those variables. Since testing each of the thousands of combinations is impractical, we identify a subset of configurations using customer data, bug trends, code coverage, and other analysis, and test those (our configuration Matrix for Orcas ranged from 25-31 different configurations).

I'd like to collect more of that 'customer data' I just mentioned. By telling us what your actual TFS configuration looks like, we can make sure that the configurations we test map to ones actually deployed 'in the wild'.

To that end, I've created a short survey you can fill out to describe your TFS deployment. It's short (10 questions), you shouldn't need to provide any sensitive data, and it will help ensure that your current and future deployment strategy is one we understand and support. If you own or manage multiple TFS deployments, feel free to fill out the survey once for each.

The tenth question is free-form, so you can choose to provide more specific information if you like. Anything you send will be protected by Microsoft's Privacy Policy.

So please, take 5 minutes and tell us about your TFS.

This feature is also available in TFS 2008 (aka Orcas) but with some slight changes.

Our guidance to people using this feature is to install/configure SharePoint and Reporting Services off of the AT (or move them, for existing installs). These products have their own availability features, and configuring both the primary and standby ATs to use the off-box WSS and RS means less things to do during a failover procedure.

This is different from Whidbey - back then, you were required to have SharePoint and RS installed and configured on both ATs.

To install TFS 2008 with an off-box RS instance, you'll need to modify your msproperty.ini. Sudhir has a blog post with the details. Note that this capability (off-box RS and AS) was not in Orcas Beta 2 but will be in the RTM version.

TFS has some challenges in this area - when you build on top of so many other technologies (the OS, .Net, SQL Server, SharePoint), getting everything into a good state takes some doing.

With Whidbey, the approach was to be very strict about the preconditions so we could be sure setup would finish. With Orcas, we've tried to become a lot more flexible - where SharePoint is installed, how SQL is configured (even where SQL Reporting and Analysis services are located), supporting Longhorn Server and SQL Katmai (Windows Server 2008, SQL Server 2008), and so on.

It also supports upgrading from Whidbey (TFS 2005), of course. So, the challenge is to make sure setup can still complete reliably - or tell you why you can't in a way that's useful.

Our Beta2 release has most of the changes and is a good preview of what the Orcas experience is like (you can find it here). We're maintaining a troubleshooting guide to both help with any rough edges, and solicit feedback on the experience - you can find that here.

Have you given TFS Orcas Beta 2 a try? If so, we would love to get your feedback - here, on the forum, whatever works for you.

I need to figure out how to add a Poll to this post - I'd love to get a gut check for how many people think it "rocks", "makes a vacuum", or somewhere in between...

A million watts of sound can't compare

Issue 1: Installing and Configuring Windows SharePoint Services on LHS

We've been doing this via automated testing for some time, but only recently discovered that doing it manually is actually a bit tricky. Installing and configuring WSS via the LHS component manager is pretty straightforward; but we discovered that manually creating a web application (or modifying an existing one) via the SharePoint admin website fails (with an Access Denied error page).

You can work around this by using stsadm.exe - from an elevated command prompt. You might be able to avoid this by disabling UAC, but I do NOT recommend doing so.

Issue 2: Manually installing IIS on the TFS Application Tier (as a prerequisite for installing SQL Reporting Services)

I did this by hand recently, after stumbling through a problem where the SQL installer kept claiming IIS was not installed, even though it was. It turns out that the default IIS install options do not include a feature that the SQL installer needs - HTTP redirection. Not having it causes the installer to flag as if IIS was missing entirely.

These issues will almost certainly be addressed in due time - Server 2008 is still pre-release software, after all. But, if you're trying to evaluate TFS Orcas Beta 2 (aka Microsoft Visual Studio Team Foundation Server 2008 Beta 2), hopefully this will help you succeed.

Everything will come around in time.

To jump straight to the goodies (note that, right now, the Tech Notes page has a little bug where 1501 and 1502 both link to the 1501 note):

TN1501: Configuring Windows SharePoint Services 3.0 on the Visual Studio 2005 Team Foundation Server Application Tier

TN1502: Configuring Windows SharePoint Services 3.0 on a Remote Server to work with Visual Studio 2005 Team Foundation Server

Also bear in mind that with TFS Codename Orcas, you'll be able to target these without additional work on a clean install, and we'll even give you the option to have us install WSS3 (on the AT) for you.

OT: I'm going to keep doing random quotes from songs that are fresh in my mind. I'll plug a random Google feature I just accidentally discovered, by linking future quotes to their meta-data on the song (for the curious). If anyone's really interested, maybe I'll even go back and link the quotes from older posts...

When you're taught through feelings