Thanks Alana, once I installed the certificate into my 'Trusted Root Certification Authorities' and restarted the docker daemon on my client machine, things are working nicely. Thanks again for your help!

Well, I've been meaning to upgrade anyway. If that's something that's available in v6 means that I'll be doing that sooner rather than later.

Now I did see one version of BuildMaster (v6.0.5... maybe?) having some issue resolving $ServeRName, but it was fixed. Try upgrading to latest v6 as well...

First and foremost, an InedoAgent will respond to any request with the proper AES encryption token (like a password), so if you don't want BuildMaster talking to a server/agent, then don't configure a valid connection to that agent. Are you connecting your Standbox server to the same SQL SErver database? This is a big problem, don't do it... ** Never have two instances of buildMaster talk to the same database ** Are you restoring a database back up to sandbox? It's strongly not recommended, because of the problem you describe. The agents will be configured to talk to eachother. Instead,, when setting up a sandbox, create a representative and testable version of your applications and processes. /you'll never be able to get a "perfect test" (since you can't talk to exact same servers), so at best you should test the broad functionality instead of the connectivity.

It is, albeit a bit buried in the formal specification.

There doesn't appear to be; but we have a new issue (BM-3034) for this. If it's easy to do, we'll get it in ASAP!

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?

Awesome!! Thanks guys!!

Hi, yes -- There are quite a few users that have BuildMaster to do just that. I'm not sure about the Oracle/SOA services, but if it's something that you can write in a quick script, then it'd be fairly easy to add as an action as part of your deployment plan.

Would love to see a VSIX feed (didn't see a way to vote for this feature).

UPDATE: This is supported with the new execution engine, available in BuildMaster 4.9. As of BuildMaster 4.6, this isn't supported, but definitely something we will support in the future. I can see other cases where this would be useful as well (e.g., copying files or deploying artifacts to multiple target servers).

Thanks for the pointers, Dean!

When run in parallel, there is no guarantee with the ordering the value is set (and the change would be observed in different groups), so you'd have to create separate variables in each group if you have multiple action groups using different server groups.

The agent does not initiate any traffic back to the BuildMaster server, so no rule needed. The agent installer has the option to auto-register the agent against the BuildMaster server, but that's done under the account of whatever user is installing it, and it only happens once. It's also easy to register a server in BuildMaster too.

Of course, it really depends on the size of the server. ~80% of in-house usage comes from requesting known package (id+version), so this is a fairly performant operation and doesn't take much searching. So, one or two servers is usually ok. For very large package stores (100k+), we seem to have hit some interesting file system / FileWatcher limitations; it works, but sometimes the indexer just stops working. We do plan to redesign the package store, but the work around is easy (just restart the indexing service) Please see http://inedo.com/support/kb/1073/load-balanced-and-high-availability-installation-of-proget for more information on LA/HA proget.

At the moment, I'm not able to update our server. I do it later. I will also test with your refernced packages in a test project. Thanks a lot.

Yes, it's from the Dummy extension. When I click the "Add Server" button on the Servers page, it lets me choose an agent type -- self-hosted, IIS-hosted, SSH-based, or Dummy Agent. I was hoping to use dummy servers as stand-ins for real servers that don't (yet) exist so I could create my deployment plan before the servers exist. Then, once they exist, I would just point the deployment steps to the real servers.

This sound like it's just a tough process to model. No matter what you do, you can't have it both ways such that you could deploy to either a subset of DevX servers to an arbitrary subset of QAX servers. The options you'll have to decide on are either: use different workflows and different environments to separate Dev1 from Dev2, which will force releases to use a specific set of servers after a build is created for it use abstract environments (Dev, QA) with server variables that resolve to different server groups (e.g. DevSet1, DevSet2, or whatever), and select the result either at release, build, or promotion time so it provides historical context with the release/build In BuildMaster, the idea of an Environment (i.e. a different stage of testing) is meant to be abstracted from a Server (i.e. a physical/virtual machine), so whatever follows most closely to this paradigm would be the way to go.

"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.