Hakan Eskici

Team Foundation Server 2010 Beta 2 Available

2009-10-22T13:16:14Z

We have just announced the availability of Team Foundation Server 2010 Beta 2 along with the Ultimate, Premium and Professional editions of Visual Studio 2010.

Download Links:

Related Resources

Where is Web Access?

Web Access is integrated into Team Foundation Server and gets installed by default when you install Team Foundation Server.

On a default configuration, Web Access is available at:

http://server:8080/tfs/web

Where is Work Item Only View (previously known as WIWA)?

WIOV now shares the same URL with full Web Access:

http://server:8080/tfs/web

There is a new permission to control access to full Web Access features. Anyone in the “Work Item Only View Users” group will have that permission denied, therefore they will see the Work Item Only View. Others will see full Web Access.

How can I install Web Access separately on its own server?

The recommended way is to install a “Application Tier Only” instance of TFS by pointing it to the same TFS database and using that instance just for Web Access. For example:

Server1: End users connect to this server from Team Explorer (Web Access is available but not used)
Server2: Web Access users connect to this server from a Web browser (TFS Application Tier is available but not used)

Sample Script to Enable New Features in Upgraded Team Projects (TFS 2010 Beta2)

2009-10-19T20:40:00Z

Important: The instructions in this post only apply to the Beta2 version of Team Foundation Server 2010. For Beta1, see this post.

Introduction

When you upgrade your existing Team Foundation Server to version 2010, upgraded team projects will work as before. However, you need to make some changes to these team projects if you want to enable the following features:

Test Case Management
Agile Planning Workbooks
Lab Management

In this post, I’m providing a sample script to help you with many of the steps. For complete information about enabling these features, see the following article:

Enabling New Application Lifecycle Management Features for Visual Studio Team System 2010 Beta 2 in Upgraded Team Projects

Required Changes

Refer to the table below for a summary of the required changes to enable the new features for upgraded team projects. Note that these changes are only necessary for the team projects that existed before the upgrade. If you are creating new team projects, all of these features are enabled by default.

Feature	Requirements
Test Case Management	Add Test Case and Shared Step work item types () Update existing Bug and Scenario work item types () Add new link types () Add work item categories ()
Agile Planning Workbooks	Update existing Task and Scenario work item types (*) Create iteration and product backlog queries Bind workbooks against the queries Modify workbook document properties
Lab Management	Grant lab management permissions to user groups Provision lab resources
Reports	Update your existing reports to work against the new warehouse

(*): You can use the sample script attached to this article to make these changes marked with (*) in the table above.

However, this sample script is designed to work if the following are true:

You are using the Beta2 (English) version of Team Foundation Server 2010
Your team project was created with the English language version of “MSF for Agile Software Development - v4.2” process template before you upgraded your Team Foundation Server
No modifications have been made to the work item type definitions on your team project before or after the upgrade
You are running the script on an English operating system that has Visual Studio Team Explorer 2010 Beta2

You need to either modify the sample script, or create your own if:

Your team project was created with a process template other than “MSF for Agile Software Development v4.2” (English)
You have made modifications to the out of box work item type definitions on your team project
Your team project already has an existing Test Case work item type
You want to use the existing “Repro Steps” field on your Bug work item type
You are using a non-English Team Foundation Server

Sample Script

The attached ZIP file contains the script and updated MSF for Agile 4.2 work item type definitions. You must be a project collection administrator to run this script. The script requires the witadmin.exe utility which is installed by Team Explorer and Team Foundation Server.

To use the script, download and extract it to a local directory such as C:\Upgrade. Before you run the script, open “EnableFeatures.bat” in a text editor and complete the configuration by specifying values for the following:

Team Foundation Server URL
Name of the team project collection
Name of the team project
Path to witadmin.exe utility
Set ConfigComplete = 1 to indicate that you’ve completed the configuration

Important: This script will only work against “unmodified” team projects created with “MSF for Agile Software Development – v4.2” process templates on Beta2 version of Team Foundation Server 2010.

What does the script do?

The script is a simple batch file that uses the witadmin.exe utility to make the following changes:

Saves a backup of your existing Bug, Task and Scenario work item types
Adds new link types (Test Case / Shared Steps and Tests / Tested By)
Adds new work item types (Test Case and Shared Step)
Overwrites Bug, Task and Scenario work item types
Adds work item categories

Download the Sample Script

If you have any questions about the script, feel free to contact me.

Investigating HTTP 400 Bad Request Errors in Web Access

2009-06-30T18:49:18Z

Recently, one of our customers reported an issue with Web Access causing some users to get HTTP 400 Bad Request errors.

HTTP 400 errors usually indicate that the request sent by the browser cannot be understood by the Web server. I’d recommend that you use a HTTP debugging proxy such as Fiddler to investigate such errors to see the underlying cause.

Header Too Long

If you see a Header Too Long error in Fiddler logs, one of the common causes for this is that you have users that belong to many Active Directory groups, which increases the size of the authentication headers the browser sends to the Web Server.

Workaround

The workaround is to increase the header size limit in IIS on the machine where you have Web Access installed:

Open Regedit
Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
Add a new DWORD value named MaxFieldValue
Enter 32768 as a decimal value
Add a new DWORD value named MaxRequestBytes
Enter 500000 as a decimal value
Restart the computer

This will increase the maximum accepted request sizes and should fix the HTTP 400 Bad Request – Header Too Long error.

FAQ on the Sample Script to Enable New Features in Upgraded Team Projects

2009-05-20T18:12:52Z

As a follow up to my previous blog post that talks about the sample script to enable new features in upgraded team projects, I wanted to answer a couple of questions and go into a little bit more detail.

Frequently Asked Questions

Do I need to run this script on my Team Foundation Server machine?

No, the script can be run on any machine where you either have Team Explorer 2010 or Team Foundation Server 2010 installed. Make sure you edit EnableFeatures.bat file to specify the path to the witadmin.exe utility as it might be on different locations depending on whether you have TFS or Team Explorer installed.

Can I use this script against team projects created with “MSF for CMMI Process Improvement” process template?

No, the sample script is designed to work only for team projects created with “MSF for Agile Software Development – v4.2” process template and doesn’t have any modifications applied to its underlying work item type definitions.

How can I check if my team project is created with “MSF for Agile Software Development v4.2” process template?

See the section “How to Check If Your Team Project is “Unmodified” below.

How can I check if my team project is “unmodified”?

See the section “How to Check If Your Team Project is “Unmodified” below.

What if I realize that some modifications have been made to the underlying work item type definitions for my team project?

See the section “What If My Team Project is “Modified” below.

How can I undo the changes that this script makes?

1. Restore backups of your Bug, Task and Scenario work item types

You can find the backups of your Bug, Task and Scenario work item types in Backup\<ProjectName> directory. If there are multiple files, look for the ones that has the earliest date/time stamp. Import the backups back to your team project using witadmin importwitd command.

2. Delete the new work item types

The script adds the Test Case and Shared Step work item types to your team project. You can delete these work item types by running witadmin destroywitd command.

3. Delete link types

The script adds Test Case / Shared Steps and Tests / Tested By link types to your team project. You can delete these link types by running witadmin deletelinktype command.

What if my team project is “modified”?

See the next section to check if your project is “modified” or not. If you determine that your team project is modified, you have two options:

1. Run the sample script anyway

This will overwrite your modifications and you will need to re-apply your modifications to your work item type definitions after running the script.

2. Modify the script and files

Examine the updated Bug, Task and Scenario work item type definitions under Agile5\TypeDefinitions directory provided with the sample script ZIP file to identify the changes to enable new features.
Rename/backup the updated Bug, Task and Scenario work item type definitions under Agile5\TypeDefinitions directory
Copy your own Bug, Task and Scenario work item type definitions to Agile5\TypeDefinitions directory and change the file names to UpdatedBug.xml, UpdatedTask.xml and UpdatedScenario.xml
Apply the same changes you identified in #1 to your own Bug, Task and Scenario work item type definitions in Agile5\TypeDefinitions directory
Run the script

3. Manually update your team projects by following the instructions in the guidance documents

See Enabling New Features of Visual Studio Team System 2010 Beta 1 in Upgraded Projects for pointers to guidance documents that explain how to enable individual features.

How to Check If Your Team Project is “Unmodified”

This section explains how to check if your team project:

was created with “MSF for Agile Software Development – v4.2” process template
has modifications that would complicate running the sample script to enable the new features

As a summary, you need to look at a couple of things:

Check the list of available work item types
Check the visual layouts for existing work item types
Check the work item type definition XML files

For details about each step, see the sections below:

Step 1. Check the list of available work item types

Using Team Explorer, right click the “Work Items” node under your team project

Hover over “Add Work Item”, make the sure the list matches:

Bug
Quality of Service Requirement
Risk
Scenario
Task

If you have a different list of work items, it means your team project is either not based on “MSF for Agile Software Development – v4.2” process template, or you have additional work item types imported to your team project.

Step 2. Check the visual layouts for Bug, Task and Scenario work items

Bug work item type

Create a new Bug for your team project, and make sure the visual layout matches the screenshots below:

Bug layout (click to zoom):

History tab on Bug (click to zoom):

Links Tab on Bug (click to zoom):

File Attachments Tab on Bug (click to zoom):

Details Tab on Bug (click to zoom):

Task work item type

Create a new Task for your team project, and make sure the visual layout matches the screenshots below:

Task layout (click to zoom):

History Tab on Task (click to zoom):

Links Tab on Task (click to zoom):

File Attachments Tab on Task (click to zoom):

Details Tab on Task (click to zoom):

Scenario work item type

Create a new Scenario for your team project, and make sure the visual layout matches the screenshots below:

Scenario Layout (click to zoom):

History Tab on Scenario (click to zoom):

Links Tab on Scenario (click to zoom):

File Attachments Tab on Scenario (click to zoom):

Details Tab on Scenario (click to zoom):

If the visual layouts of your work items are different, it means the work item types on your team project has modifications.

Step 3. Check the work item type definition XMLs for Bug, Task and Scenario work items

Export the work item type definitions by running following commands from a computer that has the witadmin.exe utility:

witadmin exportwitd /s http://server:8080/tfs /p Project1 /n Bug /f Bug.xml

witadmin exportwitd /s http://server:8080/tfs /p Project1 /n Task /f Task.xml

witadmin exportwitd /s http://server:8080/tfs /p Project1 /n Scenario /f Scenario.xml

Note: Replace the server URL (http://server:8080/tfs) and project name (Project1) with your own values.

Compare the exported XML files against the ones included in the sample script ZIP file:

Agile5\TypeDefinitions\UpdatedBug.xml
Agile5\TypeDefinitions\UpdatedTask.xml
Agile5\TypeDefinitions\UpdatedScenario.xml

The only differences you see should be the newly added sections on updated work item type definitions for enabling new features. Such changes are enclosed between the following comments:

Any questions or feedback? Just send me an email.

Sample Script to Enable New Features in Upgraded Team Projects (TFS 2010 Beta1)

2009-05-20T14:45:00Z

Introduction

Test Case Management
Agile Planning Workbooks
Branch Visualization
Lab Management

In this post, I’m providing a sample script to help you with many of the steps. For complete information about enabling these features, see the following article:

Enabling New Features of Visual Studio Team System 2010 Beta 1 in Upgraded Projects

Required Changes

Feature	Requirements
Test Case Management	Add Test Case and Shared Step work item types () Update existing Bug and Scenario work item types () Add new link types () Add work item categories ()
Agile Planning Workbooks	Update existing Task and Scenario work item types (*) Create iteration and product backlog queries Bind workbooks against the queries Modify workbook document properties
Lab Management	Grant lab management permissions to user groups Provision lab resources
Reports	Update your existing reports to work against the new warehouse
Branch Visualization	Convert branches using source control explorer

(*): You can use the sample script attached to this article to make these changes marked with (*) in the table above.

However, this sample script is designed to work if the following are true:

You are using the Beta1 (English) version of Team Foundation Server 2010
Your team project was created with the English language version of “MSF for Agile Software Development - v4.2” process template before you upgraded your Team Foundation Server
No modifications have been made to the work item type definitions on your team project before or after the upgrade
You are running the script on an English operating system

You need to either modify the sample script, or create your own if:

Your team project was created with a process template other than “MSF for Agile Software Development v4.2” (English)
You have made modifications to the out of box work item type definitions on your team project
Your team project already has an existing Test Case work item type
You want to use the existing “Repro Steps” field on your Bug work item type
You are using a non-English Team Foundation Server

Sample Script

Team Foundation Server URL
Name of the team project collection
Name of the team project
Path to witadmin.exe utility
Set ConfigComplete = 1 to indicate that you’ve completed this step

Important: This script will only work against “unmodified” team projects created with “MSF for Agile Software Development – v4.2” process templates on Beta1 version of Team Foundation Server 2010.

Download the Sample Script

What does the script do?

The script is a simple batch file that uses the witadmin.exe utility to make the following changes:

Saves a backup of your existing Bug, Task and Scenario work item types
Adds new link types (Test Case / Shared Steps and Tests / Tested By)
Adds new work item types (Test Case and Shared Step)
Overwrites Bug, Task and Scenario work item types
Adds work item categories

Questions?

For answers to frequently asked questions such as how to determine whether your team project is “unmodified”, see my follow up blog post:

FAQ on the Sample Script to Enable New Features in Upgraded Team Projects

If you have any questions about the script, feel free to contact me.

Enable Branch Visualization in Upgraded Team Projects (TFS 2010 Beta1)

2009-05-19T23:29:51Z

As part of the series on “enabling new features in upgraded team projects”; Jamie Cool, our Lead Program Manager on Team Foundation Server team, talks about enabling branch visualization features in upgraded team projects:

In Team Foundation Server 2010, we have significantly enhanced the concept of a branch. We have added functionality to branches such as:

Branches can now be clearly identified in the source control explorer.

You can now visualize your branch hierarchy and visually track your code changes as they move through your branches.

You can assign branch operation security. Ex. Who can create/delete a branch and who can merge a branch.

Branches now have checks in place to discourage poor branching structures.

In order to take advantage of these new features, you will need to convert your previously branched folders to fully fledged branches. The steps for doing this are as follows:

Identify the branch structure you are currently using. If you would like to change your branch structure, now may be a good time to do so, but it is not necessary.

Identify the folder in your solution explorer mapped to your parent (top level) branch.

Right click on that folder. On the context menu select “Branching and Merging” & then “Convert Folder to Branch”. This will open a dialog for doing the conversion of a folder to a branch.

At the bottom of the dialog, check the “Recursively perform this conversion for all branched child folders”.

Next click the “Convert” button. This will upgrade this folder to a branch. It will also walk the branch tree and convert all folders that have been branched from this folder.

Your branches should now be shown with the branch icon in the source control explorer tree.

If you have any folders that had their relationship established via Baseless Merge, you will need to use the “Reparent Branch” option from the “Branching & Merging” context menu to establish the parent/child relationship in the branch hierarchy.

Repeat these steps for all remaining branch trees in your solution.

Now that you have completed this step, you should be able to take advantage of the powerful new branching features in Team Foundation Server 2010. You can now view your branch structure visually by selecting “Branching and Merging” and then “View Hierarchy” from the branch context menu. You can also choose to “Track Changes” from a work item’s context menu to see how the changeset associated with that work item has moved through your various branches.

You can check out the MSDN documentation on Branch Visualization to learn more about the capabilities available to you:

How to: View the Branch Hierarchy of a Team Project

How to: View Where and When Changesets Have Been Merged

Enjoy!

Jamie Cool

Where is Team System Web Access in TFS 2010 Beta1?

2009-05-19T18:22:29Z

We have recently announced the availability for Team Foundation Server 2010 Beta1, which also includes Team System Web Access.

Here’s the direct link to Team Foundation Server 2010 Beta1 download:

http://go.microsoft.com/fwlink/?LinkId=147412

You can find the other downloads such as VSTS 2010, .NET Framework 4.0, Test and Lab Agents etc at:

http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx

Team System Web Access in TFS 2010 Beta1

Until now, Team System Web Access was published as an out of band power tool. In this release and beyond, Web Access is now an integrated part of TFS, and it is installed by default when you install TFS.

What’s the Web Access URL?

By default, Web Access is available at

http://<server>:8080/tfs/web

Tip: Just append “/web” at the end of your Team Foundation Server URL and that’s where you can find Web Access.

What’s the Work Item Only View URL (WIOV, or previously known as WIWA)?

WIOV is not enabled in TFS 2010 Beta1. It will be available in a future release. Unlike the previous versions, the URL for WIOV will be the same as the URL full Web Access as we will be determining whether a user has a CAL or not by checking for membership to “Work Item Only View Users” security group.

Where is Web Access installed to?

By default, files are in:

%Program Files%\Microsoft Team Foundation Server 10.0\Application Tier\Web Access

You can find the log files, cache files etc in this location.

Can I install Web Access on its own server?

No, you cannot install Web Access separately on its own server. It is always installed along with TFS Application Tier. However, if you want to dedicate a separate server for Web Access, the recommended way is to install a “Application Tier Only” TFS instance by pointing it to the same TFS database and using that instance only for Web Access. For example:

Server1: End users connect to this server from Team Explorer (Web Access is available but not used)

Server2: Web Access users connect to this server from a Web browser (TFS Application Tier is available but not used)

Strange TSWA connection issue if the server name contains an underscore character

2009-02-17T02:27:09Z

UPDATE: Here’s the KB article that covers this:

http://support.microsoft.com/kb/968549

Recently, one of our customers reported a strange issue that occurs with TSWA 2008. Although everything is configured correctly and running fine, it’s not possible to connect to TSWA using Internet Explorer if the server name contains an underscore (“_”) character. One of our MVPs, Neno Loje, reported a similar issue a while ago, so I’m writing this blog post to explain what’s going on.

Symptoms

1. When you go to the TSWA website, Internet Explorer displays an error saying “Internet Explorer cannot display this web page”. The error details might indicate a possible DNS or an authentication issue.

FAILS: TSWA on http://server_name:8090, TFS on http://server_name:8080

2. Connecting to TSWA using the IP address, but using the server name to connect from TSWA to TFS causes the following error message to be displayed on TSWA login form:

“The request failed with HTTP status 405: Method Not Allowed.”

FAILS: TSWA on http://<IP Address>:8090, TFS on http://server_name:8080

3. If the IP addresses are used instead of the server names when connecting to both TSWA and TFS, everything works fine. In some cases, using a browser different than Internet Explorer might work fine using server names.

WORKS FINE: TSWA on http://<IP Address>:8090, TFS on http://<IP Address>:8080

4. Analyzing the network traffic between the browser and TSWA website shows that the browser is being redirected continuously between login.aspx and index.aspx until it gives up. The same behavior can also be observed by looking at the TSWA log files, which looks similar to:

... Creating TeamFoundation Server...
... TeamFoundation Server Successfully Created.
... Creating WorkItemStore...
... WorkItemStore Successfully created.
... Response is redirected to /index.aspx?pname=Project1.
... Session Started
... Response is redirected to /UI/Pages/Login.aspx?redirect=%2findex.aspx%3fpname%3dProject1.
... Session Started
... Creating TeamFoundation Server..

Cause

Underscore (“_”) is not a valid character for URLs according to the RFCs. (This is why you cannot register a domain name with an underscore).

When you use Internet Explorer against a web site that uses session cookies (such as TSWA), a valid session cannot be established due to a security feature in Internet Explorer cookie handler if the server URL contains underscore characters.

Solution

Ideally, don’t use underscore characters in your server names. This issue is not specific to TSWA, and you might end up with similar issues with different web applications that depend on session states.

Workarounds

For a quick workaround, you can connect to TSWA using the IP address. You may also want to change the default TFS server entry in TSWA web.config to use the IP address of your TFS, or to “localhost” if TSWA and TFS is on the same machine.

For the longer term solution, you should consider to:

Change the name of your server to something else that doesn’t contain an underscore.
Create a DNS alias for your server that resolves to the same IP address, and use that name to connect to TSWA and TFS.

Contact me if you have any questions or feedback.

Fix: WIWA cannot download attachments

2009-02-13T22:04:30Z

If you are using the WIWA feature in the latest TSWA 2008 SP1, you may notice that it’s not possible to download attachment files from the work item window.

As a workaround, you can edit Wiwa\UI\Pages\WorkItems\DownloadAttachment.aspx and modify the page directive to fix this by adding the HasPermission attribute:

<%@ Page Language="C#"
        AutoEventWireup="true"
        MasterPageFile="~/UI/Masters/Window.master"
        Inherits="Microsoft.TeamFoundation.WebAccess.UI.Pages.WorkItems.DownloadAttachment"
        Codebehind="DownloadAttachment.aspx.cs"
        HasPermission="true" %>

We’re sorry for any inconveniences, please contact me if you have any questions.

Fix: Work Item Custom Controls SDK for Web Access

2009-02-13T21:57:22Z

The current TSWA 2008 SP1 release contains a few missing files in the Work Item Custom Controls SDK and one of our developers Serkan has published a blog post to provide a workaround. For details, see:

Missing Files in Custom Control Samples Project

White Paper: Team System Web Access 2008 Scalability Limits

2009-01-17T01:15:05Z

We have just published a white paper that explains the scalability limits of Team System Web Access 2008 power tool.

Download it at:

http://go.microsoft.com/fwlink/?LinkID=139762

If you have more than 100 users using Web Access, you may want to take a look at the document to understand what these limits are and what you can do to improve the scalability. The white paper talks about the symptoms, limits, test results and workarounds.

You can contact me in case you have any questions or feedback.

Security Update for TSWA 2008 SP1

2009-01-17T01:03:33Z

A security issue has been identified with Team System Web Access 2008 SP1 and we have recently published an update that fixes it. Please note that this is a full release, so you will need to uninstall any existing versions of Web Access before installing this update.

You can download it at:

http://go.microsoft.com/fwlink/?LinkID=136577

This update is available for all languages including English, Chinese Simplified, Chinese Traditional, German, French, Italian, Japanese, Korean, Russian, and Spanish.

UPDATE #1:

See Brian Harry’s blog post for instructions about learning which version of Web Access you’re using, and how to manually patch your existing Web Access instance.

UPDATE #2:

The KB article for this security update is available at:

http://support.microsoft.com/default.aspx/kb/961267

Updated Team System and TFS VPCs

2008-12-26T23:09:00Z

Brian Randell has recently published a set of VSTS virtual machine images for Virtual PC, Virtual Server and Hyper-V. You can download either the TFS-only version, or the VSTS "all-up" images that contain the latest bits such as:

Team Foundation Server 2008 SP1
Team System Web Access 2008 SP1
Visual Studio Team System 2008 SP1
Power Tools October 2008
and more...

See Brian's blog post for download links.

Web Access Community Translations Release 1.0

2008-12-01T03:55:00Z

For a while, we've been working on an experimental project to get Team System Web Access translated to languages other than the official ones. We wanted to create a platform for volunteers to contribute to translation efforts, so that we could release packs of translations as we made progress.

Well, recently the very first release of the TSWA Community Translations is published as announced by Marcel de Vries and Brian Harry:

Team System Web Access Community Translations Release 1.0

Big kudos to Marcel de Vries, one of our MVPs, both for doing the Dutch translation and also for coordinating the volunteers that worked on the translations, and of course, to our volunters that managed to finish the translations in relatively short time. Being from Turkey myself, one of the languages I really wanted to get in the first release was Turkish, so my personal thanks go to our Turkish MVPs Cengiz, Coskun and Okan for volunteering to work on the Turkish translation.

In the first release, we have 7 new languages:

Croatian, done by Ognjen Bajic
Portuguese (Brazilian), done by Igor Abade and Ramon Durães.
Turkish, done by Cengiz Han, Coskun Sunali and Okan Tekeli
Danish , done by Gert Christiansen
Swedish, by Mathias Olausson
Polish, by Marek Byszewski
Dutch, by Marcel de Vries

Combined with English, Chinese Simplified, Chinese Traditional, German, Spanish, French, Italian, Japanese, Korean and Russian , Team System Web Access is available in 17 languages in total!

How can I download the language packs?

Go to TSWAL project releases at CodePlex and you'll see the list of published translations. A release will likely contain multiple languages.

How can I help?

Contact myself or Marcel and we'll get you started. There are various ways you can help, such as adding a new language translation, validating an existing translation and improving it.

TSWA Work Item Only View (aka WIWA) with TFS Workgroup Edition

2008-09-10T07:05:00Z

Recently, I've been seeing questions about TSWA Work Item Only View (aka WIWA) and how it works with Team Foundation Server Workgroup Edition.

As a quick background, Work Item Only View is a feature of TSWA that enables accessing work items you've created without having to own a Client Access License (CAL) for TFS. This feature has been built for organizations that has users occasionally filing bugs from time to time, but don't want to buy CALs for each of them. No matter if you have 10 or 1,000 users, as long as they only use this interface, it's OK not to buy CALs.

What makes this possible is a change in TFS 2008 EULA. One important thing that's usually overlooked is that this licensing flexibility is made available for TFS 2008 Standard Edition only, as explained in section 3.a of the EULA. If you read my original blog post about Work Item Only View, or take a look at the public spec, you will probably notice that I've tried to mention this in a couple of places.

There's a common confusion when it comes to TFS Workgroup Edition and Work Item Only View together. TFS Workgroup Edition doesn't use CALs. As a technical limit, it only supports up to 5 people, and all of them must be in the "Licensed Users" security group. Using the Work Item Only View against a TFS Workgroup instance does not change this limitation. In addition, CAL flexibility does not apply to TFS Workgroup edition anyway. I agree that it sounds a bit confusing, but I wish I had a better answer :)

I hope this blog post clarifies the confusion a little bit. If you have any questions, feel free to contact me.