This post has been republished via RSS; it originally appeared at: Windows Blog Archive articles.First posted to MSDN on Dec, 24 2015
We are in the final stretch for support for older versions of IE on Windows – January is now right around the corner! We’re seeing customers making great progress, but some are still struggling with the final mile, and we want to understand where things are hard so we can do our best to address that and make things simpler.
One topic that’s been coming up in conversations a lot – how should I be using Enterprise Mode?
OK, I’m not going to mess about here – we thought the Tools Menu option was a terrific idea, but it turns out that perhaps it wasn’t.
User-initiated fixing was something we have experience with in IE – we did it for Compatibility View in IE8. You may have noticed that the “quick fix” (Compat View) button in the address bar is no longer there. As it turns out, more people clicked the button by mistake (it was right next to the refresh button, after all) than clicked it on purpose. A LOT more. And you’d break the entire domain if you did that. From this experience, we decided that we don’t want to lead with this, but that perhaps we could do a few things to make the crowdsourcing concept work. So, we added in the ability to “phone home”, or report in whenever a user enabled (or disabled) Enterprise Mode. That way, you can use it to crowd source testing!
And, as the intro may have already led you to believe, it didn’t work out as we had planned.
So, what should you understand about this feature?
First, since we designed it as a testing feature, we needed a way to clear out your testing data. Rather than inventing a new mechanism for clearing the Enterprise Mode configuration, we simply reused the existing mechanism to clean up browser info – clearing the cache. Yes, that means that when you clear your cache, all of your “fixed” sites go back to being broken again. So, clearly a negative experience if you’re using it as an end user self-service feature – periodically, their sites will just go back to broken, and unless they’re really paying attention, they’ll have no idea why!
Second, it’s a bit of a leaky abstraction. By making it easy, we made it somewhat less aligned with the way you’d actually configure and deploy a fix. When you enable Enterprise Mode via the Tools menu, it enables it for that specific URL, and only that specific URL. Which means you potentially behave differently than the XML file, which often gets all child paths included using the default path inheritance. For multiple pages, or compound pages using frames / iframes, this means potentially different behavior than the final fix as configured via XML. So, it’s an imperfect test tool! (Though still potentially quite useful as a quick and dirty testing tool, if you aren’t keeping that in mind, you may come to erroneous conclusions.)
Third, it no longer represents the entirety of what the Enterprise Mode feature set includes. This is only IE8 Enterprise Mode. You now have the option to include IE7 Enterprise Mode, as well as all of the Document Modes, in the XML configuration. So, while it could still be useful when you are coming from IE8 and leave your Compatibility View group policies the same, if you are in any other scenario, you may not be able to enable the mode likely to be most helpful!
I think you kind of see the point – good idea, worth a shot, but didn’t work out quite as expected. That’s OK, and totally in line with how we have to make software in a faster moving world. Make a good try, recognize when you haven’t hit the mark, and then go do a better job of hitting the mark.
And that’s why I recommend using a local XML file.
Enterprise Mode Site List (XML File)
Most people expect to use this as the deployment mechanism (except those who initially intend to just let users fix thier own things, which, per the above, probably isn’t that terrific of an idea). However, in my experience, it’s also the best way to do testing.
That being said, there are challenges with testing on production infrastructure, so what I have been doing for a while is running a PowerShell script to set up the environment for local testing. Note that this does overwrite the organization’s testing, which is what I want while I’m testing. It also resets each time Group Policy updates, so having it scripted makes it easier to reconfigure and start over when that policy applies.
First, I run this script to configure looking at the local XML file:
New-ItemProperty -path 'HKLM:\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode' -Name Enable -PropertyType String -Value 'http://localhost/phonehome/api/records/' -Force
New-ItemProperty -path 'HKLM:\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode' -Name SiteList -PropertyType String -Value 'http://localhost/sitelist.xml' –Force
A couple of things to note about the script. First, it does enable the Tools menu, which is something I do purely for quick and dirty testing, or for demos. (After all, part of my job is showing people how to use this stuff, so I do like tho show it all off and then give you advice on what I’d actually use.) Second, it points to localhost, since I’m running IIS locally (for all kinds of reasons) – you can just as easily use the file protocol here and just point to your desktop for super easy editing.
Now, after updating the site list, I want to start testing immediately. The way Enterprise Mode Site Lists work is that after you first get the group policy, it checks to see if you already have a site list enabled. If you don’t, then when you open IE, it immediately goes and fetches a version. However, if you already have one, then to remove this check from startup tasks (and improve the perceived launch time of the app) it gets deferred about 70 seconds. If you’re testing, you probably don’t want to wait for a minute before you can test. So, I have another PowerShell script I run to clear the version number and force an immediate fetching of the modified site list:
Remove-ItemProperty -Path 'HKCU:\Software\Microsoft\Internet Explorer\Main\EnterpriseMode' -Name CurrentVersion
Using this approach, I’m able to quickly perform testing that is high fidelity, majps directly to a solution you can deploy enterprise-wide, and enables the full functionality of the platform.
Hopefully this little tidbit helps saves people some time and frustration!