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
- poolname-webint-domain.com (EE Web services)
- hostname.domain.com (SE web services)
- owa.domain.com (outlook web access/web services)
- autodiscover.domain.com (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.