A few of my coworkers and I were discussing the Olympic controversy regarding the ages of the female gymnasts. After much thoughtful discussion, we came up with several possible rational explanations for the discrepancies.

1. Time travel - perhaps the gymnasts were sent back a year so both the old and new official records are correct.
2. Cryogenic chambers - this could be used to explain how Kim Gwang Suk was listed as 15 for three years in a row. Also, since the actual age since birth would be different from years lived, the athlete could have two different ages depending on the occasion.
3. Different numerical systems - There may be a numerical system that skips from 14 to 16. After all, some hotels lack 13th floors.

Be that as it may, I'm not terribly concerned. The Olympics are still fun to watch and all the althetes are worlds better at their events than I will ever be.

In case you haven't heard, Visual Studio 2008 Service Pack 1 is available!

As you prepare to install the TFS 2008 SP1, I'd like to strongly recommend that you first run the BPA tool. From the Visual Studio Team System forums, I've seen two folks already have installation failures because their current system wasn't quite what TFS expected it to be. In one case, the team had modified the TFS AppPool accounts without using TFSAdminUtil so the old TFS service account that no longer existed was still referenced quite a few other places. In another case, the permissions of the TFS Setup user had been modified. I know that the BPA tool would have exposed the first issue and think it would have found the second, as well.

If you have a machine where you'll install both the VS SP1 and the TFS SP1, you should run the BPA tool before installing the VS SP1 or else you may not be able to use the TFS tools to fix any issues. This is because the two packs share several assemblies whose internal APIs may have had breaking changes between RTM and SP1. This would cause the TFS administrative tools to not function if they use those APIs.

Hopefully this will help folks avoid SP1 installation issues so you can get it up and running. It's very well worth it- I promise!

Apparently, if there's one thing that can get me blogging up a storm it's Hyper-V. I just can't get enough! The word of the day is "snapshots". Learn it, love it, and dance with joy.

I currently have two different main machines I've been prodding over the last two days. One is my development machine that I previously mentioned, and the other is a test machine where I'm testing install on workgroup, a domain, with different settings, etc. and storing states that I want to poke at more later - all by using snapshots. Without them, this work would have taken at least twice as long, either because Virtual Server's undo disks suffered performance-wise or I would be reimaging machines to much cleaner states than need be.

How can it get any better, you ask? Why, how about with a simple scriptably WMI interface that already has a great library of tools in a Codeplex project! Powershell plus Hyper-V makes the virtual world go 'round. If you do any manual Hyper-V management, check it out.

I just wrote this up for a coworker who asked me how to move a virtual machine from being hosted by Virtual Server to Hyper-V. First off, I'd like to say that I am a big fan of this type of upgrade. The first step to improving your virtualization experience is realizing that your experience could be improved, after all :)

In any case, it should be a fairly trivial move and would function on Virtual PC 2004/2007 machines, as well. The only thing you'll need is the vhd(s) of your current virtual machine.

1. Uninstall the VM Additions from the VPC prior to uninstalling Virtual Server
2. Copy the vhd file to your Hyper-V machine
3. Create a new VM using the VHD and start it
4. Once it starts up, open the Hyper-V view of the machine from the Hyper-V role in Server Manager
5. Select the Action menu, Insert Integration Services Disk, and proceed with the installation.

That should basically be it all you need -- everything else should just work. Note that you won’t be able to use external networking with a normal Hyper-V network adaptor until you have the Integration Services installed. If you need network before that you’ll have to shut the virtual machine off and add a Legacy Network Adaptor. For example, you would need this if you have Win2003 prior to SP1 since the Integration Services require SP2.

Enjoy, and happy virtualizing!

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!

I just had a somewhat random thought. Throughout the history of computing, we've come up with one syllable abbreviations for collections of bits. First there were "bytes", then "k", followed by "megs" and now "gigs". How will we shorten "terabytes" to a single syllable? I've come up with a few options but none really sound right.

Ters - pronounced like "terse", or maybe "tares", or even like "brrr" but with a 't' at the start and a 'z' sound at the end

Ts - hey, most of my coworkers wear T-shirts so this could work...

I think petabytes will be easier when we finally get there- "Pets". I'm sure there will be many great jokes about how many cats, dogs, and gerbils everyone has running their computers.

What's your vote? Have you heard anyone using any one syllable abbreviation for terabytes yet?

The title is a reference to "Spaceballs", of course.

Recently, I've been doing all of my development on a machine that doesn't exist. This both amuses me greatly and increases my productivity.

In case you haven't figured it out yet, I'm using a Hyper-V guest OS as a development machine with the host running Windows Server 2008 x64. The machine has two harddrives, one of which has two partitions (OS and programs on one, vhd files and other persistent data on the other), and the other of which is actually offline from the perspective of the host OS.

Instead, my development guest machine has complete control of this second drive and uses it as my version control enlistment store. That means that every time I roll back to my earlier snapshot of that machine to install the latest pre-release development tools and reattach the drive its contents match what TFS says it should have and I don't need to run a complete force get.

The host has 2 processors so I've set my development guest to have two as well (otherwise building would be slower). I haven't noticed any performance degradation in terms of TFS operations, build time, etc. on the dev box and have seen significant improvements in the time it takes me to get up to the latest dogfood bits (yum yum). In addition, while the dev box is getting prepared I can still be checking e-mail, the Visual Studio Team System forums, or other similar work on my host OS.

I've been running this configuration since a little before the Hyper-V RC was released and am very content. I've also spent a good deal of time testing TFS configurations on Hyper-V and am very pleased with the snapshotting functionality in particular. If you haven't installed the RTM version, do it now!

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.

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

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!

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!

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.

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.

1. Trial Edition
2. Workgroup Edition
3. Retail Edition
4. 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!

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.

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

The other day, someone not in the computer related fields asked me an interesting question. He wanted to know what I think the difference is between the human brain and a computer. Now, it's been a long time since I took biology, but I believe I remember most of it.

The first thing that jumped into my mind is that all of the parts of the human brain are neurons which happen to be specialized for one purpose or another. When you get right down to it, they're really all the same type of cell that just happens to be versatile enough to do everything from storing memories to guiding motor functions, from sorting and analyzing sensory input to performing complex computations.

In a computer, however, ever piece is highly specialized by design. We couldn't very well put a harddrive in where the CPU is supposed to be, or RAM in the place of a network card. Perhaps if we break everything down small enough we could claim that the parts all have the same sorts of roots, but the a capacitor functions very differently from a NAND gate.

Putting these thoughts in order, I decided that what I see as the main difference between the human brain and a computer is that the human brain has multiple orders of magnitude greater adaptability. A computer, in the meantime, is only as smart as the people who designed it and programmed the software that exercises the hardware. We might even add in the end user here since they might not exercise the full capabilities or may do something to further restrict the computer's capabilities (like not plug in the ethernet cable, disable certain settings, install unknown software, etc).

In summary, while my opinion of the human mind's potential is very high, I don't see computers as having the same capabilities. Perhaps some day we'll be able to decouple "computers" from any particular physical media and thus give them the ability to incorporate whatever components they need to perform a specific function at a given time. Still, the computers will only be as smart (or as dumb) as their programmers. As the poster on my wall reminds me daily, "Never underestimate the power of stupid people in large groups."