Only the single agent port is required to be open. As a workaround, if you have BuildMaster database access, you can just set the status of the particular server to FORCE. If you have a custom extension, you could write a quick custom recipe that can do it as well - just implement the IServerRecipe interface for a RecipeBase object. You can find out how this works in the Creating an Auto-Deploying Custom Extension Application tutorial which contains a downloadable example project containing example recipe code.

I'll try changing the type to IIS-hosted and see what comes of it. Just seems a little strange, since we've been running with the same configuration (TCP-hosted) since BM 4.0.5, without any issues. At some point (I believe within the last month), all build agents began failing at random times. Whatever version it was, around the same time we were no longer able to use SSL on the agents and we haven't tried using it since.

Don't call the SOAP methods directly; that's not supported, and the communication protocols can change in maintenance versions since it's not part of the SDK. The best way to do this would be using the Util.Agents::CreateAgentFromId method. This will return an AgentBase instance. Once you have that, you can invoke the GetService<T>() method (with IRemoteMethodExecuter as T), and then run code on the agent with the IRemoteMethodExecuter::InvokeMethod) method to get any information about the agent you'd like. There is also AgentBase::GetAgentStatus) method, but that's not as easy to interact with since you need to construct a context to determine if the agent is considered outdated.

As an extra note, if you're upgrading agents from pre-4.0 installations to 4.X installations, it will require reinstallation. Please see the following KB article for more details: Upgrading Agents for BuildMaster 4.0

You just need the BuildMaster server IP. BuildMaster agents are push-only, so only the BuildMaster service will initiate connections to agents. You shouldn't need to make any other changes to enable this.

You may want to check v4.1; there is some improved diagnosis/debugging with agents that might give a better error message as to the issue.

The SOAP-based agent is the IIS-hosted agent, so IIS would need to be enabled. The installer for that agent will automatically set up IIS for you.

This message is coming from an IIS-hosted agent, and means that the agent is misconfigured in IIS - perhaps this is pointing to a different host name, has proxy issues, etc. Perhaps try the self-hosted agent instead.

You are correct - I had a typo in the working directory !. This question can be closed.

Thanks, we will wait for the updated svn extension, and use the execute command line option in the mean time.

As it turns out this is a problem related specifically to the SVN extension and will require us to release a new version of the extension. We will have this out within the next few days. As a workaround, you can call the Execute Command Line action directly with the appropriate SVN checkout arguments in order to get the latest code.

Hi Matt, The BuildMaster agent doesn't need to be installed on the TFS Server itself; whatever server you're using as your build server (could be same server BuildMaster is installed on) should have the TFS Client (Team Explorer) installed. As for the agent error... the "IIS agent" is "SOAP Based" --- so you'd want to make sure to add a SOAP Based agent from the BuildMaster servers page. To test that IIS agent is installed, you can do http://localhost:81/agent.asmx -- if that page shows up, the the agent is configured in IIS correctly.

At the moment, there is no way to accomplish the pull method. Our agents are extensible, but the BuildMaster service itself is not equipped to handle the incoming connections since it works backwards to the original design. We have however thought about implementing this type of agent specifically to allow for hosted instances of BuildMaster. If you are a looking to purchase the enterprise edition, there are additional support plans that we have done in the past that would expedite the delivery of features like this. If this interests you, please contact support@inedo.com.

"Agents" and "Servers" are generally synonymous, but there is a subtle difference. Servers represent actual (physical or virtual) servers that BuildMaster can orchestrate. Actions can operate against Servers, files can be transferred from one Server to another, etc. A "Server Group" is a set of servers that can be treated as a single server. Agents are the mechanism that BuildMaster uses to communicate with servers, and are tied to a specific protocol (SOAP/Binary/SSH) and/or operating system (Windows, Linux, etc). Environments are on a "higher level" than Servers and Server Groups; they describe a stage of testing that your application is currently in, e.g. "Integration", "QA Testing", or "Production". Server groups are a way to simplify deployment to clusters, if necessary. Environments can consist of any number of servers and server groups. To make matters more confusing... you can still work with other servers without an agent, but you're limited to whatever you can do in a normal Windows environment. For example, you can transfer files over UNC paths so long as permissions are set-up, etc. installing an agent and hooking it up to BuildMaster (via External Servers) allows a higher degree of control.

In addition to what Karl said, as of BuildMaster v3.1 we have made agents extensible. As an example, we now offer an SSH-based agent that uses the SFTP protocol to communicate with a remote server, instead of the traditional SOAP channel. This means that nothing needs to be installed on the remote server, and because agents are extensible, you or we could develop, for example, a Powershell or FTP-based agent.

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.