Microsoft Teams and Skype for Business News and Thoughts

Tom Arbuthnot MVP
Tom Arbuthnot MCSM Communications

This site uses cookies

Find this blog useful? Please take a second to share, thanks!

Lync 2013 client “Network Password Required to Connect” Proxy Issue

Published 21/05/2013 - 53 Comments

Update 25/5/2013: Others are experiencing this issue too and three different people have said they have raised cases with Microsoft and been told it is due for a CU “fix”. I’m not sure what this fix looks like and am trying to find out more.

Update 24/9/2013: A number of reports say that this issue is resolved in Lync 2013 Client September Cumulative Update (CU3). If/when I understand what has changed I will post, but for now if you are having the issue please try this CU and let me know, thanks – Tom


I’ve noticed this on a few Lync 2013 deployments (or Lync 2013 clients against Lync 2010 pools) and heard from others, the Lync 2013 client prompts for “network password”, why?


Note, this is not the same as the prompt for Exchange credentials or for Lync Better together sign in.

It seems that (unlike Lync 2010 client as far as I can make out) Lync 2013 client respects the Internet explorer proxy settings (as arguably it should). In many corporate environments a web proxy is setup to restrict web traffic/authenticate users (often to log access against a user).

Lync 2013 client picks up that there is a proxy and when it goes to a site/https web service that is not specifically excluded from the proxy, the proxy challenges for credentials, hence the prompt. Put in your creds and all is well (until your password changes potentially).

Lync client hits a bunch of web services as part of it’s normal operation, so you can reduce the likelihood of seeing this prompt by excluding those addresses from the proxy (or from proxy authentication), names such as

  • (EE Web services)
  • (SE web services)
  • (outlook web access/web services)
  • (exchange autodiscover)

(Obviously use your own judgment for the correct domains for your environment).

Since these are internal addresses it shouldn’t be a big deal to get them excluded from the proxy with a PAC file or excluded from authentication. In fact it takes needless load off the proxy. It’s not the case that Lync 2010 client doesn’t use any of these web services, just that it doesn’t seem to respect the proxy settings. Testing in fiddler shows the proxy challenge and response.

While setting the above addresses to bypass the proxy (or authentication) will reduce the likelihood of being prompted, unfortunately it potentially won’t eliminate the prompt. The 2013 client seems to have some hard coded web lookups to various Microsoft domains (probably for 365 autodiscovery/setup), and even if you find and exclude those (and if someone does with fiddler, please post the list!), if a federated user has a photo set in 2010 to do to a website (internal or public) Lync client will attempt a lookup to pull down the photo via http.

Interested to hear feedback if others are hitting this issue.


Tom Arbuthnot

Tom Arbuthnot

Principal Solutions Architect at Modality Systems
Tom Arbuthnot is Principal Solutions Architect at Unified Communications specialist Modality Systems. He is a Microsoft Certified Master and MVP, blogger, has a regular podcast with UCToday at and is a regular speaker at events including Microsoft TechEd and Ignite. He co-runs The Microsoft UC User Group London.


Dan Berry - 22/05/2013 Reply

Here’s where I’ve seen the craziest effect of this occur: Lync Phone Edition (ie.- Polycom CX600).

Here’s a prime example…

(I always knew the phones ran Windows CE, but seeing the Windows widgets was oddly amusing and entertaining to me :) )

    Tom Arbuthnot - 22/05/2013 Reply

    wow that’s crazy, is that CU8/repeatable?

      Dan Berry - 23/05/2013 Reply

      Well Tom, funny you should ask… we’re running hybrid mode, with 2010 CU8 and 2013 CU1. And yeah, that’s the latest Polycom firmware. Definitely repeatable, as it happened to all the phones in our UC practice office. Our organization has a Cisco Ironport (if it wasn’t obvious) for traffic on 443/80.

      The good news is that I had the network team add all the host records (above) to the unfiltered list and it cleared it up. And of course, they were confused as to why it would be a problem (again, as you said, they’re internal addresses, right?)… but there you have it.

        Tom Arbuthnot - 23/05/2013 Reply

        OK, if the LPE only reaches out for Lync/Exchange Web services (rather than fed contact photos/random Microsoft public domains), at least that allows an easy workaround, really interesting though.

        In the environment I’m seeing it LPE aren’t up to CU8 yet. I’ll see if I can flash a couple and replicate, but as the proxy in this case has all the exclusions in place I suspect it won’t happen if the proxy exclusions are in place.



          Dan Berry - 23/05/2013 Reply

          I just rechecked our servers for patches, etc. They’re up to date. Phone firmware 4.0.7577.4387.

Adam Jacobs - 22/05/2013 Reply

Hi Dan,

How did you manage to get this response, can you let me know how to reproduce this error?

Many thanks,


    Dan Berry - 23/05/2013 Reply

    Adam: Easy… If you have a security gateway ‘issue’, and you have the latest Polycom Lync Phone edition firmware… wipe all credentials and attempt to sign in with PIN authentication on the phone. Don’t use a USB tether via PC.

      Adam Jacobs - 23/05/2013 Reply

      Thanks Dan, presumably this didn’t occur prior to CU8?


John Smith - 22/05/2013 Reply

We have an office 365 Lync online env. setup with ADFS and use our “corporate” credentials that the Lync client automatically uses to sign in. We are getting this prompt as well. It makes no sense to me why the client will use integrated authentication for the client and not the proxy login. Why not try the integrated credentials one time and it if fails pop the login. Microsoft at work

Peter - 23/05/2013 Reply

This is a known bug in Lync 2013 client. I have just had a case with Microsoft on this and the fix is addressed in an updated scheduled for the last quarter of this year.
The only solution is to enter username/password and check save password, has to be redone when password is changed.

    Tom Arbuthnot - 23/05/2013 Reply

    Thanks Peter, do you have a PS ticket number you can share with me privately so I can backchannel/verify details.

    What’s considered the “bug” and what’s the proposed fix?


      Adrián Matías Sarabia - 23/05/2013 Reply

      I’m having the same problem! Peter, you can pass me the same information requested by Tom?

      Thank you!

bb - 23/05/2013 Reply

Its more than this.

Its also for if you just enable msn federation in lync (for all Clients!).
Or for users that have external contacts with pictures, this also occurs.

So exclude proxy for internal servers is only a workaround for some people.

    Tom Arbuthnot - 23/05/2013 Reply

    Yes, as per post “While setting the above addresses to bypass the proxy (or authentication) will reduce the likelihood of being prompted, unfortunately it potentially won’t eliminate the prompt”

      Adrián Matías Sarabia - 26/05/2013 Reply

      The problem also happens when users want to connect to a federated WAC.

        Tom Arbuthnot - 27/05/2013 Reply

        Makes sense, since that would be a HTTPS call, good point


Will - 21/06/2013 Reply

We have been suffering from the same problem. The big change that we noticed between 2010 and 2013 client is that the 2013 client no longer sends user-agent info in the proxy request. In 2010 it was possible to identify the client and allow it unauthenticated access – not brilliant but there was no pop-up. This is no longer possible with the 2013 client.

I suspect that the fix will be to add back the user-agent info in the proxy request.

If you have any information on how the fix will work I would be very interested

Tony - 09/07/2013 Reply

Why don’t they just provide an option in the client not to use a proxy? We’re using office 365 and some Lync 2013 clients have this problem. I need the office 365 Lync 2013 server addresses so I can bypass the proxy.

    Tom Arbuthnot - 10/07/2013 Reply

    Yes, I am hoping someone will run a sniffer for a long period of time and collect the addresses, but it’s a bit of a moving target. Also with fed pictures downloads more urls still…

Gazsi - 11/07/2013 Reply

In our case, at the startup the Lync client looked for the autodiscover.MAILDOMAIN/autodiscover/autodiscover.xml file (I think this is a step from the exchange discovery process. This MAILDOMAIN is not the SIP domain in our case)… if this record is not exist for internal or external users(our exchange is not published), the Lync client ask for this….trough proxy. I put this DNS alias autodiscover.MAILDOMAIN available for internal network … and the Lync started without asking the proxy authentication.

Mykhaylo - 24/07/2013 Reply

Doesn’t Lync 2013 client have possibility to provide credentials of logged on user?

    Tom Arbuthnot - 25/07/2013 Reply

    It appears not for this web proxy function

Mat - 06/08/2013 Reply

Hi Tom,

Any new about CU fix for that issue?

    Tom Arbuthnot - 06/08/2013 Reply

    No official news, a customer said they have been told it’ll be fixed in a future CU, its not in CU2.

    Worth asking MSFT if you have a contact, the more people that ask the better


Bryan Childs - 29/08/2013 Reply

I got the proxy.pac file changed internally here yesterday to try to fix this issue – after having tested locally with a file:// based proxy pac url – which had worked.

But downloading the real .pac file from our internal proxy server, the lync client is just ignoring the directive around autodiscover.. It’ll only honour it if the .pac file is loaded from a file:// url.

Weird eh?

PS – I’ve confirmed with our Microsoft TAM that there *is* a fix in the works for this. He doesn’t have a firm date for it, but seems to think Q4 this year is likeliest.

Jordon - 30/08/2013 Reply

Im running CU2 issue still present with a split DNS but a different internal domain. I’ve added all the internal and external DNS names in TMG excluding for pass through and exclude on auth.
The proxy prompt happens sporadically at least once a day and is unpredictable. Running netmon shows access to the following urls, however i cant exclude from TMG for security reasons.

I believe the above has something to do with the translator – however i dont even have this enabled.

    Tom Arbuthnot - 03/09/2013 Reply

    Yes, it reaches out to a whole bunch of MSFT domains, it would be good if someone found the time to document them, but a cu fix is on the way apparently

Tom Arbuthnot - 21/09/2013 Reply

Hi all,

Lots of references to Proxy issue fixes in the September 2013 CU. Interested to hear how everyone gets on:



    Kieron Palmer - 23/09/2013 Reply

    Hi Tom,

    thankfully the September update has removed the proxy login prompt for us.


      Tom Arbuthnot - 23/09/2013 Reply

      Excellent! thanks for sharing, testing with one of my customers tomorrow

      Any idea how its working/what has changed?

#Lync 2013 Client September 2013 CU Released: New Spell Check and Tray Icon back | Tom Arbuthnot's Lync'd Up Blog - 22/09/2013 Reply

[…] interesting there are a number of references to the known Proxy Authentication Prompt Issue, I hope that is fixed, I’ll report back on how customers with the issue get […]

Lorian - 18/10/2013 Reply

fixes the issue here too - 03/01/2014 Reply

Excellent article. I’m facing a few of these issues as well..

John - 19/08/2014 Reply

Having this issue, in case when Lync 2013 client must connect to outside for image file (like ) through TMG. User gets prompted for credentials – doesn’t matter if enters valid ones, invalid ones, cancel, or valid & save : will get repeated (1-2 per hour) prompts. Only occurs to small number of users (out of about 1000). Running latest version of Lync 2013 client as of today. Cannot find any pattern.
What else to look for?

    John - 29/08/2014 Reply

    Further testing showed that the cause of the prompts was not the connection for image files, but rather misconfiguration of Exchange autodiscovery. Once the missing DNS records for were added, the annoying login prompts went away.

Gio - 22/10/2014 Reply

Hello John,

We have an identical issue, was your fix to add an internal DNS for

Thanks for sharing :)

Gio - 22/10/2014 Reply

Hello John,

We have an identical issue, was your fix to add an internal DNS for

Many Thanks for sharing :)

sachin pawar - 20/12/2014 Reply

Hi all

Actully i am facing issue with edge server not able to connect with new skype users. which is already added in my lync contact i am able to contact that users..

any one suggest what is issue

Sam - 17/09/2015 Reply

Im getting this issue with a Lync 2013 server fully patched and Skype for Business Basic clients. Its driving us bonkers! We have added every url known to our Proxy PAC file to go direct but still getting the prompt!

mahesh shirke - 27/12/2015 Reply

Thanks !

Hi, It helped me nail down the issue. Bypassed authentication & configured allow policy for in my proxy server.

I could see the evidence in wireshark as well.

Thanks once again !

    Tom Arbuthnot - 27/12/2015 Reply

    Glad it helped!



      Stephen Walls - 02/06/2016 Reply

      Hi Tom,

      I’m seeing the prompt on SfB client and I’ve added all of the relevant URLs to the proxy exclusions.

      We are federating with O365, so i’m curious if there are other external URLs in addition to the usual internal web services etc that need to be added to the proxy exclusions. Did anyone provide a comprehensive list?

      Most of the comments on the thread are 2013, so i’m wondering if there are more recent URLs used by Microsoft for the SfB Online platform as opposed to the older namespace?



        Tom Arbuthnot - 02/06/2016 Reply

        Interesting, haven’t seen this issue for some time, are you patched to current? are you using a Web Proxy?

          Stephen Walls - 20/06/2016 Reply

          Hi Tom,

          Yes – Patched to latest and using a web proxy. Excluded the typical URLs, but now looking at running some traces.

Imrul - 23/06/2016 Reply

We are having the same issue as well in sfb client which started just recently.
We are using Lync server 2013 and sfb client. So far no changes were made in the Lync infrastructure recently that may cause this issue.
Stephen, can you please share the resolution if the issue is resolved in your environment.

Alexey - 24/06/2016 Reply

I block this url on web proxy and now all right.

Tony Macartney - 15/09/2017 Reply

Hi Tom

Are you aware of the issues with the Lync client ignoring proxy exceptions when using a pac file?

    Tom Arbuthnot - 03/10/2017 Reply

    No specifically. Don’t have many people on the Lync client anymore TBH

maglie calcio poco prezzo - 16/06/2018 Reply

thank a lot for your site it helps a whole lot.

Leave a Reply:


Weekly Email Update 
of all the key 
Microsoft Teams and Skype for Business News
every Tuesday

No Spam ever, I promise - Tom