A few weeks back, I wrote about the Group Policy changes in the Windows 8.1 Update. One of the big changes in the Update was the addition of Enterprise Mode for Internet Explorer 11. Enterprise Mode allows web sites (either specified by the end user or via Group Policy) to be processed in such a way that they appear to to the site to be Internet Explorer 8. There are also some additional ActiveX security tweaks that happen in Enterprise Mode so that [hopefully] organizations can get away from being tied to older versions of IE.
I had that “Aha!” moment and put the site into Enterprise Mode and…. buzzer. Nope, same problem. What gives? This was supposed to fix this problem, right?
After banging my head against the desk a few times, it occurred to me that this particular web application has about 10 different URL’s behind it. You go to the published URL for the application that looks something like http://application.trekker.net, get kicked to https://app.auth.trekker.net, then get kicked to a central login service page (Shibboleth, ADFS, etc.). After logging in, you’re kicked to https://prod.app.authd.trekker.net:1234. [URL’s have been sanitized and replaced with trekker.net to protect the innocent!]
After looking at the source of the page (right click > View source), there were another two (!) URL’s in the page I’d never seen before: https://files.app.trekker.net and https://scripts.app.trekker.net. Another “Aha!” moment!
I added both of these sites to my XML file (here are instructions on how to set that up) and, voila! The app works! It appears that Enterprise Mode was taking my list literally and wasn’t including either of these URL’s since they were different than the main web application. Lesson learned: if using Enterprise Mode, make sure any other URL’s that are being called by the app get added to the Enterprise Mode IE website list to ensure that everything is running in Enterprise Mode.