I see, in that case, your network/server is not properly configured. This is not trivial to troubleshoot, and this is happening before the request hits our software. The most likely culprit is an invalid/missing SPN, and a domain administrator must add that. Here are some additional resources to follow: https://support.microsoft.com/en-us/kb/969060 http://www.sidesofmarch.com/index.php/archive/2011/11/04/troubleshooting-windows-authentication-in-iis/ http://serverfault.com/questions/341978/troubleshooting-windows-authentication-problems-no-challenge-in-iis-7-5 Search terms, "diagnosing windows authentication iis"

There is a bug in 3.7.x that will be fixed in 3.7.4 On the proxy configuration page, can you enter a dummy value into "Exclude URLs" section, e.g. "example.org"?

Started new question. Please answer there. Thank you

Tod. Looks like whatever you discovered was right. Added an exclusion of example.org, and I can now query and cache through a ProGet feed

Thanks, all good now.

Do you mean that some symbols are being indexed while others are not?

No problem! Now for a barrage of questions... Where is the 503 response coming from, ProGet or the proxy server? Is there an error message in addition to the status code? What do you mean by "use the ProGet feed", does that mean browsing the ProGet web application (i.e. feed overview page), or accessing packages via nuget.exe/Visual Studio? And does it work as expected if you access ProGet over HTTPS?

I've read that NuGet's architecture is being redesigned for version 3.0, which should also improve the performance. http://blog.nuget.org/20150608/nuget-server-status.html http://blog.nuget.org/20150601/nuget-3.0-rc2.html

I see. Thanks for the feedback - I didn't think about retention but that is a very good point. Retention itself is also a relatively new feature for ProGet, and we are still evaluating whether it ought to be included in the free edition in some form. Regarding feed-specific override paths, we probably will add this in a future release, but I can't give you a specific version as yet.

The INEDOPROGETSVC service is used by ProGet to perform background tasks (indexing, cleanup, etc) and is required to run ProGet. The only options (right now anyway) to install the ProGet web application are: IIS-hosted Integrated web server (this is essentially a 2nd Windows service) Linux via Docker (currently v4.0 in beta)

To find the connector, go to Admin gear > Manage Feeds > Edit Feed (pencil icon), and that will have the list of connectors. For the error itself, try some of these recommendations: http://stackoverflow.com/a/703285

Integrated, so it uses the account hosting the web application to query.

You can look in the Web.config file in the ProGet Service directory to see what connection string it is currently using to connect to the database. If you installed everything with default settings, this will be using integrated authentication, so it's connecting using whatever account the ProGet Service is running as. Outside of this, whoever installed/updated ProGet last would have also needed to have access for integrated auth.

This isn't currently exposed in the UI, but you can run this SQL query against ProGet's database to get a list of cached packages in a NuGet feed: SELECT * FROM [NuGetPackages_Extended] WHERE [Cached_Indicator] = 'Y' AND [Feed_Name] = 'MyFeedName'

Hi Mark, We just sent you an email with a stop-gap license. Please let us know if you don't get it.

That's actually supposed to be cached, but due to a bug it looks like it's only cached if there is not a timeout when trying to download the news. We'll get that fixed in a maintenance release; thanks for letting us know!

This is not a known problem on the server-side of ProGet, but instead a problem on the client; that "Stream" is referring to something opened on the client, and closed on the client. We've also seen similar behavior with some 2.8.x versions of NuGet.exe, and perhaps OD shares some of that code?

Sorry about the broken link! That article has be updated and that link should now redirect to the correct page: http://inedo.com/support/documentation/proget/feeds/nuget/visual-studio-extension

Now that the current version of Visual Studio seems to respect authentication challenges, we are adding support for this. The tracking issue is here: PG-1273

Thanks; we've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however.