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.