New "Team System Web Access" is great!

August 2007 - We just loaded Team System Web Access 1.0 on our sandbox and we love it! The ability to start and stop and monitor builds is a wonderful addition. No need to fire up Studio just to launch a build. Or even better, we can now have our wireless deviced managers, start builds from their Blackberry's. I think Teamplain 2.0 had some of these features, but we stayed away from it since it was not "officially" released.

In addition to some new features, the load time has decreased significantly which is comforting. With Teamplain 1.0 it often took 5-10 seconds minimum for the application to load in the user's browser. While unscientific, Team System Web Access is loading in a second or so.

I also tested the Documents interface and it looks like a minor bug (actually it's quite major if you didn't abandon the interface like we did) with data loss was addressed. With Teamplain 1.0 we noticed that all changes were lost when checking the document back in. I'm not 100% sure if this is because we had something messed up or not. With Team System Web Access we are now planning to actually use the Documents interface.

We haven't played around with the Source Control tab yet, but there looks to be some nice light weight tools for viewing source and source meta-data.

Our final opinion will be made once we get this on our DEV and PROD systems, but so far we've had nothing but good vibes about this product. It will making adopting TFS by management (who doesn't want to install Visual Studio) much easier.

Thanks for releasing this before Orcas!

"No history entries were found for the item and version combination specified"

July 2007 - My worst TFS fear almost happened today. I Right Clicked on a folder under Source Control and selected View History using Team Explorer. After spinning for a few seconds I got the error "No history entries were found for the item and version combination specified." "What the heck is that?" I said to myself. I was able to tree through the source and open a file, but couldn't do a Get Latest or perform any other function. "Am I loosing my mind? This just worked fine yesterday."

My first few hypothesis's were based on my previous experiences as a VSS administrator. "We have a corruption issue," I screamed out to my local contemporaries. The .NET guys had worry written all over their faces. The Java guys started to snicker.

I Googled the error and got back two unrelated hits. I Lived it, can ironically got the same two hits. Coincidence?

Anyway, after suffering a near break down, for some reason I decided to check the permissions of the project. When Right Clicking on the project, selecting Properties, then Security, the project had no one setup with permissions (or so I thought). That was odd? Since I'm part of the [Server]\Team Foundation Server Administrators group I thought I'd be able to add my account. Nope.

I then logged into the App Tier (don't tell our system administrators this) and checked the Security. Sure enough, I could see there was one group who had access to the project and it didn't include me. The Team Project administrator in London had adjusted permissions for the project. We centralized the Server administration, but decentralized some of the Team Project administration. I Logged onto the App Tier with an account in the local Administrator group and was able to add my account. Back on my machine then, I was able to do View History just fine. .NET guys were happy to see the error was so simple to resolve, the Java guys frowned and stuck their faces back in Eclipse.

So the moral of the story is, if you get the error "No history entries were found for the item and version combination specified" make sure you have correct permissions setup on the Source Control projects (a.k.a Folders).

Using Team Build for Java builds that use Ant

July 2007 - We're a Java development group using TFS. You're probably asking why a Java development group would buy TFS, which is a valid question. The answer is quite long and complicated (political), so I'll save the gory details for a future post. In short; though my group uses primarily Java, a group across the hall, which is equally sized, uses .NET. We're a fairly large software company who was looking for a cost effective solution that would satisfy both Java and .NET developers. After evaluating the array of offerings, TFS offered this for us.

To compile our Java code we use Ant exclusively and Anthill Open Source as a high-level driver to kick off the builds. If you're interested in using Anthill Open Source to talk to TFS, I hear there is a friendly open source developer ;) who has written an adaptor for you.....

Anyway, we really wanted our builds to list out the work items linked to changesets included in each build. Team Build gives us exactly what we want, but again we're a Java shop using Anthill. How can we use Team Build to run our Ant scripts?

We (actually my wonderful configuration management colleague who deserves all the credit for figuring this stuff out) had to override the "CoreCompile" target in our TFSBuild.proj file so we have control of what "compile" means for us. The full list of things "CoreCompile" does is located in the "microsoft.teamfoundation.build.targets" file. Since "compile" to use means call ant, we can override "most" of that stuff.

I say "most" because we do need to call MSBuild. If we don't, build results are not published to the data warehouse. This is a bit lame, but after we all got done cussing and swearing at Microsoft (remember we're a Java development group and take every good natured opportunity to bash Microsoft), we simply created a blank solution file, placed it next to our build.xml in source control and called it. The only two lines in the solution file are "Microsoft Visual Studio Solution File, Format Version 9.00" and "# Visual Studio 2005". It does nothing more than somehow signal Team Build to publish our results in the data warehouse.

After we get done calling the superfluous MSBuild task, we do the real work. We use the Exec task to call Ant with the needed parameters. Lastly we copied over the OnError task from the main "CoreCompile," which will execute the "OnBuildBreak" task in the master targets file (i.e. microsoft.teamfoundation.build.targets).

I don't consider this an optimal solution, but a step in the right direction. Our current Anthill solution has a nice feature where it will only build if there are changes. Team Build fires away every night, which ends up creating a number of needless builds. We also frown every time we setup a new project and have to put a blank Solution File next to the build.xml. Again, we get over it with a afternoon coffee and obligatory Microsoft bash session (all in good fun of course).

So if you're a Java group using TFS, give Team Build a try. It seems to be working fine for us, and once Orcus gets here Team Build should have a number of additional features (e.g. continues integration builds) that you'll want to take advantage of.

<Target Name="CoreCompile">
<TeamBuildMessage Tag="Configuration" Value="%(ConfigurationToBuild.FlavorToBuild)" />

<MSBuild Condition=" '@(SolutionToBuild)'!='' "Projects="@(SolutionToBuild)" Properties="Configuration=%(ConfigurationToBuild.FlavorToBuild);Platform=%(ConfigurationToBuild.PlatformToBuild);SkipInvalidConfigurations=true;VCBuildOverride=$(MSBuildProjectDirectory)\TFSBuild.vsprops;FxCopDir=$(FxCopDir);OutDir=$(OutDir);ReferencePath=$(ReferencePath);TeamBuildConstants=$(TeamBuildConstants);$(CodeAnalysisOption)" Targets="Build" />

<Exec Command='ant -f "$(SolutionRoot)\ant\build.xml" -Dappdeploy_nightly="true" -Dversion=0.0.0.0'>
<Output TaskParameter="ExitCode" ItemName="ExitCodes"/>
</Exec>

<OnError ExecuteTargets="OnBuildBreak;" />
</Target>

SQL 2005 SP2 and TFS RTM

July 2007 - We're running our Data Tier in a cluster and thus unable to upgrade to TFS SP1, as until lately TFS SP1's install was not supported on a clustered Data Tier. They have that fixed now, but since we're running fine in PROD, we've decided to wait for Orcus before we upgrade. With the amount of time we spent on getting TFS RTM running, we want to use the product and not continue to troubleshoot it.

We started off with SQL 2005 SP1 (plus a number of hot fixes that the DBAs take care of). For a reason unknown to me (probably just consistency in our data center) the DBAs wanted to upgrade to SQL 2005 SP2 (plus a number of hot fixes). We were a little nervous about this as according to Mr. Harry, they run MSSQL 2005 SP2, but also TFS SP1 (see link).

We got confirmation from our sales engineer that Microsoft was able to test the SQL 2005 SP2 and TFS RTM configuration and everything looks good. We've updated our DEV environment and can confirm that we've not run into any issues. We're planning on upgrading our PROD environment in two weeks.

If your DBAs are looking to get you to SQL 2005 SP2 and you're still running TFS RTM like us, feel free to upgrade SQL 2005 as it's worked fine so far.

Deleting a workspace pointing to a server that is no longer

June 2007 - During the last year or so we've had a number of TFS servers up and running. The first server was a "proof of concept" server that ended up expiring on us right before a demo. Microsoft was nice enough to give us an extra 30 day extension on the 120 day trial license, but after 150 days of running TFS (both AppTier and DataTier) on an old desk top machine, we had had enough of it.

Our next TFS instance was for the "pilot," and to be honest it was not much better. In fact performance might have been worse (not due to TFS though). It did however fulfill our pilot needs and got the TFS product approved by upper management. Once we purchased TFS, we bough a bunch of bulky hardware and have it all under tight control in our datacenter. We also ditched our "pilot" TFS box as the one gig of RAM was giving me heartburn. Enough about our old TFS instances though.

Just yesterday I was trying to setup a workspace and got the error "The remote name could not be resolved: 'F1-777-2KA'" This perplexed me as 'F1-777-2KA' was our pilot server that the local system administrators took off to the graveyard a few months back. Then I remembered that I must have had a workspace from the old pilot machine that is stuck in my local cache. Sure enough issuing the command 'tf workspaces' showed the old workspace pointing at a machine that was no longer in existence. I'll just delete it right? Wrong!

Logically, I issued the command 'tf workspace /delete TestMainline' thinking I could delete the workspace from my cache. The command returned the error "The remote name could not be resolved: 'F1-777-2KA'" Sure it can't. The machine is retired in some garbage heap.

After digging around I found Buck's post which lays the solution out for us. Simply open the 'VersionControl.config' file which for me was under 'C:\Documents and Settings\%USERNAME%\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache' and delete the invalid <ServerInfo> element. Below is what I had to delete. Good luck deleting your workspaces!

<serverinfo uri="http://F1-777-2KA:8080/" repositoryguid="0544w34a0-6cb2-498c-a64c-8ae38a6575657">

<workspaceinfo comment="" computer="U0000001-XPB" name="TestMainline" ownername="Domain\U0000001" lastsavedcheckintimestamp="0001-01-01T00:00:00Z">

<mappedpaths>
<mappedpath path="C:\anthill">
<mappedpath path="C:\tmp\ant_test">
</mappedpaths>

</workspaceinfo>

</serverinfo>

Our hardware and software configuration for TFS

I thought we'd take some time and share our hardware and software configuration for TFS. On the App Tier we're running a Primary with a Standby. Only one machine is "Active" at a time. We control what machine is "Active" with a load balancer (i.e. Big/Ip) and DNS entry (i.e. tfs.mycompany.com). We actually don’t use the load balancer's "load balancing" functionally (unfortunately not supported by TFS), but do use its interface to drain users before activating the Standby. This allows anyone with long sessions (e.g. a large Get from Source Control) to finish their session before we switch over to the Standby. Moving back to the Primary works the same way.

Each App Tier machine is running Windows 2003 Server 32-bit Standard Edition SP1, has four 2.8 GHz Intel P4 processors and four gigs of memory. Windows says it only has 3,456 megs of memory, but from what the Sys Admins tell me it really has four gigs. My guess is there is some plausible reason for Windows not recognizing the other half gig of memory.

On the Data Tier we're using an active/passive cluster. Both machines are running Windows 2003 64-bit Enterprise Edition SP1, have four 3.8 GHz Intel P4 processors and four gigs of memory. Oddly enough, unlike the App Tier, Windows recognizes the four gigs (4,095 to be exact) on the Data Tier. I'm guessing that is either because we're running the 64-bit or Enterprise edition of Windows.

The App Tier is running Reporting Services 32-bit Standard Edition and using the included Reporting Services license that ships with TFS. The Data Tier is running the 64-bit Enterprise Edition of Reporting Services which we had to buy separately. As a side note, make sure someone with four PhDs and two law degrees reads the licensing white paper. Figuring out what you need to license can be a nightmare. Here is the one big thing we missed: If you have a "Duel-Server Deployment" you can only use the included Reporting Services license for either the App Tier or Data Tier. You must buy the second copy of Reporting Services separately. In addition, here is something we almost missed. Since Data Tier is an active/passive cluster you only need one license of Reporting Services for both machine. Since the second machine is "passive" you only need one license. When the "passive" machine switches to "active" (and "active" switches to "passive") the license switches over (just on paper of course). Again make sure the suites in procurement get this all straight before you sign on the dotted line.

If we run into performance problems the first thing we're going to do is increase the RAM on our Data Tier. We're only running four gigs, which may be a bit low. Our user base is expected to slowly grow to around 200-250 users so we'll monitor the usage patterns to see if we need to add memory.

Feel free to share your configurations!

Should you use Active Directory Groups or Users when managing users in TFS?

June 2007 - One decision you'll have to make when implementing TFS is whether to use Active Directory Groups or Active Directory Users when setting up users in TFS. There are advantages and disadvantages of using both and I'll discuss them below.

Active Directory (AD) Groups - AD groups are typically setup and managed by system administrators or setup by system administrators and managed by help desks. Though I've never used the AD tooling to manage users, I can't imagine it being more difficult than how you manage users in TFS. Remember TFS permissions must be managed in TFS, SharePoint, and Reporting Services. Although the TFS Administration Tool makes things easier, even it can be unbearable at times. We're hopeful Microsoft will produce a more robust administrative tool for TFS in the near future. In the mean time, when using AD Groups all you do is add the group once in each Team Project and you're done messing with TFS administration.

AD groups also off loads the administrative process of adding/removing users from TFS. As a development team, we have little interest in adding/removing users all day. We're paid to develop software, not manage users.

Active Directory (AD) Users - Users give you a bit more control. Unlike the use of AD Groups, you get to control who is added to your TFS Team Projects and who is not. No need to worry about the help desk adding a third-party consultant to the wrong AD group and thus giving away your intellectual capital to someone who should not see it. You also have more flexibility on what TFS groups you want to assign users to. For example we have a Testing TFS group in each of our Team Projects. Using AD Users we can add the specific testers to the specific Testing groups in their respected Team Project. If we used AD Groups we'd need one AD Group for each Testing group in each Team Project. If you use a number of TFS Groups, you can create quite a mess.

Using AD Users also helps when troubleshooting rights. At our company, finding out who is part of what AD Group involves a call to the help desk and a 2-4 hour turn around. If a user is having issues getting access to something or getting too much access to something, it can be very difficult to find out why. If you use AD Users, you can see what permissions that specific user has.

The use of AD Users is not without it's faults though. The biggest issue is what a pain it is to add the users. Again the TFS Administration Tool helps, but it's still not the easiest tool to use. By using AD Groups, you avoid fighting with TFS.

In conclusion, we decided to use AD Users as having 100% control over who sees what is very important to us. We have a billion dollar product in TFS with some very sensitive code that we only want select developers to see. With the number of contractors we have coming and going, we need to safeguard our priceless assets. Though the use of AD Groups would be easier, since we need to have tight control, using AD Users works better. Since this will not change anytime soon, we'll look forward to when Microsoft gives us a more robust TFS administration tool.

Automatic Checkouts with Team Explorer

June 2007 - Last night while I should have been sleeping, I was thinking why doesn't Team Explorer implement automatic checkouts like Teamprise's Eclipse Plug-in? I can't believe Microsoft left that out. It then dawned upon me that maybe you have to tell Team Explorer you want to "associate" your code with Source Control. Sure enough, I just bound my .NET solution file (and all its associated projects) to Source Control, and now Team Explorer does the automatic check out for me. This is very nice as it saves us a few more clicks when working on .NET code.

I'm probably overlooking this functionality as well, but while we can "Bind" a solution file I can't seem to "Bind" anything else in Team Explorer. For example we have our Process Template modifications under Source Control. Seems like a prudent thing to do since we're the Configuration Management group. Anyway, when using Teamprise and modifying Task.xml, we get the nice automatic check out feature. Unfortunately when we edit the same file in Team Explorer, we don’t get that feature and have to "Overwrite," "Check Out," and "Check In."

I can't say the reason I use Teamprise for most of my Process Template modifications is because of the automatic check out (the real reason is 60%+ of our user base is using Teamprise and I have to support them), but it is a very nice feature. Keep up the good work Teamprise folks!

Automatic Checkout with Teamprise

June 2007 - I'm doubt this posting will help anyone in trouble, but I thought that I'd post it anyways as I think it's a pretty cool feature. One of the really nice things I like about Teamprise's Eclipse Plug-in is how you can open up a file, start to edit it while Teamprise automatically checks the file out for you.

Unfortunately I don't see this feature in Team Explorer. In Team Explorer I find myself making a few changes, clicking Save and getting the "Save As, Overwrite, Cancel" button. I then "Overwrite" the file, check it out, and check it in. With my math, Teamprise saves you at least two clicks with the automatic check out. Below is a high level (very high level) workflow.

Teamprise Eclipse Plug-in
Open file (click 1)
Save file (click 2)
Check in (click 3)

Team Explorer
Open file (click 1)
Save file (click 2)
Overwrite file (click 3)
Check out file (click 4)
Check in file (click 5)

"Code Coverage Analysis Service" in Stopped Status

June 2007 - We've been looking into an "issue" of our "Code Coverage Analysis Service" service sitting in a "Stopped" state in both our DEV and PROD environments. Our Sys Admins alerted us of the potential "issue" as they were getting paged every time the service stopped. I'm not 100% sure how their monitoring works, but from what I understand they are paged when ever a service set to "Automatic" stops. Once these servers went out of maintenance mode, the Sys Admin pagers wouldn’t stop buzzing!

When starting the service we'd periodically get a message stating "The Code Coverage Analysis service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance logs and Alerts service." So the Sys Admins set the service to "Manual" until we got this figured out.

While working with Microsoft support on a different issue we asked about the service being stopped. According to our support representative this is normal behavior. Apparently other services do this as well. I'm surprised our Sys Admins never ran into it before given we run over a thousand Windows boxes.

Anyway the services are put back to "Automatic" and the Sys Admins have excluded this particular service from their "Started/Stopped" monitoring.

I'd be interested to see if anyone has similar experiences.