Getting error "The remote server returned an error: (401) Unauthorized." When trying to install jQuery

Apr 18, 2011 at 12:35 PM

Hi I get this error "'jQuery (= 1.5.2)' not installed. Attempting to retrieve dependency from source... Done. The remote server returned an error: (401) Unauthorized." when trying to install jQuery

any ideas?


Apr 18, 2011 at 5:05 PM

Try again? Perhaps on another machine or a different network. Works for me.

Apr 18, 2011 at 5:34 PM

Hi Phil, I’ve found out what it was, it was my TFS server which I connect o in my workgroup (no domain) I disconnected my project from TFS and all worked fine, the peculiarity was it was only happening with jQuery it’s self Elmah etc. worked fine. I have since restarted my TFS server and jQuery add fine J

Thanks Steve


Stephen John Naughton

Web Developer

Description: Description: cid:image001.jpg@01CAE0E6.F1069200

Description: Description: cid:image002.jpg@01CAE0E6.F1069200



c# bits



From: haacked [email removed]
Sent: 18 April 2011 17:06
Subject: Re: Getting error "The remote server returned an error: (401) Unauthorized." When trying to install j... [nuget:254328]

From: haacked

Try again? Perhaps on another machine or a different network. Works for me.

Apr 23, 2011 at 11:07 AM
Edited Apr 23, 2011 at 11:09 AM

It appears to be because my TFS server in is a workgroup, if I unbind from source control the NuGet works fine.

The only issue here is that the source of the error is unclear i.e. I cannot tell from the error message which server is at issue the NuGet Server or in my case my Source Control Server :)

I will try and do some more work on this to fix the issue or I'll have to have add a Domain Controller to my setup. But for now I know how to work around so it's all good.


May 10, 2011 at 4:16 PM

Confirmed, I have the exact same situation but with NLog. Didn't try others.

May 23, 2011 at 6:55 PM

Me too.

I have the same error, with Team Foundation Server 2010 (domain auth via internet).


  1. Open "Add Library Package Reference..." dialog.
  2. Install any package.
  3. Close Dialog.
  4. Try to perform a "Get Latest Version" operation over any file.

Error "The remote server returned an error: (401) Unauthorized." is displayed.

The only solution that i founded is restart Visual Studio.

May 25, 2011 at 7:54 PM

Hi there,
Confirmed here too, TFS in domain / client not.
Needed to disconnect -> restart VS -> update -> restart VS, checkin gave me auth errors too.
Apparently both rely on the same credentials when accessing internet from VS.

Jun 4, 2011 at 1:08 PM

and me, works fine if I check out my solution

Jun 6, 2011 at 1:39 PM

@ZeroDotNet & @sebdg do you get prompted for credentials during any of the steps outlined above?

Jun 6, 2011 at 6:24 PM
ilyalozovyy wrote:

@ZeroDotNet & @sebdg do you get prompted for credentials during any of the steps outlined above?

Hi ilyalozovyy,

I don't get a prompt for credencials when the issue occurs.

Jun 6, 2011 at 6:36 PM

@ZeroDotNet: What I am curious about is that the way that visual studio deals with assigning credentials when it communicates with external systems such as TFS.
For example when you open up the Visual Studio Extension Manager and you are behind a proxy that requires credentials prompt then the current implementation displays a credentials dialog box and when the user clicks on OK button it assigned the property WebRequest.DefaultWebProxy.Credentials that will end up being used for every subsequent request that is done there after. I could definitely see an issue if the same or similar behavior is occurring when you are connecting up to TFS and it caches the credentials for the requests to your TFS server and then when it tries to connect to a NuGet feed the credentials are not valid for it.
This is just a guess at this point.

Aug 8, 2011 at 7:45 PM
Edited Aug 15, 2011 at 8:05 PM

One idea of 'sirkirby' written in comments for related issue:

sirkirby wrote Apr 1 at 11:41 PM
I was getting this issue too, but i'm not convinced that its nugets fault. I, like the other users, started encountering this constantly when using the console to deal with packages. But the real problem for me was that my tfs credentials were not properly being stored by windows and the tfs server was in fact sending an unauthorized exception. Even when you restart, it seems like its working for a few minutes and then...bam, error when i try do do something involving updating a package. The issue came to the from for me because i just set up my new workstation and started fresh with win7 sp1 and ie9. In ie8, i would log in to tfs web and say "save my credentials". Once that was done, no more prompting in tfs and everything worked great. on my new setup with ie9, i did the same thing, however ie9 security is much tighter by default. Even though i saw my credentials saved in the user account control panel, it was still prompting every time. Unfortunately this is only visible when you visit the site through the browser, in vs2010 the error will eventually burp up as the tf30063. To ultimately get windows to stop prompting for the ntlm creds, i had to add my tfs site to the trusted sites list and drop security down to low for the trusted sites zone. Now it consumes my saved credentials and no more errors in vs2010 for nuget or other tfs least since i made the change early this morning.

Again, this is just what worked for me, but perhaps it will help someone else. If the issue comes back, i'll be sure to let you know via this thread.


I agree, it isn't nugets fault. NuGet just during its communications with repository resets cached Visual Studio credentials.

We cannot change the buit-in authentication logic, but may be we can force NuGet to use isolated from Visual Studio connectivity stack to prevent accidential reset of cached TFS credentials?

Run the NuGet functionality out of Visual Studio in a separate process (as a command-line tool)? separate domain, etc?

Aug 22, 2011 at 6:58 PM

I've got the same problem, however I do indeed believe it is NuGet's fault. If I open a solution and work with it, adding projects and code files, I can interact with TFS for an indefinite amount of time. It is only when I use NuGet that the credentials get lost, and I have to restart Visual Studio. This is a very frustrating problem, as whenever I add a new project or need a new library, I have to restart VS, add a couple libraries with NuGet until it fails, close VS, open it again, add some more.... Seriously, this should be a priority one issue, and there has to be a simple solution, as there are other CodePlex projects I've used that interact with TFS on a far more complex level that do not have this problem.


I have TFS set up in a workgroup, and I connect to it only from the same machine using VS2010. I'm running Windows 7 64-bit.  Following sirkirby's idea of adding the TFS web sites to the trusted sites list and setting the security level to low did not have any effect on the problem...when using IE 9, the TFS credentials are definitely cached, and I can open and close IE as often as I wish without having to re-enter my saved credentials. Whenever I interact with NuGet, however, within a minute my credentials are gone and I have to restart VS2010.

Aug 23, 2011 at 5:34 PM

Same thing here. Confirmed in the exact same setup as jrista.

Aug 23, 2011 at 5:38 PM

I think this is the bug we are referring to. Highly annoying and it gets worse. It won't be fixed before version 1.6. Which comes after 1.5.  Months away :-S I am tempted to try to fix it by myself .. if I only find some time.

Aug 23, 2011 at 6:04 PM

Would be great if you can look into it for us (we take pull requests :D).

Aug 25, 2011 at 8:12 AM

Looking at it. First impression - definitely fault of NuGet indirectly or directly at some point. Digging deeper now.

Aug 25, 2011 at 3:39 PM

Here is some progress.

I've found that it happens randomly but when it happens TFS won't work anymore.

I've tracked it down to TFS client - usually it starts by sending a HttpWebRequest and gets a NTLM challenge from server. Then TFS client responds with NTLM authentication and it works. But when it goes wrong it doesn't answer to NTLM challenge for some reason - network traffic seems the same just without the answer from client which rather throws "unauthorized".

Another puzzling thing is that it works just fine without NuGet.

Aug 25, 2011 at 10:41 PM

Link with some more details (see my question below)

Aug 26, 2011 at 2:42 PM

The Solution

Aug 26, 2011 at 5:54 PM
This is totally awesome. You rock! Just saved me countless headaches!!!



Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471

On Fri, Aug 26, 2011 at 10:43, MihaMarkic <> wrote:

From: MihaMarkic

Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Aug 26, 2011 at 7:05 PM

Yes, totally awesome. You saved me from having to investigate the bug too :)

Aug 28, 2011 at 10:25 AM

Hi guys, I am glad to contribute :-)

Aug 31, 2011 at 1:36 AM

Just to confirm, this problem also occurs in an enterprise Active Directory environment as well (TFS 2010 & privately hosted NuGet gallery / feed).  Had the same issue a month or so back and fixed it by adding the TFS domain to the local intranet zone - the pointers for me were we were using a custom DNS domain suffix (don't ask) in our TFS urls, and WinINET settings don't automatically try windows authenticating request for domains outside of the local intranet zone.  Quite why it works prior to using NuGet is a bit of a mystery but there are definitely some compatibility issues.


Oct 5, 2011 at 6:34 PM

I've noticed the same problem occurring after installing extensions or updates from the VS Extension Manager, so I don't think it is NuGet-specific. Trying out the linked solution to see how that goes - thanks Miha :)