Chris Rathjen

The TFS Administration Guide is a great resource for anyone who maintains one or more TFS instances (or is planning/considering doing so). Here are a couple highlight topics:

• 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?

This was the most popular question asked at our booth (and perhaps all of the VSTS area) at Tech Ed Developers 2008. It was asked in various forms, but they all boil down to basically the same question: How should I manage branching and merging?

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...

I'm back after a fun week at Microsoft TechEd Developers 2008. I answered tons of questions about Team System in general - and Version Control, Build, and Setup in particular. I've brought back a variety of feedback and feature requests.

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 know my blog has been on hiatus; but if any of you readers are attending TechEd in Orlando, Florida this week (June 2-6) and would like to meet me, here's your chance :)

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

First, let me thank everyone who filled out the survey. With Brian and a few others spreading the word, we collected 100 responses very quickly.

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

I'm working on some test planning for the next release of Team Foundation Server. One area I'm focused on is testing various possible configurations of TFS. Here are a few of the configurations we regularly test:

• 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.

Some of you may be familiar with the "AT Warm Standby" feature that was included with TFS 2005 (aka Whidbey).

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.

Setup. Setup. Setup. That's what I've been focused on for quite some time, and we're pretty excited about the improvements we've made for Orcas (aka Tfs 2008). I could barely pull myself away to play Halo 3 last night! :)

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

I wanted to post a couple tips relating to some issues we've seen with this scenario, mostly because I did some searching of my own and there's not a lot of guidance out there (yet).

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.

Jeff posted that the 'unofficial' guidance for modifying TFS2005 to use WSS 3.0 (on the AT or a remote machine) is now official. You can read his full post here.

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

Totally off topic: We just got back from watching Transformers. I'll write up a bigger review if there's interest. The short version: It was awesome. Great action movie, one of the few that actually does a decent job at also telling a story and connecting you with it. Good pacing, great special effects, good integration of the music with the scenes, etc. I imagine a few die-hards won't like some of the "liberties" taken with the franchise to make it into a single-shot movie, but the rest of us should appreciate it. More than a couple nitpicks in the reality/movie physics department, but nothing excessive.

 Go see it :)

What I've done...I've faced myself

Becoming a full-time employee of Microsoft (or "MSFTie") is often jokingly referred to as "joining the collective" in public and even within our cybernetic halls.

I mentioned awhile back that we'd gotten some additional team-members on the Setup/Admin/Ops QA team, and (as James recently enlightened me), one of them just started blogging. Welcome to the land of the blogs, Abdelhamid! As he said in his first post, he started last fall, and he's done some truly wonderful work in the months since.

In fact, one of the first projects we tossed at him was creating a tool to automate the installation of Team Foundation Server. This includes installing pre-requisites, installing and then upgrading from Whidbey (TFS 2005), optionally installing and configuring SharePoint, and fully supporting our many configuration options (single- vs. dual-server, SQL named instances, remote WSS, etc.). This tool has really improved our effective bandwidth in testing setup, and we're even thinking about turning it into a Power Toy Power Tool - would people be interested in something like that?

Abdelhamid completed the 'official' training requirements for the job by now, but I haven't run him through all of our unofficial training courses yet:

1. Watch Office Space until you can recognize and/or quote memorable lines. IMHO, this is a must-have for any desk job.
2. Watch all six Star Wars movies and be able to correctly rank them in order from best to "suckiest". For bonus credit, explain why "Han Shot First" is so important to the movies and to culture at large.
3. Frag me in - well, anything, the standard typically being Halo 1/2/3 or Counter-Strike. Most team members have failed to complete (or even attempt) this course, but several other TFS (and ex-TFS) staff have no trouble with this one (namely Patrick from the Team Build team).

I'm pleased to say he has already completed one course with high marks - Bojangles Appreciation. Bojangles and I were born in the same year; coincidence? I think not.

Blowing with the wind of change...

Sudhir has been blogging up a storm lately. He has a series of posts describing what we've done to improve setup for Orcas, and covers some likely "Whidbey to Orcas" migration scenarios. For example, if you have Whidbey with a local SharePoint 2 installation, you might wonder how to upgrade to Orcas and end up with a remote SharePoint 3 deployment. Wonder no more!

It is a LOT of detail to digest, so please keep sending us feedback and questions.

Sudhir also provided a pair of scripts that we use to configure WSS2 and WSS3 after they've been installed, so that they can be used as "existing" SharePoint installs for our testing. I want to make it clear that you do NOT need to make your SharePoint match this configuration exactly; it's just the way we do it. But it's a good way to see what all is configured and which values are most frequently used.

I believe in you...

So...I haven't exactly been blogging lately. This is (mostly) a "no news is good news thing" - what have I been up to?

• Finishing up a feature crew that delivered an improved TFS setup experience, support for upgrading from Whidbey (VS 2005), enhanced support for SharePoint, and other setup- and deployment-related features (you'll see these in Orcas Beta 2 - unfortunately, we just couldn't get all that we wanted done in time for Beta 1).
• Building/Buying a new house.
• Selling our current townhouse.

The last two are long, long stories in their own right - something to save for another day or my personal blog unless popular demand indicates otherwise.

In my last post, I described our SharePoint changes in some detail. I'll outline some of the other feature work we did around the same time (and since), and 'open the floor' for questions, comments, and/or feedback on that.

• Upgrade: Starting with Beta 2, TFS's setup will have the ability to upgrade from various existing versions to Orcas.
• Note, this is not EVERY possible server that could exist, but it should include virtually every 'supported' configuration out there, including scenarios where you've used one of our Whitepapers to move SharePoint off of the AT, enable SQL clustering or mirroring on your DT, or upgraded your Whidbey TFS to use WSS 3.0. You should not have to upgrade from Whidbey RTM to SP1 before upgrading to Orcas, for example (though upgrading to SP1 is strongly recommended in the meantime).
• When I say "should", well, that's one reason Beta 2 is so interesting to us. We've tested a lot of scenarios on a lot of configurations, but we really need/want to see customers trying upgrade with Beta 2 to validate the work and find any scenarios or edge cases that we've missed. 
• Finally, note that "Upgrade" is a very specific scenario - upgrade of TFS itself. If you also want to upgrade WSS from 2 to 3, that's a separate operation. If you want to move from single- to dual-server, or from standard SQL to clustered or mirrored, those are other, separate operations.
• More deployment flexibility: This is sort of a bucket for a variety of improvements, mostly based on feedback on our requirements for Whidbey.
• SharePoint flexibility - see the previous post for more details.
• TFS's website can now run as Network Service.
• While I don't recommend this as a security Best Practice, some organizations either don't allow domain accounts dedicated for services, or have restrictive policies/procedures around creating and maintaining them. If your TFS server does not have other potentially vulnerable services running as Network Service on it, this may be an attractive option.
• Note that who SQL, SQL RS, and WSS run as are still subject to the requirements and recommendations of those components, so you may not be totally out of the woods on service accounts.
• Compatibility/Side-by-Side: You may already know this, but 'major' versions of Visual Studio are expected to operate 'side by side' with each other on the same machine; and Visual Studio (the client) does not "upgrade" from one version to another (for the side-by-side reason among others).
• The story is a bit different for Team Foundation Server. We don't expect the Orcas version of TFS to run "side by side" with the Whidbey version of the server (and it just plain wouldn't work for both versions to share a data tier). However, with a few notable exceptions, either version of the client (Whidbey and Orcas) can talk to either version of the server, and the clients can be installed side-by-side as described above.
• The Version Control Proxy should support the full compatibility mix (and has had a fair amount of testing to demonstrate this) - that is, either version of the proxy can be between any combination of Orcas/Whidbey clients/servers. There is at least one change to the format of the Proxy config file, however, so be careful about just copy/pasting your Proxy config file if you're doing an 'in place' upgrade of the proxy (uninstall the old proxy, install the new proxy).
• Team Build's version should match the TFS version. There's at least some capability if you keep a Whidbey Team Build server paired to an Orcas TFS, but I'm told it's limited.

Wow, that's a lot to catch up on (and I'm sure I'm forgetting something). If you're interested in these areas and have questions or feedback, please send them my (or our) way.

I'll try to do better as we hear more Beta1 feedback and prepare for Beta2; and now that those little details about buying, selling, and moving between houses are over and done with, I should have a few more cycles to blog with :).

Take me out; out of darkness, out of doubt

We're working on improving our SharePoint integration for the Orcas release of TFS, as you may have heard/read by now.

I've been pretty busy lately on the setup-, admin-, and ops-related aspects of this work, and I thought you might like to hear some of the details. The usual disclaimer applies - this is my view on where things are right now; a lot can change between now and release.

The changes fall into several somewhat distinct improvements:

1. Support for WSS 3.0, and continued support for WSS 2.0
2. Formal support for using a WSS instance/farm installed somewhere other than the TFS Application Tier
3. Increased 'agnosticism' for how your WSS instance is configured

I'll add a few more details for each of these, but it will quickly get boring to those uninterested in a given feature, so I'll try to keep it short. I have one question I'll save for the end, as well.

Support for WSS 3.0

There isn't much more to this than the obvious. The setup-related details are a little interesting though. For a 'clean' Orcas install, you can elect to let us install ALL of WSS 3.0 for you - hopefully that's exciting for those of you who like TFS but don't really care about WSS's details (beyond that it's there and it works). We'll install the required prerequisite (WinFx 3.0/3.5), install WSS 3.0 itself, and configure it in a way that we can use. Note that if you choose this option, we'll still put WSS 3.0 on the TFS Application Tier, and use the SQL server used for the data tier (single- or dual-server configuration).

WSS on another machine

Dan Kershaw published a whitepaper describing how to move WSS "off the box" for Whidbey (Visual Studio 2005). We're making this a good bit easier for Orcas.

• For a clean install, just tell us where your WSS instance is (namely, the admin and site URLs), and we'll use it. If it's not on the TFS App Tier, we have a separate 'mini' setup you'll run on that instance, to configure it for TFS and upload the templates used during Team Project creation.
• If you're upgrading from Whidbey, you'll still have to tell us to update the SharePoint location. But, we're aiming for a command or commands that will greatly simplify things (to where it doesn't require its own Whitepaper, at least :)).

Note that in either case, the 'new' WSS instance can be WSS 3.0 or 2.0.

Agnostic to WSS configuration

This is the part that might be "boring" to a lot of you. But, if your organization has an existing WSS deployment that you want TFS to use, this will hopefully be good news to you. While we had good reasons for being picky about how WSS 2.0 was configured before, there's been a lot of requests to relax those restrictions along with the changes above. So, starting with Orcas, you should be able to give us a WSS instance that you've configured yourself. We won't require the WSS databases to have a particular name or location. We won't require the app pool to have a certain name. We still have a few requirements, of course:

• Users that need to create team projects will (still) need to be SharePoint instance (farm) administrators.
• TFS users (in general) will still need access to the TFS site in order to access TFS documents stored in SharePoint.
• The TFS setup user will still need administrative access to WSS during the TFS install/upgrade. This access (as far as I know) won't need to persist after the setup completes, though.

There may be other details, but hopefully that illustrates what we're changing.

Now, for my question: How many folks out there anticipate that they'll still be using WSS 2.0, given the option to move to WSS 3.0? I'm sure there will be some (their org just won't be able to upgrade to 3.0 yet, and they'll want to use the org's WSS deployment rather than continue having TFS use its own 'private' WSS instance), but I'm curious if the 2.0 set is "a few" or "a lot".

A related question, of course, is "how many of you care about this kind of detail?" If a lot of you could care less how TFS handles its WSS needs, that's also good data.

Suddenly I see...