Thanks, will try IIS rewrite module for that.(

Oh ok, I thought it was done by you. I'll pester him about that then. Sorry about that. Thanks, Jon

That is just a "regular" COM+ that happens every now and then when doing anything with LDAP, so you an usually restart IIS, restart the server to fix it. Will send the code ASAP!

I suspect the two messages are unrelated... but unfortunately it's really hard to know what would cause the first problem. 99% of the time, especially over long-running things like this, it's a result of problematic network connections. The new Inedo Agents (available in v5) are a bit more resilient to this.

Good question; I'm not familiar enough w/ splunk to give a definite answer, but I would assume: the Windows agent and the Linux agent are different binaries the configuration is non-trivial (i.e. more than a couple operations) there is effectively no shared configuration/operations in the plans there is minimal shared configuration (ApiKey or AcocuntNumber) Based on that, I would probably do two separate roles, splunk-linux and splunk-windows or something like that. Of course, if there was mostly shared configuration, or if only a few operations were operating-system dependent (be it Linux or Windows 2003 vs 2008), then having an if/else sort of thing seems fine. One major benefit of the roles here will be, someone looks at it from the dashboard and says "oh ok, Splunk is installed". It's already obvious that it's a Linux vs Windows server. And to me, the ApiKey/AccountNumber/whatever seem like variables on the role (or maybe environment, if it's different in Prod and Integration). Down the line, we'll probably have something to deal with nested roles, role dependencies, those sorts of thing. Really need to see what the data in the field looks like!

This is not currently supported nor is it currently on our product roadmap.

A 404 is expected if you visit the root of a maven api url; that is an endpoint that is not intended to be visited from your web browser, but by the maven client.

I get the same issue with v4.3.1 (Build 5). With nuget, I can search (via connector) to list all packages available on nuget.org. But with npm, unless I manually add packages via npm connector, the search shows a blank page.

It's actually the NuGet client that is caching the old packages, you can view the (multiple) caches with this command: nuget locals all -list And either delete the files in those directories or use this command: nuget locals all -clear

Finally got it working, turns out a single quote at the start and end of TextData is enough for the configs to be fully included without error, while still accepting BuildMaster parameters, Here's the code in case there is a desire to implement Job creation in the Jenkins extension, (anonymized a little): Post-Http http://Jenkins:8080/job/TestNewAPIJob/config.xml ( ContentType: application/xml, TextData: '<?xml version="1.0" encoding="UTF-8"?><project> </project>', LogRequestData: true, LogResponseBody: true, RequestHeaders: %(Authorization: Basic xyz123) ); Thanks for the help getting this going, this was my first time using 5.3 from 4.7, little learning curve with the new Plan editor that is really cool! -Dan

Otter Free has no server limit, includes all of the features of Otter Enterprise, and gives all users unrestricted access. Otter Enterprise allows for you to control how users access the software.

Please refer to the High-level Architecture Diagram to see the components of a ProGet installation. The Database is a SQL Server database. The Web and Indexing Nodes are both .NET application that interact with the database using the standard SqlClient API. The connection string you specify in the configuration file is assigned to the ConnectionString property of that API. All of this is very standard, but it's very likely that your DBA/Network Admins configured the SQL Server you wanted to use in such a way that a simple/intuitive connection string was not sufficient. Maybe they used a special port, security, etc.; they would be much better suited to answer your question about why it's so complicated :) Also, please note that the ProGet Installer will create/update the tables and object in the database. ProGet itself does not modify (nor have the privileges to modify by default) the database structure. If you wish to install the database component outside of the installer, then you will need to follow the Manual Installation Instructions.

If the files contained in a zip being transferred as a whole, shouldn't they be appearing almost all at once? It's like downloading a file from your browser... the files are sent are written to disk as they are being streamed. Unfortunately, sometimes the .exe files is relatively large that their size increases gradually, therefore probably locked by the anti-virus tools while the deployment is still going. That could happen; it's possible the AV tool is acquiring a lock between chunks. In this case, your best bet would be to disable the AV tool or, if not possible, then use the zip method you described.

If access is granted, then ProGet will routinely perform update checks. The url is http://inedo.com/pg. No specific package information is sent. If you block the outbound ports, then update checking will not be done. You will also have to activate your license manually. A lot of organizations do this; it's fine, but slightly less convenient.

The issue turned out to be a problem with uploading the package to ProGet. ProGet was reporting the package was available in our feed and we were able to download the package through the website however the package was not available through the nuget feed. Deleted and re-uploaded the package a couple times and it finally took. Issue resolved thanks to help from Inedo's great support team! Thanks!

This is handled by Release Package Variables within a Release Templates. They work basically the same, except now you can create multiple sets of required variables, depending on the template chosen at release time.

I would suggest to use the "Run MSBuild Script" Action instead. Then you can specify any of the properties.

This will be added as an Operation in the next release; look for [BM-2218]. IUn the mean time, the legacy action is a good work-around.

We had considered this as an option when designing templates, but decided against it because of the additional complexity required. The main challenge being, a user with Releases_Manage can already change the pipeline (or any other attribute) on an existing release. Making a "restrictive" template be a securable feature would require new permission attributes (and thus be more confusing/frustrating to use), and making it a convenience feature would give it the appearance of security (which is also bad).