Chris Rathjen

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

James tagged me - I guess it was only a matter of time. Being the avid Snow Crash fan that I am, I feel like I'm propagating a virus...

gen(n-1) tag: James

Five Things You Didn't Know About Me

1. In the same vein (no pun intended) as James', I was quite accident-prone as a child, such that it's somewhat miraculous that I survived this long. At least a half-dozen trips to the ER, at least 3 concussions; perhaps unsurprisingly, I have trouble remembering exactly how many head injuries I've suffered. Most of you don't know this, but those who learn frequently remark that "explains so much" about my personality - I really WAS dropped on my head a bunch as a kid. Sadly, it was mostly my own doing! :)
2. In 5th (or 6th? See #1) grade, I got separated from my school tour group while visiting Colonial Williamsburg. It was a defining moment for me - where previously I would have panicked, cried, and basically waited for someone to help me, I (somewhat spontaneously) decided I was going to get myself out of trouble this time. I explored virtually the whole area, asked for directions, even climbed a wall, got sunburnt, but finally found the group more or less on my own. While in hindsight, I would probably have "been found" sooner, the determination to act, rather than be victimized, has stuck with me ever since. Particularly in cases where I get myself into a jam - my single-minded fascination with a firearms display is what let the group leave at least 15 minutes before I noticed.
3. I can't decide what "mature" really means. When I was a teenager, I thought it was being independent. Since I've fallen in love and gotten in married, right now I think a big part of it is having things (people in particular, but perhaps causes as well) that you care about more than yourself; I wonder if the definition will continue to refine (I won't say change - I do still value my ability act independently when appropriate) over time, whether it's a natural function of age, or merely another of my (many) quirks.
4. I like being wrong more than being right. Many who know me will think I've just hit my head again, but it's true. I'd much rather advance an idea or belief about something and have it debated - even proved wrong - than blindly accepted as accurate/correct/gospel/etc. Why? Because I learn a lot from the debate, or the correction. Finding out I'm right about something is nice but not nearly as satisifying. I guess I'm saying that I love to learn.
5. My birthday is on (what is often) the shortest day of the year (in the Northern Hemisphere) - December 21st. Again, upon learning this, many people find this to be entirely appropriate.

Now, whom shall I tag? I must admit my "blog circle" is rather limited - many of those I'd like to tag have already been tagged in previous generations.

gen(n+1) tags:

I'll pick Josh, Korby, Joel, Jason, and Hans of BugBash. I'm not sure if any of them will notice, but I've always liked reading what they have to say and it'd be nice to know a few things I don't know about them...

Dan Kershaw has produced (and updated) a whitepaper for folks who don't want their TFS AppTier and SharePoint servers on the same machine.

Unfortunately, the doc seems to have moved since most of the links out there were created. As of right now, it's located here: http://msdn2.microsoft.com/en-us/teamsystem/aa718901.aspx

Warning: I'll quote Brian's post on the original link - this process is NOT simple: "The instructions are neither simple nor short.  I really don't recommend doing it unless you are ready to pull your hair out for a day or two getting all of the configuration pieces in place.  The simplest way to think of it is that TFS V1 does not support it but future versions will.  However, some of you are brave souls, undaunted by challenging problems.  For you fearless few, this article should provide you the information you need to configure TFS and SharePoint.

Good luck :)"

I'll also repeat Brian's comment that we'll have a better mechanism for this in a future release - the whitepaper is for those who just can't wait.

This is the time, this is the place...

I haven't been posting much lately. The reasons are very much "no news is good news", though, not an ominous silence.

The AdminOps team is "heads-down", so we can get some key improvements for TFS done and polished in the timeframe we've set for ourselves. Adam (referred to in the office variously as "Adam2" and "Fists of Fury", for reasons that shall remain a mystery to the public) is testing improvements to the way we sync user/group information. I'm testing enhancements and additions to the TFS setup experience.

The other good news is that we recently got some reinforcements, so the AdminOps QA team is no longer an 'Army of Two' - now we're more like the Four Horsemen. Hmm, that's back to ominous. Perhaps the Fantastic Four? Bug Clobberin' Time is coming up Real Soon Now...

That's the name of the game

James recently posted more details on our ISAPI filter and how it enables access to TFS in common extranet scenarios.

I'm very interested in feedback and suggestions on this feature. We want to know if it helps you, or if not, what it's lacking or what could be improved / changed to support your needs.

Among the "yeah, we already know that's a problem" issues:

1. No IPv6 support
2. Inadequate diagnostics (need more event log events, events need to be localized)

Anything else we can do to make the filter better? I obviously can't speak to exactly when we'll have these improvements, but we're definitely working on it...

Rock and Roll ain't noise pollution...