This is typically a sign that the account used to install BuildMaster does not have the necessary privileges to create a Windows service.

BuildMaster locks agents to avoid corrupting them during updates by creating a file named "locked" in the same directory as the remote agent service executable (bmagent.exe) or under the \bin directory for the IIS hosted agent. In rare cases this "locked" file will not be removed when an update is complete. If the Server Overview page shows that the agent is available and updated to the newest version of BuildMaster's core and extensions, feel free to simply delete the "locked" file.

The most likely reason is that you have recently installed something that requires a restart (usually a Windows update). That installation won't actually be finished until the system has been restarted. It is also possible that something was installed very recently and the Windows Installer service has not terminated yet. It should release locks and automatically terminate after a few minutes.

Normally you only need to activate if you have a new license key or if the hardware on the BuildMaster server has changed significantly (a different CPU and/or primary network card), and there is a 7-day grace period after setting a new key before activation is required. Basically, you just need to activate after setting a new license key - and there is no harm in activating multiple times.

This can sometimes happen when the cookies are not cleared properly after an upgrade. Try flushing your browser cache and clearing your browser's cookies, then visit the BuildMaster site root, e.g. http://buildmasterinstall.corp/

Thanks but I've had to revert back to 2.6.3 for now after spending most of the day trying to get the update to work. Will try again with 3.1 when it's available.

I've installed 3.0.6 successfully now (I think).

It looks like you're currently on 2.6. You'll need to upgrade to BuildMaster 3.0... we made a breaking change to the API/SDK and are no longer supporting our extensions written for 2.x.

Looks like this is a bug in the text :-) Should be "," separated.

Karl, thank you for the quick reply. We have 13 separate projects in just 1 of our solutions, so I was avoiding the tedious job of setting up an action to build each individually. What I ended up doing, and making work, was to just execute mstest.exe on the command line without the /p:OutDir parameter, using an "Execute Command Line" task. Not sure how that will play with the tasks that come after the build, but I suspect as long as I manage my paths correctly in the subsequent actions, it should be OK. Thanks again for the assistance.

Some providers, including the TFS provider, do not include the branching functionality. Generally, our branching actions are only implemented for providers that don't allow labeling (such as SVN which only allows tagging). One way to branch is to use the "Execute Command Line Action" against tf.exe command line utility to perform the branch with the appropriate arguments (http://msdn.microsoft.com/en-us/library/d73s8b27.aspx). Since our providers are extensible, we could always add this functionality to the provider. We prioritize features like this based on usage, so if you could send your use case to support at inedo dot com we'd be glad to help further!