The user that connects to SQL Server needs to be granted the BuildMasterUser_Role; this role is created as part of the database creation. No additional roles or access is needed.

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!

It is working now that I set the Action Group to "all deployables". I still can't use the specific deployable though. I copied the named deployable through my steps and it fails... but the generic works just fine.

Anything that can be built via a command line interface can be built in BuildMaster using the "Execute Command Line" action with the appropriate arguments. Because actions are extensible, you (or we) could also write a first-class action named something like "Build Android Project" with only the fields generally necessary to build an Android project.

It looks like for some reason one of the subdirectories beneath C:\Code\Build is not getting cleared. This could happen if there is either a file that cannot be deleted due to the directory's security attributes or a hidden file contained in one of the directories. It may be helpful to enable the "Log individual entries" option to troubleshoot this problem - that way you should see which directory it gets stuck on.

It turns out the license key request service was down, thank you for reporting this. It should be up and running now. If this happens in the future, trial and free license keys can be obtained by creating an account on the https://my.inedo.com website.

Generally this is a result of the web application domain account lacking sufficient privileges. Ensure that the account that the BuildMaster web standalone service (for the self-hosted web server) or the IIS application pool is running under an account that can query service statuses on the machine.

If you run the command: sc config inedobmwebsrv depend= / for the web server or: sc config inedobmsvc depend= / on the server with admin privileges, the dependency should be removed.

Yes, Hudson (or another CI server) can definitely co-exist. Some of our customers simply have BuildMaster pickup artifacts or build output from another tool like Hudson and use BuildMaster to deployment and implement the approval processes. However, BuildMaster does have CI capabilites (see Automatic Builds at the bottom of the Builds documentation: http://inedo.com/support/documentation/buildmaster/core-concepts/builds ), and can completely replace your Hudson/CI tool in the future

You need to add an additional host name to the Integrated Web Server. Check out: http://inedo.com/support/kb/1014

From a licensing standpoint, a "user" is simply someone who has access to and uses the functionality of BuildMaster: whether that's designing deploying plans, kicking off new builds, or analyzing data. That being said, BuildMaster is designed (and priced) to be used by the entire development organization. The reason is that we believe everyone involved in development should be involved in (or atleast aware of) the process, not just those on a Change Management team. While you can buy as few licenses as you'd like, there's a lot less value when only a small group has access

See: http://blog.inedo.com/2011/10/04/changing-buildmasters-url-with-the-integrated-web-server/