Office 2010: User's Can't Access Office.com
I began working with an enterprise customer that had begun their rollout of Office 2010.
During testing everything had gone well but after deploying to several hundred users they started getting sporadic reports that users couldn't download templates from the Office.com website. Other users reported that they were having trouble accessing online help (also from the Office.com website). The odd thing was that some users were having no issues and when we tested it on our own machines (running Office 2010) we had no issues. I had a couple of ideas on the possible causes that I wanted to investigate:
1) Perhaps we were seeing a DNS issue resolving the website Office.com. Not particularly likely, but worth checking before we started digging for a deeper problem.
2) A group policy setting might be blocking Office.com. This seemed like a reasonable scenario though the customer was confident that they didn't have any Office 2010 related policies in place.
3) A firewall or proxy was blocking access to Office.com.
I started the investigation by using nslookup to see what IP address was returned by DNS for Office.com:
A quick whois search confirmed that those were owned by Microsoft so I was reasonably comfortable that DNS was not an issue here. On to idea number two.
I know there are two group policy settings available for Office 2010 that can limit access to Office.com content:
Microsoft Office 2010\Tools | Options | General | Service Options...\Online Content Online >content options
and
Microsoft Office 2010\Miscellaneous > Disable hyperlinks to web templates in File | New and task panes
Note: these two policies are only available if you load the appropriate ADMX and ADML files for Office 2010.
Because the users reported that they couldn't get to Office.com (not that the hyperlinks were disabled) I thought it unlikely this was the problem. Because the customer also said they had not used any group policy settings for Office 2010 (yet) I decided that it was time to investigate idea #3.
I asked users what happened when they tried to navigate to the Office.com website with Internet Explorer. They reported no problems. Hmmm....
My next troubleshooting step was to use the Microsoft Sysinternals Process Monitor to dig a bit deeper. Process Monitor (v2.96) is a free tool from Microsoft and is available on the internet at: https://technet.microsoft.com/en-us/sysinternals/bb896645
I began capturing data with Process Monitor on a computer that had the problem. I then tried to open a template from Office.com.
Here is part of the capture (slightly edited to obscure the actual IP addresses):
A couple of things are immediately clear here. First, the connection is being dropped. Second, the other end is an internal (10.x.x.x) non-routable address. Likely a proxy or firewall. This is starting to look promising.
Proxy servers or firewalls have rule sets often with dozens of configurations. For example, the firewall might specifically deny access to a particular website or only allow a particular protocol (like http) through.
The odd thing is that we could successfully get to Office.com using Internet Explorer. One difference is that it was Microsoft Word that was trying to access Office.com rather than a browser.
I decided to use another free tool called Fiddler to look at the connection. Fiddler is available at: https://www.fiddler2.com/fiddler2/ Fiddler allows me to inspect the details of an http connection.
Here is some of that capture:
Here is some of a Fiddler capture from when I use Internet Explorer 9 to go to Office.com:
One thing I noticed is that the user-agent string from Winword.exe is not the same as the user-agent string from IE9 (as expected).
A user-agent string is passed from a client application to a webserver. The original intent was to alert a website to the type of browser being used (and by extension any features or limitations it has). Because the client application can masquerade as some other application by sending an altered user-agent string (aka spoofing) the technology has very limited value from a security perspective. Having said that, many enterprise customers have rules on their firewalls/proxies that check the user-agent string from the clients against an approved list. If no match is found the connection is dropped. The thinking is that while not especially secure, it "keeps honest people honest". You can read more about user agent strings at: https://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx
At this point, I thought there was a good possibility that the firewall had several rules allowing the approved browsers through, but did not have one for an application like Microsoft Word. A quick check with the team that managed the firewalls confirmed my suspicion.
The fix to our problem was to ask the network team to add Winword.exe and the other Office applications including CLview.exe (the online help engine) to the allowed user-agent strings firewall rule set.
By the way, the reason not everyone was having the issue was that there was more than one enterprise firewall and some of them had the correct rules already in place.
And lastly, there is a terrific new book by Mark Russinovich and Aaron Margosis that covers Process Monitor (and the other Sysinternal tools): https://www.amazon.com/Windows-Sysinternals-Administrators-Reference-Russinovich/dp/073565672X . I highly recommend it!
--bruce