It sounds like ProGet is working fine, but that the CHOCOLATEGUI doesn't support Windows Integrated Authentication. I would submit a ticket/bug request on their github and ask them to support it. It's generally a relatively easy change to make, depending on how they implemented querying.

Hmm, I wonder if it's related to Powershell Execution Policy? I'm not terribly familiar myself, but I know I've had to fiddle with that a bit to get things working... 15 Ways to Bypass the PowerShell Execution Policy

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today.

In this case, the error message means that the user runnin the installer does not have permission/access to read the configured ProGet database (this is an upgrade).

There are several ways to solve this problem, but a common approach is to multiple servers in each global location, and then either use connectors or replication to ensure the packages are accessible locally.

You could create a connector of this feed and add it to the other feed, so that you don't have to do any manual steps. It would act as remote connector and pull packages directly.

When you download a package, then package is cached by default; if you download aggin, it will use your local cache instead of re-downloading from npm. The caching is transparent, so they will not show up as local packages.

This is a bug in the free edition; we will resolve it in the next mainteannce release of ProGet.

Are you able to do this from the Admin > All Settings button? There should be a checkbox to enable load balancing. Also, FYI -- as an enterprise customer, don't hesitate to fill out a ticket or email us at support - Inedo - com, and include a couple screenshots or more info so we can better help resolve. This Q&A site tend to get a lower priority, so we may respond slower!

Thanks for your response. I'm glad to see that this will be fixed in the next release. For the time being, could you please specify which URL individual users should use, because every URL I've tried so far results in a SecuredTaskDeniedException

This may be fixed in a new version of ProGet; however please note that in NuGet 3.4 client, they added framework monikers abbreviation ("net" instead of "net45") that seem to be occasionally used. These will be supported in the next maintenance release of ProGet, udner PG-560 (Add Support for new NuGet 3.4 Framework Abbreviations).

In my original example that I used, the web user did have permissions. In fact, the user I used was the admin user. I did both create a special user with delete attributes and test the admin user. Both results were the same. Success was reported, but the package never really was deleted. I'm not using a feed APIKey, I'm only using users that have appropriate rights to do certain things, like delete.

It was most certainly permissions related. From the 4.0 Upgrade Notes... If you modified any of the default roles but did not rename then, then they will renamed to the new task names. In addition, the role's individually-securable actions (formerly, "tasks") will be reset to the new, default definitions

Thanks Alana. Could you guide me to-what table should I be making what changes?

Unfortunately symbols/source can be a little complicated to set up and debug; please review the various resources on the symbols tag, such as the tutorial and questions.

Hi again, My mistake, I selected the latest one and didn't notice that MINUTES before the 4.0.13 version was released and corrects this issue (Mine was 4.0.12 after all). Very, very, very fast guys. Awesome! Thanks!

I'm pretty sure mike you don't need to copy the folders one at a time and wait for pickup...you could copy all the packages at once. And watch out for that powershell script -- it will copy all files in all subdirectories into the current directory, so if your subdirectories contain things other than packages you should add a filter to it.

I think we've identified this and will fix this in the next maintenance; it only impacts the free version, but you can workaround as you've noted.

Update to 4.1.3 has solved this issue for us.

Ah ha! That is indeed the issue. I found the cached files in %localAppData%\Nuget\Cache. Thanks for the quick response!