Does one of your embedded scripts contain a reference to a module that doesn't exist on a remote server, e.g. Web Server Administration for IIS? Unfortunately the error returned by PowerShell is fairly useless in determining which exact module is missing :)

Thanks for the report - I'll have a dev take a look at this and fix it for the next version, which should hopefully be out today (8/14/14).

Curious, what versions of PowerShell do you have installed on the machine with the ProGet service, and also on the remote machine?

Thank you for the report - this will be fixed in the maintenance release coming out today (v3.1.1)

Looks like Chocolatey now requires the description field to have a value, whereas pre-v0.9.8 it did not require one. We've updated the editor for v3.1.1 to require a description, though this will not impact existing data, so you'd still have to edit existing descriptions so that they have a value.

It's unlikely this will be supported. There is no way to identify from metadata a symbol package vs a regular package... you have to open the zip file and see if it contains pdb/src files... which means we'd have to download every version of every package in a remote feed. If Microsoft / NuGet team ever implements a mechanism for identifying , then it's a possibility.

We will be adding a few fixes to help with retrying after indexing issues in the next maintenance release, as well as some more logging to figure out what is going wrong in these cases. Long term, we will also be redoing a lot of the indexing logic to eliminate these types of problems (but that probably will happen in a minor/major release.)

In this case, the web server user simply doesn't have permission to query the service status. You can ignore this message or increase the web server user's privileges.

At the moment, I'm not able to update our server. I do it later. I will also test with your refernced packages in a test project. Thanks a lot.

We can now support 99% of our clients using the Network Credential Manager. Only one edge case, as discussed with Alex, is still outstanding. We will address that by customising the code in the near future.

Thanks - somehow I missed that in the docs before. I will add this as an open issue (PG-221).

Hi Simeon, Windows XP is definitely not going to be a reliable server :) The TCP stack is deliberately throttled/crippled to prevent server usage.

As of 3.1: Active Directory / LDAP Integration Filter Packages by Name & License Load Balancing & High Availability Granular Privileges & Security

Thank you for the report - I have confirmed this particular page is validating the privilege at the system level instead of the feed level, we'll have it fixed in the next maintenance release.

This was fixed in one of the versions we released this year, if you upgrade to the newest version it should work correctly. Make sure to read the Upgrade Notes for each minor version since 2.2 (i.e. 3.0 thru 3.3), and back up your ProGet database before upgrading (the installer should offer this option) as there have been significant changes to feed storage and indexing. You'll also want to read the KB article about Migrating Legacy Feeds.

We can add a configurable throttle to the timer that triggers a package rescan. In the meantime, you can always trigger an immediate index rebuild by either setting the RebuildPackageIndex setting (under Admin->All Settings) to True, or by restarting the ProGet service.

I believe TeamCity requires that the APIkey is passed in, regardless of if the feed requires it or not. You can just use name:pass as the api key in this case.

At some point, the NuGet client started requesting every package version instead of just the latest for updates. The only way to fix this on our end is to add paging/result limiting for feed output. We could hack in a configurable result limit pretty easily which should fix this for you in a maintenance release.

In this case, it sounds like the service account has some sort of enumeration problem with groups. This is not uncommon. As a test, i would suggestto run the ProGet webapp (either in IIS or the hosted web service) with your domain account. And of course, if you do find out specifically what caused this from the groups/permissions side of things, an update would most certainly be appreciated :)

Not possible currently, but something we could definitely add - I'll put an issue in for this.