Oct 13, 2007 at 9:15 AM
Edited Oct 13, 2007 at 9:19 AM
Please post issues with you installation experience here... I'm going to try to move the conversation on the wiki page over here as well (it's much easier for us to monitor and respond then).
Oct 13, 2007 at 9:19 AM
jimeobrien wrote Aug 1 at 6:28 PM
Hi there, i'm after some installation advice.

i've had a go at installing tfsbuildlab for our development team, and can't seem to get the admin, or notify client working (exception text shown below).

i'm assuming that the "TFSBuildLab" key in both clients refers to the "buildLabAdminPort" in the service config.

this is my service config:

add key="tfsUser" value="ourdomain\tfsservice"
add key="tfsPassword" value="password"
add key="tfsServerAddress" value="tfsserver:8080"
add key="smtpServerAddress" value="exchangeserver"
add key="buildLabPort" value="9000"
add key="buildLabAdminPort" value="9001"
add key="tfsBuildLabConnectionString" value="Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TfsBuildLab;Data Source=(local)"
add key="QueueManagementInterval" value ="1000"
add key="ScheduleManagementInterval" value ="10000"
add key="RetentionPolicyEnforcementInterval" value ="60000"
add key="CINotificationWorkItemType" value=""
add key="CINotificationWorkItemFields" value=""
add key="CINotificationSenderAddress" value="email@email"
add key="CIAdministrativeNotificationEmail" value="email@email"
add key="CINotificationResolvementLDAPPath" value=""

any suggestions would be appreciated.



See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

                            • Exception Text **************
System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the serviceDebug configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at 0:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Callista.BuildLab.Core.IAdministration.ListTeamProjects()
at Callista.BuildLab.NotifyClient.Program.configContextMenuItem_Click(Object sender, EventArgs e)
at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
at System.Windows.Forms.MenuItem.MenuItemData.Execute()
at System.Windows.Forms.Command.Invoke()
at System.Windows.Forms.NotifyIcon.WndProc(Message& msg)
at System.Windows.Forms.NotifyIcon.NotifyIconNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Oct 13, 2007 at 9:21 AM
Hymee wrote Aug 3 at 12:45 AM

I'm getting the same error reported as Jim. This is looking like a valuable tool. Can't wait to get it working properly. I've got this all instaled on a Win2k3 Server that is my TFS box. All the DB setup sent fine. The TFSBuildLab service is installed and starts OK. I cant see anything obvious in my config file(s).

Anyone with some words of wisdom?

Oct 13, 2007 at 9:21 AM
Hymee wrote Aug 3 at 5:54 AM
I have since noticed that the Event Log reports an error when the TfsBuildLab service is sarting:

3/08/2007 1:48:05 PM BuildManager failed to initialize due to [HTTP could not register
URL http://+:8000/. Your process does not have access rights to this namespace
(see for details).]

For more information, see Help and Support Center at

This seems to point oto potential problem in my config file, but I see nothing obvious:

<?xml version="1.0" encoding="utf-8" ?>
<add key="tfsUser" value="TFSServer" />
<add key="tfsPassword" value="TFSPassword" />
<add key="tfsServerAddress" value="http://pqdvvs01:8080" />
<add key="smtpServerAddress" value="" />
<add key="buildLabPort" value="8000" />
<add key="buildLabAdminPort" value="8001" />
<add key="tfsBuildLabConnectionString" value ="Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TfsBuildLab"/>
<add key="QueueManagementInterval" value ="1000"/>
<add key="ScheduleManagementInterval" value ="10000"/>
<add key="RetentionPolicyEnforcementInterval" value ="60000"/>
<add key="CINotificationWorkItemType" value=""/>
<add key="CINotificationWorkItemFields" value=""/>
<add key="CINotificationSenderAddress" value=""/>
<add key="CIAdministrativeNotificationEmail" value=""/>
<add key="CINotificationResolvementLDAPPath" value=""/>

Oct 13, 2007 at 9:23 AM
HowardvanRooijen wrote Aug 9 at 12:39 AM
Has anyone resolved this issue yet? I'm getting it too and if I can't resolve it soon I'm going to have to abandon using this and go for something else that works.

Any suggestion?

Many Thanks,

Oct 13, 2007 at 9:23 AM
PeterBlomqvist wrote Aug 9 at 9:25 AM
Hi Jim and Hymee,

Sorry for not being quicker on replying, we didn't recieve any info that the wiki was updateds :( anyway could you please make sure that the tfs server setting is fully qualified:

add key="tfsServerAddress" value="http://tfsserver:8080"

And also make sure there are 2 entries in the eventlog from TfsBuildLab namely:

2007-08-03 13:12:30 BuildManager has initialized
2007-08-03 13:12:30 TFSBuildLab service started.

And try again the rest seems fine at a first glance. We will make some more test on the installation sorry for the inconvinience.

Oct 13, 2007 at 9:24 AM
PeterBlomqvist wrote Aug 9 at 11:23 AM
Hello again,

Now we have done some testing and there are 2 ways around the problems you are having...

1, Make the account running the service a member of the administrators group :)
2, The proper way, grant the account running the service the right to listen on the port you have configured the notifications to register to as explained in this blog (he has a very nice utility called HttpNamespaceManager which lets you do it):

Hope it works for you guys now, I'll be monitoring this page more closely from now on ;)

Oct 13, 2007 at 9:25 AM
Hymee wrote Aug 10 at 2:03 AM

Thanks for the tip. I used the sledge hammer approach for now to assign the service to be run by an account that is a member of the Administrators group. This seems to have progressed me past the original error.

No when I start the service, I get a new error in the log, as follows:

10/08/2007 9:52:16 AM BuildManager failed to initialize due to The type initializer for 'Callista.BuildLab.Core.TFS' threw an exception.

and the very next event logged is:

10/08/2007 9:52:16 AM TFSBuildLab service started.

So it seems to have started, but with errors. I would like to get this working, rather than abandon it in favour of another approach.

Oct 13, 2007 at 9:26 AM
PeterBlomqvist wrote Aug 10 at 9:57 AM

The problem you are getting is due to the fact that we are lazy sobs ;) we are running using the TFSService account in our config that is we connect to the TFS service with the same account as TFS it self is running under. I'll work out the exact details of how to configure a normal account to work properly during the weekend and update the instructions with this.

In the mean time swithc account in you config to your TFSService account.

Oct 13, 2007 at 9:35 AM
PeterBlomqvist wrote Aug 10 at 1:06 PM
Ok guys,

I've spent some time poking about the security stuff and as far as I can tell when you use the IEventService API to subscribe to notifications the account needs to be in the administrators group. So you have two options:

1, Use the TFSService account
2, Run TFSSecurity with the following parameters:

tfssecurity.exe /server:http://TFSSERVER:PORT /g+ adm: n:DOMAIN\ACCOUNT

This should get you guys up and running...

Oct 13, 2007 at 9:35 AM
PeterBlomqvist wrote Aug 11 at 1:49 PM
Just to be on the safe side, my last comment is regarding the account specified in the config file for TfsBuildLab which is used to log into TFS.

Oct 13, 2007 at 9:36 AM
Edited Oct 13, 2007 at 9:38 AM
AnthonySteele wrote Oct 12 at 12:07 PM
Hi, using that TFSSecurity command line just results in "Error: no command to execute" - are you sure it's correct?

Also, I have made the TFS service account a member of the local administrators on the machine on which it runs, which is not the TFS application server. This doesn't change the error. Am I right in saying that it needs this privilege on the TFS application server., i.e. the source for the web service that it is trying to connect to? Unfortunately due to company security policy I can't make this service account a doman admin myself.
Oct 13, 2007 at 9:37 AM
AnthonySteele wrote Oct 12 at 3:32 PM
Just to be clear, is the HttpNamespaceManager run on the TFS application server, or the TFS build lab server? Is the URL to be added the server URL (e.g. "http://mytfsbuilserver:8080")? What would cause this tool to come back with "Error Adding ACL. Error Setting Configuration: The parameter is incorrect".
Unfortunately, installing TFSBuldLab on the TFS server is not an option for us, and it's looking like other scenarios in a locked-down environment are much harder to configure.
Oct 13, 2007 at 9:51 AM
Hi Anthony,

I understand that it's abit harder when your in a locked-down environment. It shouldn't be a problem though. I'll try to sort it out wit you.

1, TFSSercurity.exe is available on the application tier of you TFS installation (it is really not nessecary to use that, you can just do it through the user interface of team explorer instead). The purpose with the operation is that if you wish to use the autoregistration features of TFSBuildLab the account you specify in the config to logon your TFS server needs to be a member of the TFS server administration group (it has nothing to do with the loacal admin group.

Optionally you can turn autoregistration off and follow the instructions provided to manually setup the nofications needed by TfsBuildLab.

2, The second thing is the HttpNamespaceManager, that should be run on the server where you host TfsBuildLab to enable it to expose wcf services using http as a transport so it is not the url to tfs you need to expose the url that TfsBuildLab is listening on if you still have problems let me know and I'll get the exact syntax for the operation again (but it is rather straight forward in the gui version).

We might remove this dependency in the future but I haven't had the time to try it out yet.

Oct 14, 2007 at 3:02 PM
Hi Peter.

Re the exception:
I would at this stage be thinking about intercepting the exception and adding details to it before it is displayed, e.g.

"TFSBuildlab could not connect to {theurl}. This may be due to permissions on this URL. Exception details are:
System.ServiceModel.FaultException: The server was unable to process ….."

Re the permissions:
My TFS Build service account is set up in TFS as a member of the group "ProjectName\Project Administrators". I don't have permission to add it to "Server\Team Foundation Adminstrators" myself - This is needed?

Re the URL config:
On the TFSBUildlab box, with HttpNamespaceManager, I think you're saying that I "need to expose the url that TfsBuildLab server is listening on, which the admin and dev tools will connect to" ?

These will just be "http://mytfsbuilserver:8000" and "http://mytfsbuilserver:8001" ? I'm getting the same error with these.
Oct 14, 2007 at 6:15 PM
Edited Oct 14, 2007 at 8:18 PM
Evening Anthony,

You have stumbled upon the two problematic issues with TfsBuildLab, to get around them you have to do the following:

1, The account running the TfsBuildLab service that is running on you server needs to be a member of the administrators group on that server to access the http.sys (if you are unable to do this you use either of the two options to grant these permissions to the account).

2, The account used to access TFS specified in the config file for TfsBuildLab needs to be a member of "Server\Team Foundation Adminstrators" to get the autoregistration to work if you are unable to do this you will need to perform the registration manually using bissubscribe.

As for the exception stuff I guess we could put som effort into translate the message abit :) but there has been alot of other things to finnish first, I'll look into simplifying these issues in the next release (v1.1) and I'll post something on the syntax for using HttpNamespaceManager (I need to try it again though forgot it already, but it is a syntax issue from what I can remember).

I've check out the syntax now and the trick is that in needs a trailing slash so it should look like this:


Or whatever port you have choosen in you service config as TfsBuildLabPort.