It's really hard to say; if it works from your browser but not from visual studio, then I recommend to run fiddler, and then see what Visual Studio is doing. Maybe it's a cached password, wrong DNS, or something. If you look at the session logs, you should be able to see how the requests are different.

Otter wasn't designed as general-purpose task schedule, but the orchestration jobs can certainly accomplish similar purposes. On the agent roadmap, we do have "impersonation" as a feature... which means you could run commands and scripts under different user contexts. I wonder if you could use use Otter to configure the schedule jobs across your servers? We don't have operations to configure scheduled tasks, but certainly you could use PowerShell DSC (or write an operation to do this) to configure scheduled tasks.

It's hard to say, but if you're not seeing anything come up when you visit the web interface.. it sounds like the web server or IIS isn't running or otherwise configured. The error you shared from the Windows Service would verify this (the service cannot talk to the web application either). Take a look at the Manual Installation Instructions to see if you can identify how things are mis-configured.

In order to create a feed-scoped permission, the task must be feed-scopable. Go to Tasks > Customize Tasks, and remove any attributes that aren't marked "F" for feed scopable. Then you can apply to to feeds.

There is a Machine Key (which is a hash of your network card and CPUID) and your License Key. Those are sent to Inedo.com (either from the software, or manually at myinedo.com), which then returns an activation code. You can change your license key on Admin > License Key.

Wonderful! Worked just as you said it would. Thank you very much Alana.

The /symbols/feed giving a 404 is an expected result; when you visit the page, you will get a 404, but also see instructions on how to configure visual studio. Unfortunately we're not able to reproduce this "unable to check the enable box" error, nor have any idea what might cause it. It's a simple page that sets a flag in the database.

This particular issue just means that the web server and service cannot communicate; doesn't have much to do with VOR SECURITY, and you can simply resolve it by restarting the web/service.

It certainly might... but we haven't evaluated it for performance considerations, etc. Early on, we tried implementing a much more advanced filtering system (author, versions, etc), but it really put a strain on NuGet.org and became useless, so we didn't continue on that featureset. This is the first request for this specific filter, and it might be simple, but we'll definitely consider it.

Use https://registry.bower.io/packages as the connector URL instead of https://bower.herokuapp.com to resolve this. Bower must have changed the default service URL within the past day.

I have created an issue to add a feature to display a better error message when the base url property is invalid.  (PG-1107)

Hi Alana, Sorry to say that the solution you propose is crap. If teamcity can monitor on wildcards, example +:refs/heads/release/* I'm sure BM can somewhat do it also. I raised a ticket for the purpose. EDO-3200. Thanks Regards

I should clarify my last post, it does a Return Select 0 only when it is successful.

Hi Ken, Thanks for contacting us. We are aware of this issue and have traced it to be a bug in a database script, that only affects Linux. The good news is we already have issued a fix for the problem (https://inedo.myjetbrains.com/youtrack/issue/PG-1101), it just needs to be reviewed and tested.

I'm guessing that you're referring to this from the docs. I'll give it a try. ...Feed API key authentication is performed using HTTP basic authentication. To authenticate using a Feed API key, supply "api" for the user name and the API key for the password. feed api keys

Thanks for the reply. I didn't really think it was BuildMaster itself since I can deploy other smaller apps to the same server, same main web site, without issue. This particular app has a lot of files so I was somewhat suspicious of BuildMaster, memory, Windows or combination thereof having some issue with that large number. I am continuing to debug it and we have been looking at couple of possible issues. One thing that did come is a possible incorrectly registered DLL. Our IS dept had been registering it under the apps folder rather than the Windows/system32 folder but it's not certain that the one is this particular folder was the one registered. Unfortunately this is a live server so I have to use caution as to what I do on it.

Very nice to hear that. Thanks Alana.

Hi, Yep it was the Powershell script in the end!

Ignore. Someone had modified a property value incorrectly when combining two variables which was causing the Virtual Path to be invalid.