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
Tuesday, December 22, 2015 7:53 PM
We have our environment very locked down. Internal DNS servers do not recursively resolve. Anything that needs to reach the internet uses a proxy which does have recursive resolving (since the host name is passed in the CONNECT command). We do not use Office 365. Our entire infrastructure is in-house. The PCs are sent an explicit, system wide, proxy configuration that is part of our group policy and cannot be changed by the users.
This is a new problem that has popped up within the last few weeks and is getting progressively worse as office 2013 is being deployed to a higher percentage of employees.
There is a component somewhere in Office 2013 that is flooding (to the tune of 6M+ queries per day per client) our DNS servers with nexus.officeapps.live.com A record queries. The query is 'REFUSED' by the DNS server and a 'REFUSED' response status is sent back to the client (as per our security policies).
We can see in a packet capture it is trying to resolve this over and over in rapid (flooding) succession. We isolated it to office 2013 by slowly killing word, excel, and outlook. Killing any one of them in any order doesn't seem to stop it. When they are all closed the traffic stops. We have even tried re-following user steps and we cannot recreate the issue.
We can't seem to find any rhyme or reason as to why this occurs. Anyone else have this? and if so what was the fix (if you got one)?
All replies (5)
Wednesday, December 23, 2015 7:18 AM
Hi,
Outlook uses the URL "https://nexus.officeapps.live.com" to communicate connection status and health for the Microsoft Office 365 service; this URL could also be used for other service status other than Office 365, but as long as it belongs to Microsoft, it is safe to add it to your proxy exception.
Regards,
Melon Chen
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].
Tuesday, January 5, 2016 12:28 PM
Is there a way to disable the request entirely? We have systems on closed networks and there is no path to Microsoft? There are other connections to odc.officeapps.live.com related to Office 2013 products that I would also like to be able to disable.
Tuesday, January 5, 2016 9:24 PM
It is whitelisted in our proxies, but whatever is causing this behavior isn't using the proxy. We also don't use Office 365 for ANYTHING.
We've isolated it to something in Office 2013. Machines with Office 2010 don't do it and also when we close All office apps is when it stops. We can close any one app and it'll keep doing it. It's also random. Sometimes Excel is the last app to close and it'll stop, sometimes powerpoint is the last app to close and it'll stop.
Under normal behavior it properly uses the SOCKS5 system proxy with a 'CONNECT nexus.officeapps.live.com' causing the proxy to do the DNS resolution, not the desktop.
Under abnormal behavior, the desktop just keeps hammering the internal DNS servers to resolve nexus.officeapps.live.com until we close ALL office applications. Our DNS server sends a 'REFUSED' answer to any DNS requests that require recursive resolution since only the proxies can reach the internet directly.
Friday, March 4, 2016 9:20 AM
Hi,
Did you ever get this working? We are seeing a similar issue on a locked down internet network:
Issue: Launch Word / Powerpoint document from internal on-premise SharePoint server and it takes 20-30 seconds to open the file
- When we look at Procmon/Wireshark, we can see DNS requests from the device out to nexus.officeapps.live.com and www.microsoft.com . As soon as the DNS queries timeout, the document opens
- If we attempt this on a test PC which has external DNS capabilities it opens instantly
- This only happens on Windows 8.1 devices running Office 2013 launched from Internet Explorer 11
- If we attempt this on a test PC on the locked down network using Google Chrome, it opens instantly
I suspect the process that is spawning these requests is to do with the Software Protection service.
Wednesday, May 18, 2016 3:37 PM
I know this post is a few months old now, but I have been digging into this very same thing. When I tried to federate our Office 365 tenant which had no users yet, I "broke" our Office 2013 local installs which weren't connected to Office 365 at all (or so I thought). After opening a case with MS, I found out that the Office 2013 built in default identity behavior will first look for the identity in the cloud on launch. You may notice the UPN of the logged in user shows up in the upper right of Office 2013 apps automatically.
Here's some info on the identity behavior and how you can disable it from accessing the online services:
https://technet.microsoft.com/en-us/library/jj715259.aspx
https://technet.microsoft.com/en-us/library/jj683102.aspx
I believe SignInOptions is the registry key you are looking for to disable this behavior.