SOLVED Human error on my part. Thought it best to state this so that others don't waste anytime on the thread.

Currently the license filtering is only supported for NuGet-feed types, but we are planning on a license management module coming soon that will handle this much etter for npm and other feeds.

This regression was fixed in ProGet v4.5.0. I'd recommend upgrading to the latest version.

It's likely that the user installing does not have the ability to access the database defined in the configuraiton files on disk. So, make sure to run as a user that has DBO on those databases.

Thanks!!!!!! That will help a lot.

When you un/re-install ProGet, it will not delete the database unless you explicitly say to. If you run the service interactively (just run the ProGet.Service.exe), there is an option to reset the admin account permissions.

SOLVED See the following Stack Overflow question fro the solution. http://stackoverflow.com/questions/3853767/maximum-request-length-exceeded In summary: in the web.config <configuration> <system.web> <httpRuntime maxRequestLength="2147484" /> </system.web> </configuration> and <system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="2147483648" /> </requestFiltering> </security> </system.webServer> Note: maxAllowedContentLength is measured in bytes while maxRequestLength is measured in kilobytes, which is why the values differ in this config example. (Both are equivalent to 2 GB.)

We'll consider it when revising the UI/homescreen (we don't , but most package managers do seem to report the total (not unique)...

Found the problem: It was an incorrect credentials at the connector.

I've managed to get this working in v5.0.11 by setting up the second ProGet website in IIS with anonymous authentication enabled and pointing to the same physical path as the original website. The same AppPool is shared between the two and is using the Integrated pipeline. No other IIS or .config configuration was required. In ProGet, for the npm feed that required anonymous access I added the Anonymous user to the feed permissions under Administration > Security > Users & Tasks. Restarting the web services then enabled the anonymous access to the feed using the second website's bindings.

You may have luck grabbing the packages from the internal, disk-based package store, and copying those to the drop path on the new server.

That did the trick! Thanks for the hint.

You can fairly easily switch directory providers, so you could just try that and see if it works. A lot of organizations will have a dedicated ProGet test instance (note this requires a separate server license) to test upgrades and major configuration changes. For most organizations, both LDAP and the Multi-domain configuration "just work". So long as service account running the ProGet web application has the appropriate permissions to query, and the domains are set for proper trust, then users will be retreived as expected. But for some, it doesn't, and the only way to find out why is to do a detailed analysis using our code. 90% of the time it's a domain configuration problem. But there's no easy way to identify it because the AD libraries do not tell us why certain users or their groups are not returned in a query.

Unlisting requires that Feeds_DeletePackage is part of the task.

Thanks for the bug report. We'll investigate and get a fix in the next release. We probably will also change the group syntax in dependencies to use a / instead of a colon, so you could just specify: "Root" (or "group/Root", etc). Of course, we would retain compatibility with the : syntax as well, but this would make things less ambiguous.

You can use the ProGet Native API to create feeds, and we will soon have a better endpoint available for that.

Just enter the license key in Admin > License. You can request a key at my.inedo.com

You will need to reactivate ProGet from the Admin UI. there will be instructions on how to do so within the software.

We did remove the dropdown for prerelease from the NuGet feed browser to make it more in line with how NuGet.org is these days. As of v4.5.0, we always show the latest version in the browser, including prerelease packages.

Apologies, I've created an account and now have a license. Thanks