There have been a number of efforts we’ve been going through lately to promote users running modern versions of Internet Explorer. We have been marketing and advertising since release of course, and over the summer we added a prominent advertisement. Then, we recently announced that we plan to start doing automatic upgrades, in line with the approach taken by other browsers.
However, it has long been important to us that we leave the owner of the PC in control of their PC, and if you are an organization that means that your administrators should be the ones in control. We’re not trying to subvert an intentional choice, our goal is to simply default to the better choice (which is to be more secure and support modern standards) for those who would rather not be troubled to answer yet another hard question from their computer.
So, if you are running Windows 7, you may not have validated your readiness for IE9 yet, so you don’t want an auto-upgrade. We, of course, will respect the IE9 blocker toolkit – so you can go ahead and apply that. However, when we announced the updates, it happened to come on December 15. Anyone working in the retail sector knows full well that the holidays is when all of technology freezes – not only no IE upgrades, not even a blocker kit! That has simmered down since the holidays passed, but there is still a sense that you’re being forced to install something to stop the install of something else – and the fact that we call it a toolkit makes it sound complicated. So, I wanted to take a look and see what was in that toolkit, to see just how scary it was.
The first thing that surprised me was that it contained an ADM file. Since it’s for IE9, the blocker is only necessary on Windows Vista and above, which replaces adm files with admx files. Why we’d put in a legacy format I cannot explain, so I just ignored that and went over to the cmd file – I just didn’t have the patience to convert and wouldn’t blame you if you didn’t either.
So, what does the cmd file do? Well, it’s 69 lines of text, but at a glance it seemed more complicated than perhaps it needed to be. First of all, it turned @echo off, but then proceeded to echo a lot of output which nobody would ever see – I didn’t see the point of that, so I pulled those out. I found a REM and pulled that out as well. Once I’d cleaned that up, I could see that it had branches for usage, blocking, and unblocking. So, I wanted to focus on the blocking scenario first. It turns out to be a single registry key:
Add a DWORD value DoNotAllowIE90=1
That’s it. How does it unblock? It just deletes that registry key.
This was discussed in TechNet Magazine back in April of 2011, but in the emphasis on explaining the various options provided, I’ve still had some customers who just saw that there was a whole kit, with several components, and didn’t dig much deeper before getting worried that it was too complex. In the end, it’s just a registry key. Personally, I think setting a single registry key sounds less scary than a toolkit, and I can’t name a single IT Pro who can’t deploy a registry key easily enough.