Thanks for the bug report! We've reproduced this and have fixed the bug in one of our pgSQL functions that was causing this. We'll have the fix included in the next beta (4.0.2) which will likely be released some time today. FYI- it's the same bug preventing changing the password on that page and adding a new user; we have verified that both are now working.

The upgrade is a coincidence, and the problem could have been triggered by something as simple as restarting the application pool; this is handled entirely by IIS (more specifically, Microsoft Negotiate). Negotiate authentication uses Kerberos (see Kerberos Explained), and this is difficult to debug. You can search for things like “windows negotiate authentication fails” to find all sorts of tips, but this article has been a good resource. In my experience, the most common reasons this doesn’t work: accessing by a different url (buildmastersv vs buildmastersv.mydomain.local) having a time difference between server and domain controller not having certain patches/windows updates NTLM is a different type of authentication, which may not be desirable.

Yes, run the Admin Tool from the start menu.

As long as your support renewal is current and either you are upgrading the instance directly, or you have purchased enough server licenses to cover all running instances; it will just work. If you attempt to activate a key on a new machine that would cause the number of running and activated servers to be greater than the number of purchased licenses, there may be an issue with the activation and you wouldn't be able to use the software. For more advanced or specific scenarios, you might be better off contacting us directly.

This answer doesn't answer the question. Is there anything else to check or try?

The SRCSRV stream for downloaded PDBs was always empty. Once I added that stream ProGet correctly updated it to point at itself. I never saw errors on the /administration page of ProGet. Is there somewhere else to look? I'd like to be able to skip the local indexing step if possible.

You can move BuildMaster from one server to another using the backup and restore instructions. However, I would suggest using the built-in retention policies to purge old items instead of that script.

Yes. Currently different versions of our websites get deployed to the server to a directory based on the version number. Was interested in just changing the directory the website was pointing at after the artifact was deployed. We currently do have a builds/deployments using a bunch of PowerShell scripting but it is getting challenging to maintain. Thanks for pointing out the Windows Extension.

Ah I missed the snapshot creation option, because I only tested an existing ProGet 3.7.x maven feed I had. The checkbox is handy when creating new feeds since it'll save the step of whipping up another feed. Since nothing appears to prevent you from creating your own snapshot repository without the checkbox, and the snapshot feed appears to be fully configurable and separate from the other repository (which one would generally setup as a RELEASE repository) so - yeah - that feature seems good to me. Thanks a ton for adding the storage location override to the next release - that's really going to be useful. Of course, now I'm getting excited... so I have to beg for feed retention rules being made available for snapshot repositories as a free version feature -- like Nexus, Archiva, etc. If that happens, my journey to the dark side will be complete. :-) I can understand the wisdom in making that a pay-for feature for most all other repository types, but at least for maven snapshots, the general industry standard is to provide some mechanism to auto-purge snapshots (keeping only the last 3 - or whatever the user specifies, etc.). I can also say that these specific improvements being made will help making a stronger case to switch binary repo managers, as well as going pro to pick up the other enterprise features. So thank you for the help and new features!

We're currently running BuildMaster and their agents under the same account. If we can turn off the "agent" role within the Server, it would help us achieve a clear segregation of concerns. We can then narrow the security the server's account runs under and since it won't be doing anything other than coordinating with agents, we can lock down the ports, etc. Ideailly, we would like to achieve the following: BuildMaster server (lightweight, has no source control providers, no dependencies installed, does NOT build anything) BuildMaster build agents (has source control providers, SDK's, etc.) BuildMaster deploy agents (on the actual target servers the apps should be executing on )

Thanks for the clarification. But then you should disable the ability to add anonymous as a group member and show a corresponding warning. With kind regards Boris Bopp

Your best bet will be using either a Delete files action, or simply just the Transfer/Synchronize files action, along with some negative/exclusionary masks. For example... * !images !cache !web.config

If that were to happen, then you'd need to follow the instructions here to restore it. Resetting the Default Admin Account If, due to a configuration issue, you find yourself locked out of ProGet, you can reset the built in Admin account to its default password and reset ProGet to use the built in directory by running ProGet.Service.exe and selecting the ResetAdminPassword option.

FYI - there is now a 30-release limit as of v4.8.2.

With remote connector caching enabled (default is enabled), there is almost no reason to pull a package to your feed. The reason the Pull feature is there, for example, is so you can pull down your "approved" packages, then remove the connector which in turn makes that package part of your local feed. Anyway, pulled packages are keyed by ID and version, so if a new version were released, you'd have to pull that. Check out some of the features we have planned on the Road Map which will better handle scenarios for users who pull packages often.

I don't believe the "Application Modified" event is particularly useful because that simply means a field on the Application Settings page was changed (like "allow multiple active releases" was checked), and I can't think of a good reason you'd want to know when an individual setting like that changed beyond who and when since you'll notice the changes as you use the application and can refer back to the event log then. That being said, I do agree that things like deployment plans being edited should show exactly what changed... and that feature is scheduled for BuildMaster v5; check out the Road Map for more information.

You can perform any action on the BuildMaster (local) server, or on a remote (agent) server. It's quite common to use a dedicated build server (via an agent) to compile source, etc).

Please see the Features by Edition page.

Thanks for the report; in this case, the correct behavior is to not display the log-in form at all when Integrated Authentication is enabled, and instead give an error page indicating no access. I've logged this PG-435

All fixed and I finally realized what I was doing wrong the admin password, need to learn where my uppercase characters go in passwords! Thanks, Jon