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