Freigeben über

TFS - Enhanced support for Windows SharePoint Services

  • Artikel

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

Comments

  • Anonymous
    February 14, 2007
    We care. :) "Users that need to create team projects will (still) need to be SharePoint instance (farm) administrators." I assume this is because TFS will want to create site collections for the TFS sites? Is there any chance this could be configurable so that TFS can either create site collections or instead can create subsites of a pre-defined site collection? It'd sure be nice to use some of the cross-site query stuff in WSS v3 with TFS sites, and that could only be done if TFS sites are subsites, not site collections. I haven't checked Project Server 2007, but in Project Server 2003, it wanted to create site collections instead of sub-sites, too. If the TFS WSS 'stuff' was created as a Feature, TFS wouldn't even need to create a new site, it could be added to an existing site. This would be really nice to avoid the multiple-sites-per-project syndrome that occurred with TFS 1.0 and Project Server 2003. We ended up with 3 sites per project, one for TFS, one for PS, and one for collaboration.

  • Anonymous
    February 14, 2007
    You assume correctly. The changes you suggest (being more flexible in how we deal with WSS sites and how they relate to Team Projects) are being considered/debated/etc. by the 'powers that be' - but I can't say yet what the result will be. We want to make Team Projects more manageable in the future, and that includes making how each site's SharePoint integration is created and managed better. However, I (personally) doubt this part of our WSS story will change for Orcas.

  • Anonymous
    February 15, 2007
    I'm pretty sure I'll move to 3.0 when it's available to work with TFS. A more detailed separation will be better for our organization. Good news !! Thanks ..

  • Anonymous
    February 15, 2007
    The comment has been removed

  • Anonymous
    February 15, 2007
    The comment has been removed

  • Anonymous
    February 15, 2007
    "However, I (personally) doubt this part of our WSS story will change for Orcas." Knowing what the API's are like for programmatically creating sites fairly intimately (having written tools and workflows to do it), I don't see why this is such a major proposition. There would be a slight difference in what method is called, but once the web is created (whether it's a new site or a subweb of an existing site), the web service andor OM calls to get at the web and manipulate documents, etc. are the same. Seems like a pretty small set of things to manage in a confined context (creating the site in the first place) for such a potentially large payoff (all TFS sites in one site collection). If TFS didn't support it as a configuration option but would let you change the url for the TFS web after the fact to point to any valid TFS web, whether a top-level site's web or a subweb, that'd be nice too. Admins could move them to at least accomplish the goal of keeping TFS webs in a single site collection. My $0.02.

  • Anonymous
    February 15, 2007
    For Whidbey, I think (part of) the reasoning was a desire to keep the backup story (across TFS - not just WSS) manageable, though I don't know (I wasn't involved with the WSS aspects at the time). I'll pass your comments (and the implicit) request on to the team. My perception is that it's a risk/schedule issue more than a "size of workload" issue. As I said earlier, we're definitely looking at making these experiences better and better over time.

  • Anonymous
    February 19, 2007
    Chris Rathjen on TFS - Enhanced support for Windows Sharepoint Services . Rob Caron on SharePoint...

  • Anonymous
    February 25, 2007
    http://www.microsoft.com/technet/windowsserver/sharepoint/wssapps/templates/default.mspx Application

  • Anonymous
    February 26, 2007
    The comment has been removed

  • Anonymous
    February 28, 2007
    I'm not sure the exact change/feature you're requesting will be in Orcas. However, last I checked, we plan on letting the TFS site's port change (instead of defaulting to 8080). That work MAY enable the scenario you describe, but I don't know the story first-hand. Stay tuned, though - I'll poke around more on this subject and address it in a future post.

  • Anonymous
    February 28, 2007
    Ok, thanks. But simply changing the port was possible in VS2005 already. For deployments behind a firewall with lots of access of remote users it would be very, very handy if all communications between clients and the server would go via one IIS site, which hosts both WSS and TFS. Of course the WSS admin site would still need to be extra, but still.

  • Anonymous
    February 28, 2007
    Maybe the work I'm thinking of does combine the sites, then. I'll investigate.

  • Anonymous
    March 20, 2007
    Do you have any clues on projected release dates for the WSS 3 TFS product?

  • Anonymous
    March 20, 2007
    WSS 3 has shipped (http://www.microsoft.com/downloads/details.aspx?familyid=D51730B5-48FC-4CA2-B454-8DC2CAF93951&displaylang=en). I don't know of any dates (projected or otherwise) for the Orcas release of TFS, though; sorry.

  • Anonymous
    May 22, 2007
    So...I haven't exactly been blogging lately. This is (mostly) a "no news is good news thing" - what have