Outlook, Lync/SfB prompt for credentials?

In the last few weeks I had some complaints from users about Outlook, Lync/SfB prompting for credentials, after switching between networks (wired to wireless and vice vers). Users got pop-ups like this:

But not all of them and affected users even didn’t get them all the time.

This was going to be fun….

I started investigating the issue. After a while I could find the first thing they had all in common:

Only Office 2013 installations were affected. Furthermore this seems to happen ONLY when you had Outlook running AND Lync or Skype for Business, while you switched networks. When you killed the process of UcMapi.exe the prompt disappeared. But Outlook was not able to connect to Exchange on HTTP protocol level.

After a while I figured out that IT team deployed a new image with Windows 8.1. And all affected users had the new image.

I stepped back and had a look at the image. There must be a setting, which caused this issue. Maybe also some information to the environment:

No client is able to access the internet without using a proxy. Additionally split DNS for the services Exchange and Lync are in place.

I also opened a PSS case. We traced everything from the Outlook, Lync/SfB client and additionally we did some network traffic and Fiddler tracing.

We couldn’t really find a root cause. Of course Microsoft wanted to have the latest bits for Outlook and Lync/SfB on the clients as well as the latest drivers.

I’m with you when it comes to have the latest bits for the clients, but drivers….it really depends. Over the last years I have really rarely seen cases where drivers on the clients caused issues. I’ve seen much more related to any kind of add-ins for Outlook, which caused weired issues.

Nevertheless I brought the clients to the latest versions. I have to admit that some clients were really outdated. But no success.

Then I focused more on the proxy part. Normally the clients use the settings from your default browser. When the IT team introduced the new image based on Windows 8.1 the also introduced a scheduled task, which sets the WinHTTP proxy depending on whether the client is in the corporate network or not. The task is triggered by an event (guess what!) from the source NetworkProfile:

I checked what action is performed and I could see that a proxy was defined, but the bypass-list was only for the local DNS part. The code looked like this:

If (!(Test-Connection -CN 'portal.adatum.local' -Q)) 
{ Start-Process -F 'cmd' -A '/c netsh winhttp reset proxy' -N} 
Else { Start-Process -F 'cmd' -A '/c netsh winhttp set proxy "proxy:1080" bypass-list="*.adatum.local"' -N}

As split DNS is available there was no exclusion for the Exchange service related endpoints. Therefore I changed the code to include also AutoD and EWS endpoints:

If (!(Test-Connection -CN 'portal.adatum.local' -Q)) 
{ Start-Process -F 'cmd' -A '/c netsh winhttp reset proxy' -N} 
Else { Start-Process -F 'cmd' -A '/c netsh winhttp set proxy "proxy:1080" bypass-list="*.adatum.local;mail.adatum.com;autodiscover.adatum.com;amer.adatum.com"' -N}

After I tweaked a couple of users it seemed to be fixed. But after a while the users came back and reported that the issue still exists. Some of them also got now 2 prompts:

From Outlook

and from SfB

And this with the latest bits and the tweaked WinHTTP settings. As mentioned before split DNS is not only for Exchange services available. Also for Lync. So I changed the code again to include also the Lync part(lyncdiscover.<SIP domain>,lyncdiscoverinternal.<SIP domain> and sip.<SIP domain>):

If (!(Test-Connection -CN 'portal.adatum.local' -Q)) 
{ Start-Process -F 'cmd' -A '/c netsh winhttp reset proxy' -N} 
Else { Start-Process -F 'cmd' -A '/c netsh winhttp set proxy "proxy:1080" bypass-list="*.adatum.local;mail.adatum.com;autodiscover.adatum.com;amer.adatum.com;lyncdiscover.adatum.com;lyncdiscoverinternal.adatum.com;sip.adatum.com"' -N}

After this change the users did not report this issue anymore!

Conclusion

There are also a lot of article or post on the internet about changing the authentication for Exchange from Basic to NTLM for Outlook Anywhere or related to the certificate and its Subject or SAN. The environment had already the authentication set to NTLM and has a proper certificate. The takeaway from this case was essentially that you need to make sure running the latest version of your clients and when your company enforces a proxy: Make sure when you configure WinHTTP proxy that you also have a properly defined bypass-list.

Note: If you still experience the issue have also a look at the used add-ins!