VSTS/TFS 2010 Beta 1 Installation
See a good summary of the 2010 system requirements here. Click download to get the PDF.
Here's the scope of my install:
Single-server TFS install
TFS server:
Windows Server 2008 Enterprise 64-bit SP2
SQL Server 2008
Test Agent Controller
Lab Management server SCVMM 2008 (Windows Server 2008 64-bit v1/SP1 - I used SP2 per some assurance from the MS Lab Mgmt team in India. It did cause some security related issues, but I was able to figure out hoe to complete the installation - see below
Development workstation XP SP3 (VSTS 2010 Beta 1 Team Suite)
NOTE: the CHM TFS Beta 1 install guide specifies WS08 R2 for Lab Management (LM). This is incorrect. See below.
So, MS does a pretty good job with the procedures. Though TFS now includes so many pre-requisites, that its like a maze or doing a jigsaw puzzle to figure out the right order. For example, LM 1st then TFS, except for the VMM console, maybe? A consolidated checklist would be nice. Anyway, here's the order I'm taking:
- OS on TFS and LM servers (I used a VM for TFS, but this is not permitted for the LM server)
- IIS on the TFS server
- Hyper-V on the LM server
- Created VM on the LM server using Hyper-V. NOTE: had to reconfigure the machine bios to support Hyper-V. The HW requirements for Hyper-V are very specific!
- Obtained TFSService account
- SQL Server 2008 on the TFS server. NOTE: I used one domain service account - TFSService - for everything. In other words, I did not use a second, TFSReports account.
- I used the MSDN version of Sys Center VMM 2008. I had to go and find the install procedure (here) and am glad I did. You need to consider installation alternatives for SQL Server, the default share location, service account and ports.
- I had SCVMM install its own SQL Server (05) instance for me, which then required a separate follow-on installation of SQL Server 05 SP3 (x64). HINT: reboot before you install SP3, or you will have to reboot and reinstall SP3
- I went ahead and took the default share, although it was stated as a best practice not to do so. It seemed that this was for space and performance optimization, which is not something I'm worrying about for the beta
- I used a domain service account because I had no idea whether the "namespace conflict" might apply to my situation
- I used the default ports, but again, there was some vague language about that not being the best practice, for security reasons. The main thing is that you have to use the same ports for the VMM console installs
-
I then installed the VMM Console, np, but then you must configure VMM for Lab Mgmgt using the VMM console. This was also no problem, but given I have about 20 different procedures spread all over my desk I almost missed doing it.
-
I installed the VMM update Microsoft System Center Virtual Machine Manager 2008 KB959596
-
I finally got to the install of TFS. I used the default configuration. NOTE: you must continue with the TFS configration as a follow-on step
-
The TFS configuration went fine (it took about 15 minutes).
OUCH! Then I found the VSTS 2010 Beta1 Lab Management Setup Guide. This is a 25 page document and there is a lot of duplication with the MS library install procedures I've been using. Never the less, this guide is essential to the configuration of the SCVMM shares and the configuration of TFS project collections, team projects, build services, the test agent controller and the VMS themselves. All needed to run and use Lab Management.
So, ...
-
The first thing I had to do from the guide was create 2 shares on the SCVMM server, Golden VMs and Environment Templates
-
Then using the SCVMM console, I added those library shares
-
Applying the MS updates was largely futile. Some came back with NA and some I couldn't get from the MS update site. But attempted all the updates I could get and I think only one (959956) was applicable (worked)
-
Starting with "Create and configure project collection for Lab" (step 9 on page 12) I was in new territory with the guide. When doing this select a collection name for and appropriate to the team projects that it will contain. Don't name it "Lab Management" like I did. Once I figured this out I created another collection with a good name and stopped the first one. I don't think they can be deleted.
See note below on problem with verification step: unable to write to lab host computer registry.
-
Configure the user accounts for the collection (step 10); np.
-
Install the VSTS 2010 Beta 1 Team Suite client on my development workstation (XP SP3) - finally! - and Team Explorer installs with it. Yea! Then create one or more team projects.
-
Set up access/permissions needed for Lab Mgmt (step 12)
-
The guide (step 13) then describes installing the build service, but I already did that as part of the my TFS install.
-
I did have to then Configure the build controller (step 14). I did this from the TFS administration console by selecting Team Foundation Build and then following the procedures from the guide, though they are pretty hard to follow. NOTE: I think the person who wrote the guide was getting pretty tired by this point (I certainly am from reading it).
-
Then I installed the Test Agent, which is really two installs, the 1) Controller component and the 2) Load component. Be sure to install them both: controller(DTEC) then agent(DTEA). I used the same (one and only domain service account). NOTE: I installed these on the TFS server.
-
The from the Computer Mgmt console on the TFS server, I configured the users for the test agent controller (step 16)
-
Then added the test agent controller to the collection from my development desktop computer using the (new) MS Test and Lab Manager (step 17). NOTE: the UI is really different. Why couldn't it use the same look and feel as VS? Why couldn't it be integrated into VS? Even if the primary user is a tester, still it seems it would be better the same UI look and feel.
-
So, picking up where I left off on Friday, I find that I need to install yet another and different piece of SW on the VM itself: the Lab Agent. I had already created a VM using the Hyper-V manager.
-
Next, install the Test Agent (see above) on the VM. I had already added the service account to the admin group on the VM so I could use it to run the Test Agent as required. I used the TFS server as the controller machine. NOTE: the guide really does not have a step 22; you didn't accidently delete the text
-
There is an error in the TFS Beta 1 install CHM. I spent a couple of days trying to get my VM added to the collection. I connected with the MS Lab Mgmt team in India and found I had installed the wrong OS to support SCVMM 2008. I installed WS08R2. The CHM 'Scenario: Installing Lab Management' page says to install R2. The VSTS 2010 Beta1 Lab Management Setup Guide says to install WS08 64-bit (which I understand is correct, and I corrected this at the beginning of this article).UPDATE: MS says that 2010 Lab Mgmt Beta 1 will run on WS08 SP2.
-
OK. So, once I had created the VM using Hyper-V on WS08 SP2, the next step was to reinstall the Lab Agent (vstf_labagent.exe) and the Test Agent. I also plan to install the Build Service on the VM client as well. But, I forgot to first install XP SP3 (my base image had SP2) and the .NET 4.0 installation failed with a generic error "error code -2147467259 for this component means 'unspecified error'."
-
After installing XP SP3 on the VM client, .Net 4.0 (as part of the Lab Agent installer) installed fine as did the Lab Agent.
-
Than on the VM I installed the Test Agent (2 installers: DTEC_Setup and DTEA_Setup) and the build service, which requires the 2+ GB TFS setup to install! It seems like there is huge redundancy in the footprint for these installers and together they take a lot of time (days) to work through: more than the rest of the TFS install together. Big need for some improvement here!
-
The first several times I tried to create a template from the VM it failed and deploying a VM from the template involved much trial and error and many more steps than in the guide.
-
I had to reinstall TFS and re-create the Team Collection because things got so muddled. However, with WS08 SP2 on the Lab host computer I got a warning of "unable to write to lab host registry!" The relevant user account was in the admin group on the Lab host computer and I was able to grant permissions and change local security policy so that I could regedit the Lab host locally and remotely. I still got the warning, but was able to create the team collection and use it (so far).
-
To get the template creation to work I had to take the intial VM off the network to allow for a blank administrator password. I found that this was the only way I could get the VM deployment from the template to work.
-
To deploy the VM I had to provide the machine name and OS product key in the Virtual Machine creation wizard advanced setting dialog
-
I had to manually connect to the VM while it was creating and click the Next button while it just waited for minutes on the XP install wizard dialog. This might not have been needed as the creation script may have eventually done this.
-
I was then able to successfully complete the last step in the Guide, "Create a Virtual Environment" (page 23)
I am now ready to begin the evaluation of the VSTS 2010 beta, which will involve the development of training walk-throughs, evaluation procedures and demo prototypes.
I will enter and report on problems through the MS Connect and MSDN Forum sites.
SUMMARY
The CHM install guide specified WS08 R2 and the Guide did not
The steps in the guide were incomplete
On a positive note, I did get good support from the MS Lab Mgmt team in India and want to especially thank Vijay for his help and attention. I hope my experience will help them tighten up and improve the next version of the installation procedures.
- By bhardister at 06/23/2009 - 23:05
|