Adam Singer : Team Foundation Setup Admin & Ops

Ventriloquism: TFS Style

Adam Singer — Mon, 28 Jul 2008 18:45:00 GMT

Quite a long time back, Buck posted about how to recover from the situation where one TFS machine is created as a clone from another. This can lead to clients still showing the project list for one server when the connect to the second. Based on a recent Visual Studio Team System forums question (they certainly seem to be inspirational to me these days), I decided to code up a very simple tool that connects to one or more TFS instances and spits out their GUIDs so you can check whether they were cloned from each other. The actual interesting block of code is as follows:

TeamFoundationServer tfs = new TeamFoundationServer(arg);
Console.WriteLine("The GUID for server '{0}' is:{1} {2}",
arg, Environment.NewLine, tfs.InstanceId);

As you can see, there isn't much to finding out the GUID of a server. I've attached the project in case you want to play around with it yourself. Nothing fancy- I even attempted to manually hack it back to a Visual Studio 2008 capable csproj file since I'm using a recent internal version of the next release. Enjoy!

Edifice Reqs II: The SQL

Adam Singer — Wed, 16 Jul 2008 16:00:00 GMT

Back in March, I posted about the requirements for TFS installation. I promised to post about "SQL Server and it's Various Components", but have been tied up with the Visual Studio 2008 SP1 like a Thanksgiving turkey (only not quite as delicious).

In any case, I'm back from outer space. I just blogged in to find you here... ahem. I'm getting side tracked with my song spoofs these days, apparently. Hey, they say blogs are supposed to be conversational, right?

SQL Server 2005 and SQL Server 2008 have quite a few subcomponents that Team Foundation Server requires. If you're installing TFS 2005, we require everything possible to be installed, running, and set for automatic startup. In TFS 2008, we investigated this requirement and determined there were several of these components and restrictions we didn't need. Depending on your desired configuration, there are different components you must have installed.

For all installs using SQL Server 2005, we require the SQL Database Engine ("SQL DB"), the SQL Analysis Services ("SQL AS"), and SQL Reporting Services ("SQL RS"). If all components are remote from the TFS Application Tier, you must install some SQL component on the AT so that we can use the SQL assemblies to talk with the remote components. The simplest way to achieve this is to install the "SQL Workstation Components". If you are using named instances of SQL DB, SQL AS, or SQL RS and don't want to use the port numbers to communicate with them, you should install the SQL Browser and set it to start up automatically. This will provide the hook TFS installation needs to find SQL components.

If you're using SQL Server 2008, please note that it's still pre-release. For TFS 2008 RTM, TFS was installable using the version of SQL Server 2008 that was available publicly at that time. TFS 2008 SP1 Beta is installable on the SQL Server 2008 February CTP (a.k.a. CTP6). Abdelhamid has a great post you might want to check out here that has the details on that score. For the TFS 2008 SP1 RTM release, we plan to support SQL Server 2008 RTM. At present, the components we require for SQL Server 2008 are the same as for SQL Server 2005. I don't anticipate that changing, but think it's important to add the qualifier in there just in case lightning strikes (twice) an alligator that's attacking a coin that landed on its edge.

My service is packed, I'm ready to go

Adam Singer — Wed, 09 Jul 2008 19:12:00 GMT

...installing here, upgrade once more
(Adapted from "Leaving on a Jet Plane")

A post on the Visual Studio Team System forums reminded me of one very important tidbit of Visual Studio patching. The integration of Team Foundation Server with Visual Studio enables all sorts of marvelous functionality and is great for development, but does place some restrictions on what patching scenarios are supported.

In particular, all Visual Studio derived products on the same machine must have the same service pack level. This includes Visual Studio Express SKUs, Visual Studio Standard, Professional, Team System (and the individual role SKUs), Team Foundation Server's Application Tier, Data Tier (only exists in TFS 2005), Team Build, Proxy, and Team Explorer. Since these components share common assemblies, if one tool has been upgraded to SP1 while another is still at RTM the functionality is undefined and unsupported.

The easiest way to check your SP level is look in the control panel Add/Remove Programs (on XP/Server 2003) or Programs and Features (on Vista/Sever 2008). For the former, check the "Show updates" button. On the latter, click the "View installed updates" link. There, you should be able to see which components have been updated and which haven't. If there's a mismatch, my recommendation is to reapply the Visual Studio and TFS service packs to bring everything back up to the latest SP. Of course, you can also uninstall the SP from everywhere that it's installed, but I would hope you'd want to get the latest and greatest functionality!

Best of luck, folks, and feel free to shoot along questions and comments if there's any other topics you want to see me address.

Edifice Reqs

Adam Singer — Fri, 07 Mar 2008 18:16:00 GMT

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!

Pre[ranasaurus] Reqs: The OSic Era

Adam Singer — Tue, 04 Mar 2008 21:37:00 GMT

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!

License to Nil

Adam Singer — Sun, 10 Feb 2008 07:54:00 GMT

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.

Supercalifragilisticexpialidociou-dition

Adam Singer — Tue, 05 Feb 2008 23:43:00 GMT

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.

Trial Edition
Workgroup Edition
Retail Edition
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!

Absence makes the install grow fonder

Adam Singer — Thu, 16 Aug 2007 18:15:00 GMT

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.

Open the MSIProperty.ini file located under InstallMedia\AT directory
Change VSTF_RS_SERVER property to indicate the machine that the Reporting Services resides on.
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.
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!

Great news!

Adam Singer — Tue, 31 Jul 2007 16:45:00 GMT

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.

He who permissions least, permissions best

Adam Singer — Wed, 23 May 2007 21:05:00 GMT

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:

allow the "developers" group read, label, lock, pendchange, and checkin access
deny the "contract developers" group checkin and lock access
allow the "testers" group read access
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.

Can you direct me to Directory Services?

Adam Singer — Thu, 29 Mar 2007 22:15:00 GMT

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

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

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.

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

Random Acts of Group-ness

Adam Singer — Wed, 28 Feb 2007 22:00:00 GMT

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!

'Grep'ing Groups

Adam Singer — Fri, 09 Feb 2007 20:05:00 GMT

Man have I been busy. What have I been busy doing? Well, see there's.... actually, I'll let Brian explan as he's already done such an eloquent job at it, with some neat charts and graphs, too.

I mentioned in my last post that I have some code that will help you find built-in groups. It's actually pretty simple, and build upon code that James already provided last year. Say you want to find the Team Foundation Administrators group, the Valid Users group, or the Service Accounts group. These three groups are always created when TFS installs, so we added a neat flag to help you access them without knowing anything else than the server name. Try using the attached file as the main file in a new C# console application and then add dll references to Microsoft.TeamFoundation.dll, Microsoft.TeamFoundation.Client.dll, and Microsoft.TeamFoundation.Common.dll. Many thanks to Matt Hoover for the code review on my sample code here.

The key piece of code is the following method.

/// <summary>
/// Prints out the membership of the three built-in groups
/// </summary>
public void DisplayBuiltinGroupMembers()
{

// Find all the Administrative users
Identity adminUserSids = m_gss.ReadIdentity(SearchFactor.AdministrativeApplicationGroup, null, QueryMembership.Expanded);
PrintSubUsers(adminUserSids);

// Find all the Service accounts
Identity serviceSids = m_gss.ReadIdentity(SearchFactor.ServiceApplicationGroup, null, QueryMembership.Expanded);
PrintSubUsers(serviceSids);

// Find all the valid users
Identity allUserSids = m_gss.ReadIdentity(SearchFactor.EveryoneApplicationGroup, null, QueryMembership.Expanded);
PrintSubUsers(allUserSids);

}

We can also read the project administatrative groups in a similar way. The only thing you need to know is the project URI. Note that if you have the project name you can find its URI the ICommonStructureService's "GetProjectFromName" method.

ProjectInfo project = m_css.GetProjectFromName("My Project");
Identity adminGroup = m_gss.ReadIdentity(SearchFactor.AdministrativeApplicationGroup, project.Uri, QueryMembership.Expanded);

Disclaimers: The most efficient means of reading identity information is by using the SearchFactor.Sid. If you plan to do a tremendous number of queries like the ones in my sample app and want to get the best perf, this may not be the right method for you. Instead, use the members of the Microsoft.TeamFoundation.GroupWellKnownSidConstants class in Microsoft.TeamFoundation.Common.dll (this will also allow you to access the Licensed Users Group which only exists in the Team Foundation Server Workgroup Edition). Even so, the extra SearchFactors can make your code look a bit prettier.

Living Large

Adam Singer — Mon, 08 Jan 2007 19:31:00 GMT

As Brian points out, there are some new Orcas specifications available for TFS. I've been working on the Large Group Sync crew for some time, and am very proud of the end result. What used to wind up as a support call can instead be managed by your Team Foundation administrator. While the whole system may not handle an enormous number of users in the system, at least the basics will still work and you can back out to a fully functional state by paring down the number of users. I can't wait until this gets released so you folks "out in the wild" get a chance to see how it works!

Of course, never one to miss an opportunity for some form of celebration, I baked a batch of sugar cookies for the team:

Virtual Green is made of People!

Adam Singer — Thu, 14 Dec 2006 21:45:00 GMT

So you want to run Team Foundation Server, but don't have the physical machine resources. You think- 'hey, isn't Virtual Server a free download now?' You're right! And what's best, TFS works just fine in a Virtual Server. Having done quite a bit of testing against servers set up in virtual machines, I can attest to at least basic functionality (and much deeper for some features). Still, there are a few issues to consider of before put all your eggs in the bandwagon as the train leaves the station.

First, we generally recommend that any virtual machine have somewhat increased memory and hardware from the default recommendations, and the host machine should have approximately double the recommended RAM. Also, I've heard that it can help to have the virtual machine's VHD stored on an entirely separate physical drive from the drive with the host machine's OS. If you have other processor intensive operations running on the host OS, or other VPCs running simultaneously, your TFS performance will decline as well.

Also note that I don't know if virtual machines are an officially supported TFS hosting mechanism (I would postulate due to potential performance hits as well as network configuration issues between host and guest OS). That being said, for small teams, virtual machines will likely help ease the hardware costs of a new server.

Oh- and virual machines certainly aren't made of people, you know. They're made of other machines, chopped up and reprocessed into a messy pulp of silicon and plastic, and eventually reconstituted as a Replicant.