Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Sunday, May 15, 2016 10:31 PM
Hi all
I have had numerous support tickets created by our users complaining about being prompted for proxy credentials when opening office files. The users use a mixture of office 2016 and 2013. The 1st application most complained about was outlook 2016. I submitted a ticket with MS and we got this resolved via a registry entry. The registry is only preventing the request mechanism thus prevent the pop up (so is really a workaround not a fix to the underlying issue as to why it happens). The interesting thing is the issues have only started recently where our deployment of office 2013 is 18+ months old and 2016 deployment is 3+ months old in a static environment over that time. My guess is the latest windows updates have caused this issue to start.
I have read fixes for issues to do with 2013 (turning off access to the internet ) but the settings doesn't exist for 2016 (and didn't seem to work for 2013 either).
For interest the fix (Outlook only) i got from MS is as follows :
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeHttpsRootDomain"=dword:00000001
**A screenshot of the prompt is as below **
All replies (5)
Monday, May 16, 2016 7:41 AM
Hi,
What's your account type configured in Outlook 2016 and Outlook 2013? Are you using Exchange account?
If the issue happens to all your Exchange users, please check the Outlook Anywhere and Autodiscover configurations in Exchange server side.
If the issue only occurs in specific clients, please check the following settings:
1. Open Internet Explorer, click Settings > Internet Options > Connections > LAN settings, uncheck all options here including uncheck the “Automatically detect settings” option. Save settings.
2. Go to Control Panel -> All Control Panel Items -> Credential Manager -> Windows Credentials, remove the credentials for Microsoft Office. Then restart Outlook to confirm if the issue persists after typing Password.
3. On a working machine, run Test E-mail AutoConfiguration Tool to check the Autodiscover service with this problematic user’s email address. Share the results and Log information here.
Regards,
Winnie Liang
TechNet Community Support
Please mark the reply as an answer if you find it is helpful.
If you have feedback for TechNet Support, contact [email protected].
Monday, May 16, 2016 7:56 AM
HI,
check in all the CAS server's if AD topology services are running properly. check in the event logs there you might get the related events and can find the solution easily or paste here we can look into that easily and can revert recommendation.
Salman
Monday, May 16, 2016 11:18 PM
Outlook is the one app as i mentioned we have a fix for. It was to do with the auto-discover and one of the updates to Outlook 2016 changed the ways it resolved the location of the exchange server (according to the Exchange specialist from MS). the registry fix essentially stops Outlook from trying to auto-discover via the local Domain and forces it to use the correct DNS entries from the NS.
But like the topic and my previous post we are now getting credentials request for ALL office applications for 2013 and 2016.
Monday, May 16, 2016 11:28 PM
As stated Outlook is working fine once we use the registry entry i posted. We use Office365 for our exchange server. We have the same issue for all other office applications (except it seems outlook 2013). I'll run some process monitor traces etc on an affected machine and see what is up
Thursday, May 19, 2016 12:37 AM
So i have managed to make a couple of packet captures of what is happening. Something odd. Essentially the office app tries to connect to our root public FQDN domain over https. The only thing i can think of is that we use a local UPN for our online account names instead of the *.onmicrosoft.com address. No idea why after 18months of using Online services this has started to do this.
Debug of the Packet Stream below. This debug used an intentionally fake user/password witch can be seen int he NTLM packet section (but that isnt shown below). I'll work on capturing a correct login, but i have also excluded the domain it is requesting from the proxy so it should just bypass it (though their wont be anything for it to request at it's destination)
CONNECT fake.domain.com:443 HTTP/1.1
Host: fake.domain.com:443
Proxy-Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
HTTP/1.1 407 Proxy Access Denied
Server: WebMarshal Proxy
Content-Length: 0
Proxy-Connection: keep-alive
Proxy-Authenticate: Negotiate TlRMTVNTUAACAAAACgAKADgAAAAVgoniw8IC5x9G27kAAAAAAAAAANwA3ABCAAAABgOAJQAAAA9OAFAARwBIAFMAAgAKAE4AUABHAEgAUwABABQAVwBFAEIATQBBAFIAUwBIAEEATAAEACwAcwBjAGgAbwBvAGwALgBuAHAAZwBoAHMALgBzAGMAaABvAG8AbAAuAG4AegADAEIAdwBlAGIAbQBhAHIAcwBoAGEAbAAuAHMAYwBoAG8AbwBsAC4AbgBwAGcAaABzAC4AcwBjAGgAbwBvAGwALgBuAHoABQAsAHMAYwBoAG8AbwBsAC4AbgBwAGcAaABzAC4AcwBjAGgAbwBvAGwALgBuAHoABwAIAEooed9fsdEBAAAAAA==
X-WebMarshal-RequestID: 7E829A8C-542E-4561-9576-B5377DE5B973
CONNECT fake.domain.com:443 HTTP/1.1
Host: fake.domain.com:443
Proxy-Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAH4AAACwAbABlgAAAAoACgBYAAAADAAMAGIAAAAQABAAbgAAABAAEABGAgAAFYKI4gYBsR0AAAAPQMmLDzpkQvdnwMfRLWqoE04AUABHAEgAUwBjAHoAeABjAHoAeABHAEgAVABMAC0AMAAyADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbgJuDuQuvKKIDd1EI2mFmwEBAAAAAAAASih531+x0QEJeNzWHKDnOgAAAAACAAoATgBQAEcASABTAAEAFABXAEUAQgBNAEEAUgBTAEgAQQBMAAQALABzAGMAaABvAG8AbAAuAG4AcABnAGgAcwAuAHMAYwBoAG8AbwBsAC4AbgB6AAMAQgB3AGUAYgBtAGEAcgBzAGgAYQBsAC4AcwBjAGgAbwBvAGwALgBuAHAAZwBoAHMALgBzAGMAaABvAG8AbAAuAG4AegAFACwAcwBjAGgAbwBvAGwALgBuAHAAZwBoAHMALgBzAGMAaABvAG8AbAAuAG4AegAHAAgASih531+x0QEGAAQAAgAAAAgAMAAwAAAAAAAAAAEAAAAAIAAAwa4WrzTPa/h8tAkNL8a1KX97kxNRJoqjHxh47zWH0y4KABAAAAAAAAAAAAAAAAAAAAAAAAkATABIAFQAVABQAC8AdwBlAGIAbQBhAHIAcwBoAGEAbAAuAHMAYwBoAG8AbwBsAC4AbgBwAGcAaABzAC4AcwBjAGgAbwBvAGwALgBuAHoAAAAAAAAAAAAAAAAA+fOjqRYmWxJ65fB8gM6NiA==
HTTP/1.1 407 Proxy Access Denied
Expires: 0
Server: WebMarshal Proxy
Cache-Control: no-cache
Proxy-Connection: close
Via: 1.1 WEBMARSHAL
Content-Length: 2354
Content-Type: text/html; charset=utf-8
Proxy-Authenticate: Basic realm="WebMarshal Proxy Server"