Windows Explored

Every now and then I use Word 2010 to blog. I recently ran into an issue where I could no longer post to my SharePoint blog at work from my workstation and the error was rather generic, not alluding to anything: “Word cannot publish this post. The provider where you are trying to publish is unavailable…”

This was odd because previously blogs posted normally. Additionally, I was able to post to my Word Press blog on the Internet and a different internal blog. To see what was happening, I turned to Process Monitor and set a filter for winword.exe. There was nothing unusual with the file and registry activity. However, network activity stood out:

Network traffic from Word is hitting xx2-isa2, our gateway to the Internet. This traffic should remain internal and not need to go that route. Why was it going to xx2-isa2? Unless you configure your browser with an exceptions list, FQDNs are all treated the same by your browser and attempt to go outside your network. But this didn’t add up. I had no trouble browsing this blog or other internal resources from Internet Explorer. I double-checked the exceptions list and it was populated with the correct entries (trust me, they’re there):

With nothing else to go on, I put this one aside and resorted to Windows Live Writer to blog.

A couple days later my interest was sparked again when I started running into DNS fail while opening links in emails that pointed to internal resources from App-V Outlook 2010:

I looked in the exceptions list and saw this time it was empty. I closed IE, opened it again, and the list was populated. I repeated, this time using the link in the Outlook 2010 email and the list was empty again. IE seemed to be exhibiting some schizophrenic behavior. Lather, rinse, repeat.

Soon, though, a pattern emerged. If I launched IE from the Outlook 2010 message via a link, I experienced a DNS fail. If I did the same using any other method, all was normal. I tried the link this time using instead Outlook 2003 that was installed locally on my workstation with no problems.  I assumed the problem was with App-V Outlook 2010.

Exception lists in IE are generated via group policy in our environment. Why they were not populating in IE sessions started from App-V? I was not sure, I have yet to fully grasp how App-V works. Some quick research, though, revealed this Microsoft TechNet blog: http://blogs.technet.com/b/appv/archive/2011/03/02/how-to-troubleshoot-situations-where-gpo-settings-are-not-applying-to-packages-in-app-v-4-5-and-later.aspx

In short, the App-V package keys were overriding the local registry keys defined by group policy, i.e. the proxy exceptions list key was blank for this App-V package . Until corrected, this could be worked around by simply populating the exceptions list manually from any IE session opened from a URL link from an App-V Outlook email link once. And since Word 2010 App-V also relies on this exception list, it also corrected the issue with failed blog post.