Grant Holliday

Update: If you’re after the TFS2008 version, see this blog post.

… Almost hands-free.

This 4-part series of blog posts describes how to automate the preparation, installation and configuration of a TFS 2005 (v1) for deployment in a Virtual Server environment. I will discuss how to save installation time and configure your servers for HTTPS/SSL without using the GUI.

This process is only good for TFS 2005 (v1) and will most-likely change for TFS 2008 (Orcas). I use a combination of netsh.exe, netdom.exe, sysprep, installation answer files, quiet installations, custom ISO files, resource kits, batch files and PowerShell scripts in this solution. There is no error checking and no guarantees that it will work in your environment.

All configurations are as vanilla as possible and I’ve provided links throughout the posts for further information on the tools and techniques.

Warning - Before you start

These posts are not a substitute for reading and understanding the latest version of the Visual Studio Team Foundation Installation Guide (TFSInstall.chm) . The content of this guide is very important and always being improved.

Reasons

Before starting anything these days, I take a moment to understand the reasons for doing so. I ask myself the questions:

• “What am I trying to achieve here?”
• “What does the end-goal look like?”

The reasons vary for why you might want to setup a hands-free TFS installation. Some examples that I could think of are:

• You might be a TFS consultant and you’ve done so many installs for customers that you’re sick of the long drawn-out process of following the latest TFSInstall.chm line-by-line. (not to mention getting all the latest media together and swapping DVD’s in and out).
• You might be an ‘IT Pro’ / ‘infrastructure guy’ and your time is at a premium. You hate sitting there watching progress bars move slowly across the screen just so that you can swap in the next DVD.
• You also might be building a farm of TFS servers… for …something *shhh* - you’ll have to wait for TechEd Australia (8-10 August 2007) for the big announcement :-)

For me, the reason to create these scripts was a mix of all these. I hate waiting for progress bars, I hate swapping media and I don’t trust other people to follow instructions. The more automation, the better. I wanted a consistent & repeatable process for creating a TFS server so that it’s easy to support and maintain.

But what about Etienne’s TFS Install Scripts?

Some of you may have already been using fellow VSTS MVP Etienne Tremblay’s TFS Install Scripts. Etienne’s scripts use a combination of VBS and a HTML ‘control’ page for filling in parameters. There’s nothing wrong with these scripts - the process is just not as automated as I would’ve liked. (and they’re written in .vbs which I have a personal dislike for).

Technologies in use

There’s a wide range of technologies that I’ve used to create this solution. They range from old-school batch files to the more recent PowerShell scripting runtime. Some of the different technologies are:

• Batch files
• PowerShell scripts
• Netsh.exe
• Netdom.exe
• Net.exe
• IIS 6.0 Resource kit
• SYSPREP 
• Virtual Server 2005 R2 SP1
• System Center Virtual Machine Manager (SC VMM) beta 2
• ISO files

Here they are:

• Introduction (this post!)
• Part 1 - Preparation & Configure network interfaces
• Part 2 - Building the ISO
• Part 3 - Installing Team Foundation Server unattended
• Part 4 - Script for Configuring TFS for HTTPS and SSL Only

Download the scripts

The latest version of all the scripts covered in this series can be download from this location:

• Download the latest scripts.

This blog post is part of a 4-part series. The other parts are:

• Introduction
• Part 1 - Preparation & Configure network interfaces
• Part 2 - Building the ISO
• Part 3 - Installing Team Foundation Server unattended
• Part 4 - Script for Configuring TFS for HTTPS and SSL Only (this post!)

Introduction

Nothing in this blog post is new or revolutionary. All the tools and techniques I’m about to show you have been around for quite some time.

Why would you want to configure TFS for HTTPS only?

There are three different scenarios for configuring TFS access:

1. Out-of-the-box configuration. TFS web services listen on HTTP port 8080 with no SSL
2. HTTP + HTTPS. TFS web services listen on HTTP 8080 and an additional port with SSL. (See MSDN Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL))
3. HTTPS only. TFS web services listen on HTTPS port 8080, or any other port. No HTTP access. (See MSDN How to: Configure Team Foundation Server for HTTPS and SSL Only)

The main reason you would want to configure SSL for TFS is so that you can expose your TFS server to the Internet and allow people to access from remote locations using an encrypted connection.

The scripts that form the rest of this post are the command-line equivalents of the guidance given in the above MSDN articles.

Can’t I already do this another way?

There’s nothing stopping you achieving this in other ways. You could use Microsoft ISA server to publish an internal TFS server securely. You could allow remote users access via a VPN.

All client-server and server-server communication for TFS is standard HTTP traffic. (Except the build server - it uses .NET Remoting on port 9191, until TFS 2008 when it will be WCF) .

Danger! Heed the warnings!

From How to: Configure Team Foundation Server for HTTPS and SSL Only:

If you configure Team Foundation Server to use any customized ports, such as HTTPS and SSL, you will not be able to install any service packs for Team Foundation Server after making those changes. Installation of service packs will fail. You must reconfigure Team Foundation Server to its default settings before you can apply service packs for Team Foundation Server.

Before we get started, you’ll need the following:

• Obtain a valid SSL certificate from your corporate root CA, or third-party root CA
• Make sure adsutil.vbs is available (Usually found in C:\Inetpub\AdminScripts\adsutil.vbs)
• Install the IIS 6.0 Resource Kit (docco)
• Install PowerShell
• Install SQL management tools (osql.exe)

Preparing your certificate for import

I’m not going to cover how to obtain a trusted SSL certificate, there’s plenty of other resources out there for that. Before you can use IISCertDeploy.vbs to deploy the certificate, you need to export the certificate as a *.PFX file.

Follow the instructions on TechNet Export a Server Certificate (IIS 6.0). At the end of it you should have a single *.PFX file and a password for the file.

IIS Web Site Identifiers

Each web site in IIS has a unique identifier. The Default Web Site is always ‘1′. We can find out the identifiers of the other web sites by issuing the following command:

set ADSUTIL=C:\Inetpub\AdminScripts\adsutil.vbs

cscript %ADSUTIL% GET W3SVC/1/ServerComment

cscript %ADSUTIL% GET W3SVC/2/ServerComment

cscript %ADSUTIL% GET W3SVC/3/ServerComment

cscript %ADSUTIL% GET W3SVC/4/ServerComment

Your results should be similar to the following. These are the identifiers used throughout the rest of these scripts.

• /W3SVC/1 Default Web Site : 80
• /W3SVC/2 SharePoint Central Administration : 17012
• /W3SVC/3 Team Foundation Server : 8080
• /W3SVC/4 TeamPlain Web Access : 81

Configure TFS Webservices for SSL

Before we can configure TFS web services to listen on port 8080 with HTTPS, we need to move the non-SSL ones out of the way to port 8081. We can do that by manipulating the “ServerBindings” key using the Adsutil.vbs SET command.

set ADSUTIL=C:\Inetpub\AdminScripts\adsutil.vbs

cscript %ADSUTIL% SET W3SVC/3/ServerBindings “:8081:”

Now we are ready to install the certificate and attach it to the Team Foundation Server web site. To do this, we use the IISCertDeploy.vbs script from the IIS 6.0 Resource Kit Tools. We’re going to configure SSL on the standard TFS port 8080.

set PFXFILE=your_certificate_private.pfx

set PFXPASS=yourCertificatepassword

cscript IISCertDeploy.vbs -q ON -c %PFXFILE% -p %PFXPASS% -i w3svc/3 -port “:8080:”

Configuring Digest + Integrated authentication

The next step in the MSDN guidance is to configure Integrated AND Digest authentication. This is done using the adsutil.vbs script again. We’re going to update the AuthFlags node in the IIS metabase.

• Digest Authentication = AuthMD5 = Bitmask 16
• Integrated Authentication = AuthNTLM = Bitmask 4

So adding the bitmasks, we end up with Bitmask 20.

cscript %ADSUTIL% SET W3SVC/3/AuthFlags 20

Now, if you had performed this operation through the IIS manager GUI, it would prompt you “do you wish to apply this setting to all children?” … Or something to that effect. That means that we have to apply the same setting to each folder like this:

cscript %ADSUTIL% SET W3SVC/3/Root/aspnet_client/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/3/Root/Build/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/3/Root/services/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/3/Root/VersionControl/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/3/Root/Warehouse/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/3/Root/WorkItemTracking/AuthFlags 20

Require Secure Channel (SSL)

The next step in the MSDN guidance is to configure the website to ‘Require Secure Channel’. This is done by modifying the AccessSSL node in the IIS metabase. Once again, we have to apply it to each subfolder as well.

cscript %ADSUTIL% SET /W3SVC/3/AccessSSL TRUE

cscript %ADSUTIL% SET /W3SVC/3/Root/aspnet_client/AccessSSL TRUE

cscript %ADSUTIL% SET /W3SVC/3/Root/Build/AccessSSL TRUE

cscript %ADSUTIL% SET /W3SVC/3/Root/services/AccessSSL TRUE

cscript %ADSUTIL% SET /W3SVC/3/Root/VersionControl/AccessSSL TRUE

cscript %ADSUTIL% SET /W3SVC/3/Root/Warehouse/AccessSSL TRUE

cscript %ADSUTIL% SET /W3SVC/3/Root/WorkItemTracking/AccessSSL TRUE

Configure SSL on the Default Web Site (SharePoint team sites)

We’re going to configure the Default Web Site to listen with HTTPS on port 443. This means that your users will be able to access their Windows SharePoint Services (WSS) team sites using https://server/sites/TeamProject.

We still need to perform the same steps as above, but on the Default Web Site with ID ‘1′.

:: Configure SSL on Default Website (Sharepoint team sites) on port 443

cscript IISCertDeploy.vbs -q ON -c %PFXFILE% -p %PFXPASS% -i w3svc/1 -port “:443:”

:: Require secure channel (SSL) on the Default website

cscript %ADSUTIL% SET /W3SVC/1/AccessSSL TRUE

:: Enable Digest + Integrated auth on Default Website

cscript %ADSUTIL% SET W3SVC/1/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/1/Root/Reports/AuthFlags 20

cscript %ADSUTIL% SET W3SVC/1/Root/ReportServer/AuthFlags 20

Configure SSL on the SharePoint Central Administration on port 17013

We’re going to configure SharePoint Central Administration on port 17013. The normal HTTP port is 17012, so we can’t use that port without moving it. The steps are the same again

:: Configure SSL on SharePoint Central Administration on port 17013

cscript IISCertDeploy.vbs -q ON -c %PFXFILE% -p %PFXPASS% -i w3svc/2 -port “:17013:”

:: Require secure channel (SSL) on the SharePoint Central Admin site

cscript %ADSUTIL% SET /W3SVC/2/AccessSSL TRUE

Updating TFS with the new server settings

Proceed with caution. Even though I tell everybody “DON’T _EVER_ TOUCH THE TFS DATABASES”, this case is OK - because MSDN tells us so :). Be sure to take a backup though.

At this time, we can also specify a Fully Qualified Domain Name (FQDN) that we want TFS to use at all times. Why would you do this? Well, the default TFS install usually only uses just the computer name in any of it’s settings. That means if you’re not connected to the VPN, or ISA doesn’t perform link translation correctly, you will end up with http://servername/ URLs that nobody can access from external. In the following sections, we’re going to change all the URLs that TFS uses to their full internet names with the https:// prefix. e.g. https://servername.domain.com/

SET FQDN=servername.domain.com

Updating the Reporting Services Server location

The Reporting Services virtual directories /Reports and /ReportServer are located in the Default Web Site. If we want our users to be able to access reports over a secure connection, we need to tell TFS to use this new location.

This location is stored in the registry and we can update it using reg.exe from C:\Windows\System32

:: Update the Registry Key for SQL Report Server

::HKLM\Software\Microsoft\VisualStudio\8.0\TeamFoundation\ReportServer - Key

reg add “HKLM\Software\Microsoft\VisualStudio\8.0\TeamFoundation\ReportServer” /v Key /d “https://%FQDN%” /f

Notes:

• The /v parameter specifies the “Value” under the selected key to update. It’s a little confusing in this case, because the value is called “Key”.
• The /d parameter specifies the data for the new value.
• The /f parameter specifies that we want to force the overwrite of existing values

Updating the TfsIntegration database with the new SSL URLs

Now we need to tell TFS the new URLs. This is done by updating the tbl_service_interface table in the TfsIntegration database. We can do this from the command-line by using osql.exe which is included with the SQL Server Tools. If you have enabled SSL on different ports, don’t forget to update these URLs appropriately.

:: Update the integration table with the FQDN and SSL urls

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’https://%FQDN%/ReportServer/ReportService.asmx‘ WHERE name=’ReportsService’”

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’https://%FQDN%/Reports‘ WHERE name=’BaseReportsUrl’”

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’https://%FQDN%:17013/_vti_adm/admin.asmx‘ WHERE name=’WSSAdminService’”

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’https://%FQDN%‘ WHERE name=’BaseServerUrl’”

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’https://%FQDN%/sites‘ WHERE name=’BaseSiteUrl’”

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’https://%FQDN%/ReportServer‘ WHERE name=’DataSourceServer’”

osql -E -d TfsIntegration -Q “UPDATE dbo.tbl_service_interface SET url=’\\%FQDN%\sites‘ WHERE name=’BaseSiteUnc’”

:: Update the subscriptions table with the FQDN and SSL urls

:: BuildCompletionEvent

osql -E -d TfsIntegration -Q “UPDATE tbl_subscription SET address=’https://%FQDN%:8080/WorkItemTracking/v1.0/Integration.asmx‘ WHERE id=’1′”

:: DataChangedEvent

osql -E -d TfsIntegration -Q “UPDATE tbl_subscription SET address=’https://%FQDN%:8080/WorkItemTracking/v1.0/SyncEventsListener.asmx‘ WHERE id=’2′”

:: ProjectCreatedEvent

osql -E -d TfsIntegration -Q “UPDATE tbl_subscription SET address=’https://%FQDN%:8080/WorkItemTracking/v1.0/warehousecontroller.asmx‘ WHERE id=’3′”

:: DataChangedEvent

osql -E -d TfsIntegration -Q “UPDATE tbl_subscription SET address=’https://%FQDN%:8080/WorkItemTracking/v1.0/Integration.asmx‘ WHERE id=’4′”

Notes:

• The command line parameters are case sensitive.
• The “-E” parameter specifies that we should connect to SQL using Integrated authentication / Trusted connection.
• The “-d” parameter specifies the database that we want to connect to
• The “-Q” parameter specifies that we want to execute the following command and then exit.

Update Reporting Services Server to Require SSL

This is where things get interesting. We have to update an XML app.config file with a new value. To do this, I have created a simple powershell script to update the value which we then call from our batch script.

UpdateRSConfiguration.ps1

$file = “c:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\rsreportserver.config”

$config = [xml] (get-content $file)

$node = $config.Configuration.SelectSingleNode(”Add[@Key='SecureConnectionLevel']“)

$node.Value = “3″

$config.Save($file)

I really love how simple this is. Can you imagine doing something like this in a normal batch file?

I’ll explain what this script is doing line-by-line.

• Line 1: Set a variable $file to the location of the Reporting Services app.config file
• Line 2: Load the contents of $file as XML into the $config variable
• Line 3: Select the <Add Key=”SecureConnectionLevel” Value=”X” /> XML node from the <Configuration> node of the config file stored in the $config variable.
• Line 4: Update the Value of the node to our new value.
• Line 5: Save the contents of the $config variable back out to the config file on disk.

Now we need to call this PowerShell script from our batch file. This is done by passing the script from the standard input.

:: Update RSReportServer.config to require ssl

powershell -command - < UpdateRSConfiguration.ps1

Update TFSServerUrl in the three other app.config files

There are three other app.config files that need updating, and we’ll do those in the same way as above. These scripts could easily be re-factored into one generic script, but I’ve kept them separate because they are each subtly different.

The config files that need to be updated are:

• c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Web.Config
• c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\CoverAn\CoverAn.exe.config
• c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TFSServerScheduler\TFSServerScheduler.exe.config

Each of them needs to end up with a TfsNameUrl parameter. TFSServerScheduler.exe.config doesn’t have a TfsNameUrl parameter to start with, so we need to rename the BisDomainUrl key as well as set the value.

UpdateTFSWebConfig.ps1

$file = “c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Web.Config”

$url = “https://servername.domain.com:8080”

$config = [xml] (get-content $file)

$node = $config.configuration.appSettings.SelectSingleNode(”add[@key='TFSNameUrl']“)

$node.value = $url

$config.Save($file)

UpdateCoverAnConfig.ps1

$file = “c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\CoverAn\CoverAn.exe.config”

$url = “https://servername.domain.com:8080”

$config = [xml] (get-content $file)

$node = $config.configuration.appSettings.SelectSingleNode(”add[@key='TFSNameUrl']“)

$node.value = $url

$config.Save($file)

UpdateTFSSchedulerConfig.ps1

$file = “c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TFSServerScheduler\TFSServerScheduler.exe.config”

$url = “https://servername.domain.com:8080”

$config = [xml] (get-content $file)

$node = $config.configuration.appSettings.SelectSingleNode(”add[@key='BisDomainUrl']“)

$node.key = “TFSNameUrl”

$node.value = $url

$config.Save($file)

Now we need to call these three update scripts, just like we did with the Reporting Services update script:

:: Update app.config files with HTTPS TFSServerUrl

powershell -command - < UpdateTFSWebConfig.ps1

powershell -command - < UpdateCoverAnConfig.ps1

powershell -command - < UpdateTFSSchedulerConfig.ps1

Configuring Team Plain Web Access for SSL

Just like all the other websites, we can configure Team Plain Web Access in exactly the same way. In this case, I’ve configured it with HTTPS on port 82. This is because port 443 is already taken by the Default Web Site / SharePoint.

:: Configure SSL on Team Plain Web Access SSL port 82

cscript IISCertDeploy.vbs -q ON -c %PFXFILE% -p %PFXPASS% -i w3svc/4 -port “:82:”

:: Require secure channel (SSL) on the Team Plain Web Access website

cscript %ADSUTIL% SET W3SVC/4/AccessSSL TRUE

Summary

So there you have it. In this final part, we have completed all the steps of the MSDN guidance How to: Configure Team Foundation Server for HTTPS and SSL Only using only the command-line. We’ve used batch, VBS, PowerShell and even SQL scripts, but in the end we got the result we were after.

Download the scripts

The latest version of all the scripts covered in this series can be download from this location:

• Download the latest scripts.

Feedback

If you find these scripts useful please blog about them or leave a comment on the blog posts. If you want to provide some feedback please leave a comment here or send me an email via the contact form.

This blog post is part of a 4-part series. The other parts are:

• Introduction
• Part 1 - Preparation & Configure network interfaces
• Part 2 - Building the ISO
• Part 3 - Installing Team Foundation Server unattended (this post!)
• Part 4 - Script for Configuring TFS for HTTPS and SSL Only

Introduction

In part 3 of 4 of my Hands-Free TFS Installation series, I’m going to cover two things:

• How to perform an unattended installation of TFS, and
• The shortcomings of the TFS installers

If you’re only interested in building a server once, or you just want a repeatable process for doing so, this is the part for you. Before you start this part, you may want to read Part 2 on Building the ISO - as the file paths all relate to this.

As you should know from reading the latest version of the Visual Studio Team Foundation Installation Guide, there are a number of steps that must be performed before you can start installing TFS. It’s not a simple “throw in the DVD and run setup.exe”.

The steps that I will be covering in this post are:

• Creating user accounts with appropriate permissions
• Installing SQL Server 2005
• Installing SQL Server 2005 SP2
• Installing Windows SharePoint Services 2.0 SP2
• Installing .NET Hotfix (913393)
• Installing a Single-Server TFS
• Installing Team Explorer (the TFS Client)
• Installing TFS SP1 + Hotfix
• Installing Team Suite SP1 (to patch Team Explorer)
• Installing Team Plain Web Access

Creating user accounts with appropriate permissions

This is easily scriptable. The two commands we will use are:

• the “net.exe” command from C:\Windows\System32
• the “NTrights.exe” command from the Windows 2003 Resource Kit

First of all, we create the 2 additional user accounts to the TFSSETUP user account.

net user TFSSERVICE * /DOMAIN /ADD /EXPIRES:NEVER

net user TFSREPORTS * /DOMAIN /ADD /EXPIRES:NEVER

Some notes on the syntax:

• The ‘*’ parameter signifies that we want to be prompted for a password. You could enter a password here and not be prompted.
• The ‘/DOMAIN’ parameter signifies that it’s a domain account we’re creating
• The ‘/ADD’ parameter signifies that it’s a new user
• The ‘/EXPIRES’ parameter signifies when the account password should expire. Since this is a service account and we want to avoid the operational headaches of changing passwords, we set this to ‘NEVER’. Your situation may be different.

Assigning appropriate permissions

The service accounts used need to be given the ‘Log on as a service’ right. This is usually configured by going to Control Panel | Administrative Tools | Local Security Policy | Computer Settings | Security Options | Allow Log on as a service.

This can also be done from the command-line with the following commands.

ntrights -u TFSSERVICE +r SeInteractiveLogonRight

ntrights -u TFSREPORTS +r SeInteractiveLogonRight

See How to Set Logon User Rights with Ntrights.exe for more information.

Installing SQL Server 2005

Fortunately the TFS media includes a setup answer file for installing SQL server. This means that we can run an unattended installation with no user input.

The answer file is called ‘SQL2005ForATDT.ini’ (for a single-server installation) and it’s located in the root of the TFS media. However in our case, we’re using a custom ISO file, so it’s in a subfolder.

The other thing to consider is that you need the \Servers directory AND the \Tools directory for SQL setup to succeed without warnings. This is because the answer file installs the SQL 2005 management tools.

The command-line for installing SQL is:

D:\SQL\Servers\setup.exe /qb /settings D:\TFS\SQL2005ForATDT.ini

Installing SQL Server 2005 Service Pack 2

Unfortunately SQL Server 2005 does not support slipstreaming of service packs (see connect). That means that you have to run the SP2 installer which takes almost as long as the initial installation!

The good news is that this is seen as “key functionality and planned in the next major release: SQL Server 2008“, so this will reduce installation times considerably.

Now before we install SP2, we need to stop the SQL Browser service, set it to automatic startup and start it later. So the steps become:

sc stop SQLBrowser

sc config SQLBrowser start= auto

D:\SQLSP2\SQLServer2005SP2-KB921896-x86-ENU.exe /quiet /allinstances

sc start SQLBrowser

Installing Windows SharePoint Services 2.0 SP2

This one is a no-brainer. No unattended script required, just command line parameters.

D:\WSS\stsv2_ENU.exe /C:”setupsts.exe /remoteSql=yes /provision=no /q”

We also ensure that NTLM / Integrated authentication is in use.

cscript C:\Inetpub\AdminScripts\adsutil.vbs set w3svc/1/NTAuthenticationProviders “NTLM”

Installing .NET Hotfix (KB913393)

Another easy one. We use the standard “/q” parameter for a “quiet” install. More on this later.

D:\TFS\KB913393\NDP20-KB913393-X86.exe /q

Installing a Single-Server TFS

Up until this point everything has been Hands-Free. Unfortunately the TFS server bits can’t be installed without the GUI. So we start the wizard, fill in our service accounts and passwords, configure SMTP settings and let it run.

We also use the “start.exe /wait” command so that our batch file waits for setup to complete before continuing.

start /wait D:\TFS\atdt\setup.exe

Installing Team Explorer (the TFS Client)

I always find it useful to have Team Explorer installed on my TFS servers. There are two reasons for this:

• It’s useful for configuring user permissions and debugging builds, etc.
• Team Explorer includes the Microsoft.TeamFoundation.* assemblies which many third-party tools rely upon.

Unfortunately it’s a GUI installer as well. Aaron Stebner has written a blog post on How to perform a silent install of Visual Studio 2005 Team Explorer. Although I could’ve made this a silent installation it’s not officially supported, so it’s best not to.

The command-line becomes:

start /wait D:\TFS\tfc\setup.exe

Installing TFS SP1 + Quiesce-GDR Hotfix

Two more easy installations using the standard “/q” for “Quiet” installation.

D:\TFS_SP1\VS80-KB919156-v2-X86.exe /q

D:\TFS_SP1\TFS_SP1_VS80sp1-KB926738-X86-ENU.exe /q

Installing Team Suite SP1 (to patch Team Explorer)

Although I’m not 100% sure on whether this is required or not, I thought it would be a good idea to install the Visual Studio 2005 SP1 patch to patch Team Explorer.

This is a mammoth path and can take quite some time to install if you have the full Visual Studio Team Suite installed. Fortunately Heath Stewart comes to the rescue with his blog post on Save time and Space for VS 2005 SP1 by disabling the patch cache.

reg export HKLM\Software\Policies\Microsoft\Windows\Installer %temp%\installer.reg

reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /t REG_DWORD /d 0 /f

net stop msiserver

start /wait D:\TFS_SP1\TeamSuiteSP1_VS80sp1-KB926601-X86-ENU.exe /q

reg delete HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /f

reg import %temp%\installer.reg

net stop msiserver

del /q %temp%\installer.reg 2>nul

If your server doesn’t have enough “contiguous virtual memory” available, the patch installation may fail with:

Error 1718. File Filename was rejected by digital signature policy.

See this KB925336 article for more information.

Installing Team Plain Web Access

The last installation step we want to perform is Team Plain Web Access (or whatever it gets renamed to in the next release).

Unfortunately the v2.0 RC doesn’t support unattended installation, so we run the GUI.

D:\WEB\TeamPlain-Web-2.0-RC.msi /q

The script

So putting it all together, we end up with the following script. Remove the pauses once you confirm that it works for you.

SET TFSSERVICEPW=strongpassword

SET TFSREPORTSPW=strongpassword

:: ############# User accounts

net user TFSSERVICE %TFSSERVICEPW% /DOMAIN /ADD /EXPIRES:NEVER

net user TFSREPORTS %TFSREPORTSPW% /DOMAIN /ADD /EXPIRES:NEVER

ntrights -u TFSSERVICE +r SeInteractiveLogonRight

ntrights -u TFSREPORTS +r SeInteractiveLogonRight

pause

:: ############# SQL 2005

:: # Run SQL2005 setup unattended

D:\SQL\Servers\setup.exe /qb /settings D:\TFS\SQL2005ForATDT.ini

pause

:: # Stop SQLBrowser service before SP2 install

sc stop SQLBrowser

sc config SQLBrowser start= auto

:: # Run SQL2005 SP2 unattended

D:\SQLSP2\SQLServer2005SP2-KB921896-x86-ENU.exe /quiet /allinstances

:: # Change SQLBrowser service to automatic statup and start

sc start SQLBrowser

pause

:: ############ WSS 2.0 SP2

D:\WSS\stsv2_ENU.exe /C:”setupsts.exe /remoteSql=yes /provision=no /q”

cscript C:\Inetpub\AdminScripts\adsutil.vbs set w3svc/1/NTAuthenticationProviders “NTLM”

pause

:: ############ .NET Hotfix

D:\TFS\KB913393\NDP20-KB913393-X86.exe /q

pause

:: ############ TFS Single-Server install

start /wait D:\TFS\atdt\setup.exe

pause

:: ############ TFS Team Explorer

start /wait D:\TFS\tfc\setup.exe

pause

:: ############ TFS SP1

:: # TFS Quiescene patch

D:\TFS_SP1\VS80-KB919156-v2-X86.exe /q

pause

:: # TFS SP1

D:\TFS_SP1\TFS_SP1_VS80sp1-KB926738-X86-ENU.exe /q

pause

:: # TeamSuite SP1 - disable patch cache to speed it up

reg export HKLM\Software\Policies\Microsoft\Windows\Installer %temp%\installer.reg

reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /t REG_DWORD /d 0 /f

net stop msiserver

start /wait D:\TFS_SP1\TeamSuiteSP1_VS80sp1-KB926601-X86-ENU.exe /q

reg delete HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /f

reg import %temp%\installer.reg

net stop msiserver

del /q %temp%\installer.reg 2>nul

pause

:: ############ Team Plain

D:\WEB\TeamPlain-Web-2.0-RC.msi /q

Summary

In this post we have learnt how to automate the setup of users and perform unattended installations of most of the TFS components.