Run the service setup on any server of you choice. We test installing on the application tier of TFS and a standalone TfsBuildLab server. Make sure you change the account that runs the service to something other that local system since you need to give this account permissions to use the database.

Optionally create a database named TfsBuildLab, this is performed by the sevice setup if no database with the name you provide during setup exists already.
  1. Run the CreateDatabase.sql script on your database to create the needed tables.
  2. Run the CreateLogin.sql script to setup the needed security (don't forget to replace the string DOMAIN/ACCOUNT in the script with the account that is running your service).
  3. Run the InsertData.sql script on your database to insert the needed data.


The service reuqires that you have access to either a SQL Server 2005 or a SQL Server 2000 database server where it can install its database. Also you need to install .NET Framework 2.0 and .NET Framework 3.0 (this also limits you to running either Windows XP and Windows Server 2003, we currently do not test on Windows Vista).


The following section explains the various settings available in the config file of the service:
  • tfsUser the identity (username) that the service should use when connecting to the TFS server, this needs to be a valid TFS account (if you want to use the auto registration functions this needs to be a member of the Server\Team Foundation Adminstrators group).
  • tfsPassword The password for the bove mentioned identity (username).
  • tfsServerAddress Fully qualified address for the TFS server (http://<servername>:<port>
  • buildLabPort The port used by the TfsBuildLab service for event notification subscriptions.
  • buildLabAdminPort The port used by the TfsBuildLab service to expose it's administrative services.
  • tfsBuildLabConnectionString The connection string to the TfsBuildLab database, for a single server installation the connection string would be the following "Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TfsBuildLab;Data Source=(local)"
  • RetentionPoliciesOnlyCleanupDropLocation This setting allows you to turn on that the retention policies only will remove the actual build drop when enforcing the policies.
  • AutoRegisterNotifications This setting allows you to turn of the automatic registration of notifications, we introduced this since this feature requires the account used to access the TFS server to be a memeber of the administrators group.
  • QueueManagementInterval The poll frequency for checking the build queue (in milliseconds, defaults to 60000)
  • ScheduleManagementInterval The poll frequency for checking for new schedules (in milliseconds, defaults to 60000) this is only used if the service is started up without and schedules in the database.
  • RetentionPolicyEnforcementInterval The poll frequency for checking for old builds to purge (in milliseconds, defaults to 3600000)
  • smtpServerAddress The address for the SMTP server used for sending out CI alerts.
  • CINotificationSenderAddress The email address to that will be the sender of the CI info mails when the build breaks.
  • CIAdministrativeNotificationEmail The email address that will receive a copy of all CI info mails that are sent.
  • CINotificationWorkItemType The TFS workitem type to create when a CI build fails.
  • CINotificationWorkItemFields A list of fields and their values that are required to be filled out when creating the workitem type above this list is separated by semicolon. T he result would look like this "Microsoft.VSTS.CMMI.Symptom=Test;Microsoft.VSTS.CMMI.StepsToReproduce=YAT" (in a CMMI project where the feilds symptom and stepstoreproduce are mandatory)


If you encounter problems using the service you can shut it down and add the following section to the config file and you will get a detailed log to help tracking down the problems:

<trace autoflush="false" indentsize="4">
<add name="TextLog" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\\tfsbuildlab.log" />

Problems with auto registration of notifications

If you encounter problems with the registration of build and checkin notifications when starting the service and if you are unable to give the apropriate rights you can turn off auto registration (see above) and do the registration yourself the following way:

BisSubscribe.exe /eventtype BuildStatusChangeEvent /address http://[TFSBUILDLABSERVER]:[PORT] / /deliveryType Soap /server http://[TFSSERVER]:[PORT]
BisSubscribe.exe /eventtype BuildCompletionEvent /address http://[TFSBUILDLABSERVER]:[PORT] / /deliveryType Soap /server http://[TFSSERVER]:[PORT]
BisSubscribe.exe /eventtype CheckinEvent /address http://[TFSBUILDLABSERVER]:[PORT] / /deliveryType Soap /server http://[TFSSERVER]:[PORT]

Problems with http.sys and exposing WCF services

The easy way around this is to make sure that the account running the service is a member of the local administrators group. If this is not possible you can grant the correct permissions to the account using one of the following ways:
  • Use a tool called HttpNamespaceManager which you can find here just make sure that you have selected an account when you are about to modify the permissions and grant execute persmissions to your service account.
  • Make sure that the url you provide follows the following syntax {http://*:[TfsBuildLabPort]/} (the last trailing slash is crucial).
  • Make sure that when adding permission you select the account specified after you add it since otherwise you can add permissions (select GenericAll).
  • Manually configure it as described by Keith Brown in his article here there are some syntax problems (atleast for us) when following this article (also you'll need to determine the sid so for clarity it should look like this:
  • Retrive the sid using a tool called getsid (it's included in the windows resource kit) to retrieve a sid you need to specify two servers (they can actually be the same server): getsid \\[server] [domain]/[account] \\[server] [domain]/[user]
  • Once you have a sid run httpcfg (make sure the port is the one you have specifed in your config as buildLabPort and that the sid is the one you retrieved in the previous step (note the command should return 0 if successful): httpcfg set urlacl /u http://+:8000/ /a D:(A;;GX;;;S-1-5-21-1681502023-2202157333-1552196959-1028)
  • On Windows Vista you can use the simpler netsh.exe command instead of httpcfg.exe: netsh.exe http add urlacl url=http://+:8000/ user=domain\user

Last edited Oct 14, 2007 at 6:59 PM by PeterBlomqvist, version 11


No comments yet.