TSWA Profile > Options Not Staying

A colleague of mine tracked down an issue where all users' TSWA Profile > Options were not staying after they closed the browser. For example, a user would change their Theme to Olive, but after they closed their browser it would default back to the default.

We're not sure if this is the right fix, but we had to change permissions on the D:\Program Files\Microsoft Visual Studio 2008 Team System Web Access\Web folder so that "Users" had Modify permissions. Users are now able to change their Options and they stick.

Firefox authentication issue resolved

The good folks at Microsoft reached out to use to see if they could get more information on the Firefox troubles we've been having. That request forced to look into the Firefox issues a bit, and as it turned out I think we have the primary problem resolved on both Windows and Linux.

Here is what we found out; we use a proxy server for the entire company. Because of the proxy we have a defined inclusion list in IE that tells IE and Visual Studio to not go through the proxy for internal sites. We use *.int.mycompany.com*. If you're wondering why the trailing "*" is there, check out this post. This list is company wide and managed by the support folks.

Since Firefox is not "company supported" they don't send out an inclusion list so people build their own. This is typically done by just copying what IE has. When the users copied IE, they got *.int.mycompany.com*. By the looks of it though, Firefox handles the list a bit different and was giving the consistent "Authentication Prompt" as the page rendered. To fix the issue, we needed just *.int.mycompany.com without the trailing "*".

So far this has worked with the small body of users we've had try it. Now that we have this fixed, we might have some more users go back to Firefox and test it out more.

Long source file names don’t work well in TSWA 2005

We have not run into an issue with long file paths in TSWA, but another TFS administrator in this monster of a company has. Apparently it's caused when you have a file path more than 260 characters. We're probably not running into the error for one of these two reasons.

First, our localCache path is set to D:\cachedir from the default of C:\Program Files\Microsoft Visual Studio 2005 Team System Web Access\cache\. Thus saving us 64 characters.

Second, who interacts with source code from TSWA? While I nice feature to put in the marketing material, our users don’t use it often.

Here is a good posting explaining some more of the gory details. Sounds like the issue is fixed in TSWA 2008.

"Culture name 'en-securid' is not supported. Parameter name: name"

A user in England was getting the error "Culture name 'en-securid' is not supported. Parameter name: name" when accessing Team System Web Access 1.0. I asked Google and Live. No luck.

I then started to dig. In IE if you click Tools > Internet Options > Languages.. you'll see the Language Preference dialog. The user with the issue only had "User Defined [en-securid]" listed. They added "English (United States) [en-us]" right below "User Defined [en-securid]", but still got the error. We then had them Move Up "English (United States) [en-us]" to the top value, click Ok > Ok and the error was resolved.

If you run into a similar error, give this a shot and let me know how it goes.