I'd like to tip my hat to the father of a guy I worked with as a camp counselor one summer long ago for the post title. He owned a demolition company called "Edifice Wrecks".

In our last episode, I described the OSes that the various Team Foundation features support. This time, I'd like to cover what other software components you need to install, and how you can best do so. As before, I'll be making copious references to the Team Foundation Install Guide so I recommend you download it to play along at home.

• Application Tier and Proxy: Both of these components require IIS 6 with ASP.NET, or, if you're on Longhorn Server, IIS 7 must have IIS 6 Compatibility, ASP.NET, HTTP Redirection, and Windows Authentication installed. I usually install it through Add/Remove Programs (Windows Server 2003) or Server Manager (Longhorn Server). Specific instructions for each OS can be found on the install pages "How to: Install Internet Information Services 6.0 on Windows Server 2003" and "How to: Install Internet Information Services 7.0 on Windows Server 2008".
• The Application Tier also requires SQL Server. You can use either SQL Server 2005 or certain versions of SQL Server 2008. Since the latter still hasn't released yet and changes in CTPs have broken TFS functionality, I strongly recommend using SQL Server 2005 SP1 or SP2 for production installs of TFS. There are separate instruction pages for each of SQL Server 2005 and SQL Server 2008 on Windows 2003 and Longhorn Server, so I won't list them all out here. They're children of the "Prerequisites for Team Foundation Server" topic in your install guide. To sum the up, though, I'll say the following. You need the SQL Database Engine, Analysis Services, and Reporting Services. Workstation components are very useful for troubleshooting, so I'd recommend them as well. If you want to mix and match instances, things get a little bit harrier- I'll address that in a separate post. Besides that, the simplest install is to take the defaults for SQL Server 2005, using either Local System or a domain account as your SQL service account. Note- this is not the Reporting Service account, but rather the SQL Database engine account. Reporting Services should be run as Network Service, and using the selection "Install the default configuration" on the Reporting Services options page will do this for you.
• The Application Tier requires SharePoint, as well. If you don't yet have an install of SharePoint on your corporate network, the simplest path is to just let the AT install and configure SharePoint for you. If you want to install SharePoint on a machine other than you TFS Application Tier, however, you should very, very carefully read and follow the page "How to: Install SharePoint Products and Technologies on Windows Server". Make sure to follow the steps all the way through to configure the SharePoint sites. One thing I will add to the install guide is that if you want to extend the existing site on port 80 instead of creating a new one you must set the "Description" to the existing web site name (e.g. "Default Web Site") in step 17. If you don't do so, it will disable the existing site and create a new one with just SharePoint components.
• Team Build: Team Build as a server doesn't have any particular prerequisites. However, in order for it to be able to run coverage analysis, or run tests you must install the appropriate SKU. For running tests, you need Visual Studio Team Edition for Testers or Visual Studio Team Suite. For coverage analysis, you need Visual Studio Team Edition for Developers or Visual Studio Team Suite.
• Team Explorer doesn't have any other software prerequisites. It installs all the necessary Visual Studio shell components to host itself and stand on its own.
• SharePoint Extensions: The only prerequisite for our SharePoint Extenstions feature is that SharePoint be installed. As I mentioned in my previous post, we currently only support 32-bit SharePoint installed, but are actively working on a power tool for 64-bit.
• Team System Web Access: The system requirements documentation for TSWA is currently online, but not in the TFS Install guide. You need to install IIS 6.0 or 7.0 with ASP.NET, the .NET 2.0 Framework, and Team Explorer.

Next, we'll take a closer look at SQL Server and its various components (that sounds like a rock band, doesn't it, Dave Barry?). See you then!

I've seen a bunch of questions over time about what it takes to get Team Foundation Server (TFS) components installed. Because it varies by component, the answer is usually rather lengthy and takes long enough to fully describe that eyes start glazing over, heads start nodding, and the utility of the information is basically reduces to a (very) small hill of beans. So, over the next few posts I'll review specific prerequisites (a.k.a. "prereqs" to their friends) for the TFS components. I'll be refering to the Team Foundation Install Guide left, right, top, bottom, and center (possibly front and back, too, but don't hold your breath), so I recommend you download it so you can play along at home. Also, it's pretty useful in its own right.

Today, we start with the all important operating system. I'm going to gloss over the hardware requirements since they're all listed on the pages I reference. If you're interested, feel free to read up on it at the source. Each TFS component has its own specifications for what it can and cannot be installed over, so we'll break them down by categories:

• Application Tier and Proxy: These two SKUs can only be install on 32-bit OSes in the VS2008 release. In addition, they require a "server" OS - Windows Server 2003 or Longhorn Server. For Windows Server 2003, we require at least SP1. All 2003 Editions other than the Web Edition are supported. For a complete list, check out the "System Requirements for Team Foundation Server" section of your install guide. The Proxy page ("System Requirements for Team Foundation Server Proxy") starts out by saying "The software requirements for Team Foundation Server Proxy are the same as for Team Foundation Server" so you can just look at the first page to get the list of OSes you can play with.
  
• Team Build is a different story. It can be installed on 32- or 64-bit systems. On the latter, it will run in WOW64 mod since it's actually a 32-bit application. The install guide page doesn't give you an exhaustive list, but rather refers to the Visual Studio 2008 Readme with some modifications. As with the Application Tier and Proxy, we require at least SP1 or R2 on Windows Server 2003 and only support Standard and Enterprise Edition. On XP, we require at least SP2 and it must be Professional. For Vista, we support Home Premium, Business, Enterprise, or Ultimate Edition. They don't mention Longhorn Server on the "System Requirements for Team Foundation Build" Install guide page, but I can't imagine why it wouldn't be supported. I'll find out about that.
  
• Team Explorer also references the Visual Studio requirements, but doesn't specify any exceptions like Team Build has. As with Team Build, it will run in WOW64 mode if installed on a 64-bit OS. See the "System Requirements and Additional Client Software for Team Explorer" page for more detail.
  
• TFS Databases can be installed on a 64-bit machine only if you use the "dual server" deployment where the Application Tier resides on a different machine from the SQL instance with the TFS databases. In addition to the OSes listed in the Application Tier's requirements page, you can find the 64-bit OSes the databases supports on the page titled "64-Bit Support in Team Foundation".
  
• Remote SharePoint: If you choose not to install SharePoint on your Application Tier, it can be installed on any OS supported by SharePoint, with some caveats. Currently, our TFS "SharePoint Extensions" SKU doesn't like 64-bit OSes. As Jason mentioned, we're working on a Power Tool to rectify that and will post more when it's available. Otherwise, for 32-bit OSes, see the Install Guide page "How to: Install Windows SharePoint Services Extensions for Team Foundation Server" on how to upload the appropriate templates and redirectors to make SharePoint and Team Foundation Server friends.
  
• Team System Web Access: According to the Power Tool download page, TSWA only supports Windows Server 2003. As TSWA is incorporated into the main line components for the next version I'm sure we'll see more information on its support.

I hope there aren't too many nodding heads and glazed eyes- it's very tough to condense all of this down, especially when you enjoy words as much as I do. Next time we'll investigate what other software must be installed prior to TFS. Stay tuned!

As a follow up to my explication on the various TFS Editions and a few thread I saw on the Visual Studio Team System forums (including Upgrading TFS 2008 Workgroup to Std. Edition - then TF50626), I'd like to point out something about the upgrade from Workgroup Edition to Full Edition.

When you're running Workgroup Edition, users need to be added to the Team Foundation Licensed Users group in order to connect to the server. However, the Full Edition doesn't have this restriction and in fact doesn't use the Licensed Users group to limit server access. What confused folks it that the upgrade doesn't remove the group. In fact, due to the way our group membership logic was coded the group still has a maximum membership of 5 users!

The best way to make sure that your upgrade succeeded is to actually remove a user from the Licensed Users group, add that user to a different TFS security group, and make sure the user can still connect to the server. If that works, you should be able to just ignore the Licensed Users group.

I'll follow up with my team to see if we can get this group removed on upgrade to help avoid confusion in the future.

With Team Foundation 2008 generally available, I've seen a bit of confusion over the various Editions offered. Of course, there's still a bit of confusion over how "Workgroup Edition" relates to workgroup networks, but there's also some missing clarity around the upgrade paths, the restrictions, etc. Hopefully this simple guide will help make the Edition story a little less obtuse.

Believe it or not, we have four Editions, or so they tell me.

1. Trial Edition
2. Workgroup Edition
3. Retail Edition
4. Volume License Edition

For all intents and purposes, 3 and 4 are the same. The only difference is how you obtained them, and whether you have to fill in the PID yourself or if it's already filled in. Both are fully functional and should have no timebomb or user limit restrictions.

The Trial Edition has a 90 day timebomb, but is otherwise fully functional.

The Workgroup Edition has nothing to do with domain versus workgroup network deployments. Rather, it's a version you get with an MSDN subscription that has a five user limit. It's my understanding that it may only be installed in a "single server" configuration.

Supported upgrade paths are from Trial to Workgroup, Trial to Retail or Volume License, and from Workgroup to Retail or Volume License. Brian Harry has a great post on how to upgrade.

 I hope that helps- if not, let me know and I'll see what other information I can dig up!

As I mentioned in a previous post, our program manager Sudhir is blogging up a storm on all the great new features in Orcas, including remote Analysis Services and Sharepoint. You can also use pre-installed and configured Sharepoint instances, if your company already has one set up. Brian Harry recently posted the final TFS 2008 feature list, and I'm very pleased to say that you can also use a remote Reporting Services instance in the final version! Note that this was not available in time for Beta2, unfortunately. We still need to have some SQL assemblies on the application tier during setup so we can use the API, but that can be acheived by just installing the workstation components.

Having played around with remote capabilities a bit, I must say that I'm really pleased with the update. I've seen many requests for it on the forums and so believe you'll be pleased with it as well. In any case, I wanted to let you know a bit about how to set up our install to use a remote SQL Server Reporting Services (SSRS). It's very similar to our Analysis Services Flexibility. You'll have to copy the installation folder onto a local disk from the media where you can edit the msiproperty.ini file.

1. Open the MSIProperty.ini file located under InstallMedia\AT directory
2. Change VSTF_RS_SERVER property to indicate the machine that the Reporting Services resides on.
3. If you Report Manager virtual direrctory is located at a different path than the default http://[reportserver]/Reports, set the VSTF_RS_REPORTS_URI to point to the correct location.
4. If your Report Server virtual directory is located at a path than the default http://[reportserver]/ReportServer, set the VSTF_RS_REPORTSERVER_URI to point to the correct location.

Note that you may have to open some firewall ports on the remote SSRS machine for our installation to complete successfully.

Happy installing, and please do let me know what your experiences are with remote components, good, bad, or ugly!

The other day, someone not in the computer related fields asked me an interesting question. He wanted to know what I think the difference is between the human brain and a computer. Now, it's been a long time since I took biology, but I believe I remember most of it.

The first thing that jumped into my mind is that all of the parts of the human brain are neurons which happen to be specialized for one purpose or another. When you get right down to it, they're really all the same type of cell that just happens to be versatile enough to do everything from storing memories to guiding motor functions, from sorting and analyzing sensory input to performing complex computations.

In a computer, however, ever piece is highly specialized by design. We couldn't very well put a harddrive in where the CPU is supposed to be, or RAM in the place of a network card. Perhaps if we break everything down small enough we could claim that the parts all have the same sorts of roots, but the a capacitor functions very differently from a NAND gate.

Putting these thoughts in order, I decided that what I see as the main difference between the human brain and a computer is that the human brain has multiple orders of magnitude greater adaptability. A computer, in the meantime, is only as smart as the people who designed it and programmed the software that exercises the hardware. We might even add in the end user here since they might not exercise the full capabilities or may do something to further restrict the computer's capabilities (like not plug in the ethernet cable, disable certain settings, install unknown software, etc).

In summary, while my opinion of the human mind's potential is very high, I don't see computers as having the same capabilities. Perhaps some day we'll be able to decouple "computers" from any particular physical media and thus give them the ability to incorporate whatever components they need to perform a specific function at a given time. Still, the computers will only be as smart (or as dumb) as their programmers. As the poster on my wall reminds me daily, "Never underestimate the power of stupid people in large groups."

I'm still alive! Yes, I know you all agree that's great news. At least, I think it's great news so will classify it as such here in my blog.

First, a bit of business:

Come chat with the Visual Studio Team System product team – This Wednesday

 

Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new in Beta 2.

 

We will be holding two sessions:

 

Join the chat on Wednesday, August 1^st, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

            -or-

Join the chat on Wednesday, August 1^st, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

Now for something on a more specific and on-the-front-lines style.

Orcas Beta 2 has been out for awhile now, and with it a lovely improvement that I think will make Team Foundation administrators jump for joy, throwing confetti and streamers all the way. Hey, it's still my blog and I can imagine what I want to.

In Whidbey, syncing users from Active Directory to TFS happened due to three conditions but really only two conditions. This was fixed in Orcas as part of the Sync Large Groups feature crew. As such, you can now take advantage of the ability to modify the periodic AD/GSS sync period. To do so, you need to manually modify a Web.config file on the Application Tier that by deafult will appear under the folder "%PROGRAMFILES%\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\services". DISCLAIMER: I do not guarrantee that this will not cause your computer to eat all of the data it has ever come into contact with, possible with fire. This confers no warranties and no rights, your mileage may vary, use at  your own risk, void where prohibited, etc. [Note: still my blog].

You'll need to add the following two lines to the key/value pair section at the top of this file, followed by resetting IIS to make sure our application pool picks up the changes:

<add key="IdentityUpdatePeriod" value="01:00:00" />
<add key="IdentityUpdateInitial" value="01:00:00" />

Note that I've set both the initial update (i.e. the delay after startup that the first periodic sync happens) and the delay between periodic syncs to 1 hour. You can increase this to multiple hours, or decrease it to a matter of minutes. Be very careful when reducing the time as forcing the sync to happen too frequently will likely decrease the overall performance/throughput of your Team Foundation Server due to the multiple connections to your domain controllers that a sync opens as well as the processing that it kicks off in the SQL Server to update the cache.

Well, there you have it. Administrators spontaneously breaking out in song, bluebirds and rainbows for everyone, and a bright smiling sun grinning at us from behind fluffy white clouds. That last part sounds somehow like Super Mario Brothers, and this frightens me.

This week, we have one of our User Education ("UE") folks out visiting the North Carolina office. We're talking about all manner of interesting documentation topics, including what we want to work on with respect to documentation for future versions. After spending a bit of time scratching my head and trying to come up with answers I realized that I don't have to come up with ideas all by myself. After all, any of you out there who have experience using and reading our online documentation certainly have at least as much of an idea what may be needed or what else you'd like to read.

With that in mind, I'd like to make an open call to all users of TFS to comment here or use the "Email" link on my blog to pass along your thoughts. What documentation changes would you like to see? What documentation have you found most helpful? Where can we improve? Any other thoughts?

Recently, in part because of such interesting capabilities as Sudhir mentions in his post on Analysis Services Flexibility, we had an e-mail discussion about the msiproperty.ini file. As such discussions are wont to do, this one became somewhat humorous. I decided to reply back at one point with famous quotes, replacing key words with others related to the topic on hand. Here's what I came up with:

Movies

Matrix: “There is no msiproperty.ini file.”

Blazing Saddles: “Msiproperty.ini file?! We don’t need no stinkin’ msiproperty.ini file!”

Star Wars: “You have strong feelings for them, especially for… msiproperty.ini file. He was wise to hide it from me. Yes… now Obi Wan’s failure is complete.”

A Few Good Men: “You want the msiproperty.ini file? You can’t handle the msiproperty.ini file!”

 

Adages

“An msiproperty.ini file on the hard disk is worth two in the install media.”

“An msiproperty.ini file in time saves nine.” (but nine what?)

“The setup is always easier on the other side of the msiproperty.ini file.”

 

Games

Gauntlet Legends: “Green programmer needs msiproperty.ini file badly.”

Soul Caliber: “Msiproperty.ini file was seriously wounded, but the setup.exe still burns.”

Zero Wing: “All you msiproperty.ini file are belong to us.”

 

I think I just jumped the shark with that one…

One of my coworkers came by and told me that I hadn't jumped the shark- I'd jumped the msiproperty.ini file.

I've heard a few questions and comments about our permission model recently. For example, some folks have asked why user in two groups, one granted a permission and one denied the same permission, is denied the permission rather than granted it. The answer lies in our permissioning model.

Lets first define a few terms to get us all on the same page. Note that these are not necessarily official terms, they're just the terms I've used when discussing permissions with folks on the team here:

• Identity: A user or group that may be used with the permission system. Groups are both external groups (e.g. active directory security groups) and TFS groups (e.g. [SERVER]\Team Foundation Administrators) 
• Securable object: An item in Team Foundation which may have permission rights granted or denied to perform certain operations with the object. Examples are the folders and files stored in Version Control, Area nodes, Projects, and the Team Foundation Server itself.
• Explicit vs. Implicit: An explicit perimission for a given identity is assigned directly to that identity, while an implicit permission is assigned to a group the identity is a member of (either direct membership or through nested membership)
• Inherited vs. Immediate: While Team Foundation Server global and project permissions don't have a notion of inheritence, permissions on items stored in Version Control do. An inherited permission is assigned to one of the parents of a given securable object, while an immediate permission is set on the securable object itself.

Overall, we follow the same permissioning scheme as the Windows OS. A permission may be allowed, denied, or unset. Unless a permission is allowed (explicitly or implicitly, through inheritence or immediately on the securable object), the permission is denied. The only exception is for Administrator users who are always granted permissions (for Version Control, admin users are users who are Machine Administrators on the AT). Hence, if you don't want users to be able to be able to perform a given action, simply don't grant them permission to do so and don't add them to a group that's been granted that permission.

From that notion comes the title of this post- keep your permission set as minimal as possible, and you won't run into situations where a user is a member of 27 groups, half of which are granted some set of permissions, half of which are denied some overlapping set, and all of which cause your head to spin.

Now, that's not to say that you shouldn't set permissions on objects. Certain permissions are necessary to use the system in a reasonable way. Just remember that as soon as a user is denied a permision, whether explicitly or implicitly and whether the permission is inherited or immediate, no amount of grants at any level to any group will override the deny setting. Denied permissions are the trump card and should be used to specifically lock resources and components. Since all denies trump all allows aside from administrator status, users may be unable to perform actions if they're in two groups that have different permission settings.

Let's walk through a simple example. Suppose you have four different groups- developers, testers, contractor developers, and contractor testers. Due to corporate policy, contractor developers may be disallowed from directly checking in changes and locking files, while contractor testers may be disallowed from viewing the developer source code. Lets also suppose that the two contractor groups have been added to the other two groups (contractor developers to developers and contractor testers to testers). If your product code resides under the Version Control path $/AcmeCode/Product/, you could set permissions on the folder as follows:

1. allow the "developers" group read, label, lock, pendchange, and checkin access
2. deny the "contract developers" group checkin and lock access
3. allow the "testers" group read access
4. deny the "contract testers" group read access

All other permissions (e.g. "Undo other users changes") are unset for all four of these groups, so are treated as denied permissions unless the users are members of other groups. This permission set will completely lock out the "contract testers" group from that version control path, while the "contract developers" can read, label, and pend changes which they will then shelve to have a full developer check in.

An alternate method would be to make the developers group a member of the contractor developers group (and not vice versa, only granting the "contractor developers" read, label, and pendchange permission while adding the lock and checkin permissions to the developer group. Of course, this seems a little weird from the perspective of someone looking at group containment and could therefore get confusing.

So, that's a little long winded, but I hope it gets the point across and helps you make informed decisions about what our permissions mean.

Another Team System chat is on the way! You've got questions? We've got answers - I just hope they match.

Visual Studio Team System Chat – April 27th

Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers. In addition, discuss what's new in the upcoming Orcas Beta.

Join the chat on Friday, April 27th, 2007 from 10:00am - 11:00am Pacific Time.

Add to Calendar
Additional Time Zones

As Rob Caron posted, there's a new Microsoft Visual Studio Team System Licensing white paper. Now, I'm not a lawyer, but I could follow what it's saying and think it's much clearer than the previous version (and even that one basically made sense to me). Here's a few tidbits based on the common questions I've seen on the forums:

• Team System client products are licensed according to the Microsoft Developer Tools licensing model, which licenses products on a per user basis and each licensed user may install and use the software as many times as they wish on their devices. However, a license for each product is required for each user who uses it on those devices.
• When you purchase a Team System client product, you also receive a CAL (Client Access License) for Team Foundation Server. You may purchase additional CALs for users who are not licensed users of these client products.
• Team Foundation Server Workgroup Edition contains all of the same features as Team Foundation Server, but its use is limited to five (5) named user accounts... Team Foundation Server uses SQL Server 2005 as its data repository. A restricted-use version of SQL Server Standard Edition is included with Team Foundation Server, which is installed separately.
• You do not need a Team Foundation Server CAL for:
1. Any device running another licensed copy of the server software
2. Up to two devices or users that only access the server software to administer it.
• Hardware or software that reduces the number of devices or users that directly access the server software (sometimes referred to as “multiplexing” or “pooling”) does not reduce the number of CALs you need.

On that last point- generally the two devices/users are your service account and reporting service account. The former will have administrative TFS privileges by default (due to the nature of the operations it performs), while the latter basically gets read-only access.

Hope this helps! If you have any questions, I may not be the best person to answer but can certainly try to find out what you want to know.

As with many of my other Administration and Operations posts, this one stems from posts I've seen on the Visual Studio Team System forums. I've read a number of questions where people are having trouble granting 0their Active Directory users access to their Team Foundation Server.

What I've found is that, oftentimes, this is due to either the trust relationships between their domains or the permissions for the account currently running as the TFS service account. In the latter case, this may be due to using a local account rather than AD account as the service account, AD permission settings, the "Log on as service" permission, or AD trust relationships (looping us back to the first possibility).

So, to help you figure this all out, I'm going to lay down The Word on what it is you need to set up in order to get AD users into TFS.

1. If you wish to use AD users, you must either:
• Create local accounts with the same user names and passwords as your AD accounts (and add them to a TFS group) if you want to use a local account as your TFS service account (or)
• Use an AD account for your TFS service account
2. In the second case, your TFS service account needs to have read access to objects in all domains you wish to add users from
• In short, this means the domain of the TFS service account must be trusted by all of the other domains you wish to use
• Also, users in those domains need to be granted the rights to read objects. This is the default, but some folks lock down their ADs so normal users can't read all other users/computers/etc. for their domain. If your domains are set up this way, you'll have to talk the domain admins into granting the permission to your service account explicitly.
3. No matter what your TFS service account is, it needs "Log on as a Service" permission. Two useful sites on how to set this permission are this forum post and our MSDN documentation.

Hopefully setting that up will let you add your domain users to TFS. If not, though, there may be fouler forces at work. Still, you'll probably want to take a look back at my other post on getting users into TFS entitled "Get your users for nothin' and your sync for free" as our periodic sync process is known to have issues in Whidbey (VSTS 2005) RTM and SP1.

Best of luck, and let me know if you hit any other stumbling blocks along the way!

[Edit: I should note that, from what I can recall of our stated support cases, we permit you to have as many two-way trusts as you like, but only claim to support one one-way trust where the TFS service account must be in the trusted domain.]

I've had this brewing in my head for awhile now and wanted to share it with you, my fellow netizens.

This stems in part from a philosophy course I took back during my undergraduate days called "Freedom and Responsibility". The basic question in the course was "do we have free will and, even if we don't, are we responsible for our actions?" My final paper was an analysis of the sentence "I have free will" and comprised two basic sections. First, to determine the truth or falsehood of the statement we have to define "free will" and what is necessary to be free willed. Next and this is even more important, we need to define who or what the "I" is that [believes it] has free will.

I proposed that the "I" part was more important because, no matter what free will ends up being, the subject of the sentence is the creature affected and through whose perspective the whole question is posed. Changing the "I" inherently affects the "free will", and so on.

You may ask why I'm bringing this up; does this have anything to do with Team Foundation Server? I'm so glad you [may have] asked.

 Indeed, the same sort of analysis can apply to the very term "Team Foundation Server", only in three parts. Let's work backwards.

What is the "server"? That's fairly straightforward, but has hidden complexities. In the simplest world, the server is the application tier, data tier, build machines, and proxy machines through which users access and manipulate "team foundation" objects (version control items, work items, work item queries, team builds, reports, team portals, etc.). Of course, if it were that simple, we wouldn't have so many questions about setup and server configurations on the Visual Studio Team System forums. Still, those questions are mostly technical and less theoretical in nature. In the interest of remaining somewhat philosophical, I'll defer those questions for a later time.

What is the "foundation"? Again, we can take the simplistic view that the foundation is merely a collection of tools (version control, work items, team builds, team portal, etc.). However, there's more to it than that. The foundation is more of a framework or an SDK due to the project templates, object model, and publicly accessible web services [N.B. I'm not advocating directly interfacing with the web services here- they are intentionally undocumented as the OM is expected to be the major entry point for extra plug-ins]. These access points allow people to modify processes, workflow, and even work item types and project definitions. A framework is supposed to have some degree of open ended behavior capabilities, and that's what we [hopefully] provide with the OM/template model for Team Projects.

Finally, which "team" are we talking about? What is a team? The way I see it, "team" is a many layered onion, if onions contained multiple sub-layers per layer (not that some don't - I cooked one just the other night that--- hmm, off track here). At the innermost layer, the team is a single person. Personally, I want to make sure to be thinking about what you, each and every individual using Team Foundation Server, need, want, and would benefit from on a daily basis. How can we help you be more productive? Around that is the group of folks including your direct coworkers and manager. I want you to be able to use TFS to tell what that team is doing, how it's measuring up, and what its priorities are from day to day. Beyond that may be your feature group or product unit or sales team or... any number of things, really. You should be able to use TFS to find out what's going on there, too. And up and up and up to the level of your whole company. How can you figure out what your company is doing? Where it's headed? Hopefully, the answer will be "Why, used Team Foundation Server's reports and queries, of course!" If not so today, then hopefully someday soon.

To me, as with "I have free will", the key aspect of "Team Foundation Server" is what I'll call the "subject" of the phrase. The "Team" should always be the focus of our efforts- how can we help your team, no matter how big or small it may be, get more done with less hassle and frustration? What does your team need day to day? What does it want? What could you benefit from that we haven't even dreamed up yet?

If you ever think of an answer to one of these questions, please feel free to send it my way and I'll see what I can do to help you out. I can't control or predict the future of the world let alone Team Foundation Server, but I may just be able to nudge it along a bit, and sometimes it's the butterfly flapping its wings that causes the storm.

Enough philosophy- next time we'll get back to good old reliable TFS functionality posts. Cheerio!

Following up from my last post "'Grep'ing Groups" and this question on the forums, here's a bit of code that will help you add a user to multiple groups across all projects on your server. Say you want to add someone with the domain account "CORPNET\JoeBlogs" to the "Readers" group for all your projects on your Team Foundation Server "atlantis". Simply download, build, and run the attached code with the arguments "atlantis CORPNET\JoeBlogs Readers" as a Team Foundation Adminstrator.

A few of the more salient points in the code are as follows:

NTAccount userAccount = new NTAccount(username);
...
SecurityIdentifier userSid = (SecurityIdentifier)userAccount.Translate(typeof(SecurityIdentifier));

Here, I'm using some of the System.Security.Principal .NET helpers to conver our user to a SID. While I could also use the IGroupSecurityService's "ReadIdentityFromSource" call, that includes a round-trip to the server and includes a bit more information than we need in this helper code.

ProjectInfo[] projects = css.ListProjects();

Here, I chose to use "ListProjects()" rather than "ListAllProjects()". The former only includes well formed projects while the latter will list all projects that are in the process of being created, being deleted, etc. as well. In this case, I think we only want to try to update projects that have been completely constructed.

Identity projectGroup = gss.ReadIdentity(SearchFactor.AccountName, String.Format("[{0}]\\{1}", project.Name, groupToUpdate), QueryMembership.Expanded);
...
List<string> members = new List<string>(projectGroup.Members);
if (!members.Contains(userSid.ToString())) {...}

Before attempting to add the user to the group, I want to make sure it's not already a member. I chose to query the extended membership rather than just direct as it wouldn't make a difference in terms of user permissions whether the user is a direct member or a member under a nested group. However, if you want to make sure that the user is a direct member of the specified groups, you could change the "QueryMemberhip" value to Direct. Changing the query to Direct will also speed up the ReadIdentity call, particularly if your groups have many members.

Happy coding!