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.

There may be a number of reasons why a builds aren't being created: Verify that there are releases for the target applications; a build cannot be created unless a release exists. Make sure the build schedule (under each app) is there, and not set to "disabled." Verify that the service is running. (Admin -> Service) Look for entries in the error log (Admin -> Errors) to see if anything popped up overnight. Verify that the ScheduleExecuterThrottle (Admin -> Advanced Settings) is a positive integer (default is 1).

When you say delete, do you mean remove from a workflow such that the build never travels into that environment? If so, just delete the workflow step from the workflow. If you actually want to keep the workflow step but remove all the action groups, just delete them one-by-one.

I was refering to Strong-Naming. I was using a passworded file .pfx and therefore causing issues, I moved to a .snk file (not password protected) and it's working correctly now.

That error message says "DirectoryProvider 1" which is the built-in provider. If you open up the Admin Tool located in the BuildMaster installation directory you can switch the directory provider to the LDAP one.

The password being displayed is by design, since the same privilege (Builds_ManageBuildSchedules) is required to both view and edit the build schedules, therefore showing it on one page is essentially the same as showing it on the other. You can disallow users to view the schedule details by denying the Builds_ManageBuildSchedules privilege to whomever you do not want to view the passwords.

The "Execute Database Scripts" action executes all the scripts in the specified source directory (and all subdirectories of that directory) on every execution. The only scripts that are run once and only once are the Change Scripts via the "Execute Database Change Scripts" action. Can you verify that: the action is referencing the correct provider and instance the action is running the correct server if applicable, previous actions are putting the .sql files in the correct source path on the correct server the source directory of the "Execute Database Scripts" action has the files you expect in it

Awesome! It looks like the API is working without a hitch in powershell. At this point, we probably have enough to to start with and a few angles to test. If we have any issues with the API or procs, we'll come back here. Thank you!

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/

Wow, that was quick! Thanks!

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

Not currently; that information is configured at an extension level. We do have a feature on the backlog that would allow for multiple extension configuration profiles, but that's not schedule for a specific release yet. In the mean time, your best bet would be to modify the extension (we can provide source code) to bring these peroperties to the action-level.

I'm not sure what you mean by distributed tests for MSTest, but pointing the MSTest Action at the configuration file is the way to go if you already have one. As for the batch file problem, what does your action configuration look like to try to run the .bat file? Is it set to run on the correct server? Does the account running BuildMaster have access to those paths? It's also possible that when you're running locally on the target server that you have the MSTest directory in your PATH but the BuildMaster account doesn't. That being said, is there a problem running the MSTest action as opposed to this batch file? It will be better integrated into the logs if you use that instead - the batch output will only give you stdout/stderr as opposed to an individual test breakdown.

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.

We do use the specific paths under the project root. The issue still occurred, but we altered our labels to have a text precursor and now it works. It appears to be an issue with mostly numeric labels and TFS. If two apps in the same root project happened to get similar release numbers... then it bombed.

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.