Support for Windows XP ends in April 2014 and IE6 dependencies are standing in the way of many Windows 7 migrations. Legacy – yet still business-critical – web applications are all too often a key migration blocker, so Browsium and Camwood have teamed up with Microsoft to help customers jumpstart their browser migration and accelerate deployment of Windows 7.
Join us on Thursday May 3rd 2012 in London England for a packed agenda discussing the technical challenges faced by IT departments looking to migrate to a later version of IE. We’ll show you how to overcome these challenges with new tools and innovative solutions, including Browsium Ion.
Registration and event details can be found on the Camwood website.
One year ago today we shipped our first product, designed to help enterprises keep their legacy IE6-dependent business applications working when upgrading to Windows 7. That was a huge milestone for us as anyone who works in software development will tell you: “Shipping is a feature.” But these same experts will tell you that shipping again and again and again is also a key feature. You ship. You learn. You ship again. You learn even more. And the process continues.
Here we are a year later and we’ve learned a lot (and shipped a lot of software too). After constantly improving our initial solution over the course of the spring and summer of 2011, we moved on to design and build our second generation solution. In January of this year we shipped that solution, called Browsium Ion. Ion contains the cumulative learning that began on a year ago and has continued to this day. One huge learning was that IE6-dependent applications don’t actually need the IE6 engine to work in a modern browser. So Ion doesn’t include that engine, instead using the built-in engines in IE8 and IE9 along with highly granular control over all the features and settings in modern Internet Explorer.
The customer response to Ion has been tremendous. The world’s largest and most demanding enterprise organizations are finding its power, granular control, and compatibility to be exactly what they need to keep critical apps running and migration costs under control as they transition to Windows 7. In fact, these customers are learning too. They’re learning that Browsium Ion does a lot more than simply fix their IE6 dependencies. They’re leaning that Ion is an indispensable tool for browser management of modern applications as well, giving them complete control over the platform and settings for every web application. They’re learning that Ion not only fixes legacy compatibility, but delivers the unprecedented ability of future-proofing their critical apps against the inevitable changes & improvements to browsers and run-time components that seem to appear with increasing frequency.
Today’s positive response would not be possible if we hadn’t begun this journey on March 15, 2011. And it also wouldn’t be possible if it weren’t for our outstanding customers and partners who put every version of every product we release through rigorous testing and then tell us what’s working well and what needs to be improved.
As we look forward to the future, with new features coming to Browsium Ion and the introduction of entirely new enterprise browser management tools that we’re just now cooking up in our labs, we plan to keep one thing the same: A commitment to shipping and learning and shipping and learning in a continuous virtuous cycle.
A tip of the hat to all of you who have been teaching us since day one and helped us get to where we are today. Thank you, and keep the feedback coming.
One of the many powerful features in Ion is our Custom Registry Manager, which allows you to override any key in the registry with new values, but only for the web applications that need those custom settings.
We can isolate custom registry keys to a specific Ion Profile, meaning that you can use Ion to customize the registry environment for your web applications but prevent those settings from affecting other applications or Windows or Internet Explorer in general.
By default, Ion Profiles load all the same settings from the registry as the host IE8/IE9 browser, which is typically what you want but through Ion you can change that behavior when required. Any settings that is controlled through the registry can be managed this way, including proxy settings, security settings and ActiveX behavior. If there’s a registry key for it, we can override it with a new value.
Once again, this means you can maximize the compatibility of your browser environment while retaining a high level of security.
One way this is useful is to override ActiveX killbits. Make no mistake: this is advanced stuff and not recommended for any customer who doesn’t thoroughly understand the implications of reviving a control that’s been killed by Microsoft, but it is possible and can be done (through Ion) in a way that’s more isolated than otherwise.
First, some background: Killbits are a way for Microsoft to mark poorly-behaved and insecure ActiveX controls as persona non grata to the browser. If a control has shown that it has serious security flaws that can not be easily fixed, Microsoft prevents that control from loading by setting a key in the registry. The registry setting that does this is called a “killbit.” Internet Explorer will simply refuse to load any control marked that way. You can begin your reading on Internet Explorer killbits with this article. Microsoft will occasionally kill 3rd party ActiveX controls, but only when the 3rd party vendor is in agreement with the decision.
We do not recommend overriding killbits without fully understanding why the specific control was shut down in the first place. In most cases, Microsoft recommends re-writing your application to use a newer ActiveX control instead (and in those cases, you may want to use our “String Replacement Manager” feature as an alternative). When this is not possible, and the security risk and compatibility impact of the ActiveX control is fully understood, you can use Ion to allow a given ActiveX control to run, but only for the specific Ion Profile in question. Please note that in some cases, the security flaw of an ActiveX control may be so aggregious that even allowing it to run for one specific website may not be an acceptable solution from a security point of view, so consider this option carefully.
To help those of you who’d like to tweak the registry for application compatibility, I’ve posted two new KB articles to our support site. The first, “Setting a custom registry value with Ion” goes into detail about how the feature works in general and what syntax is required in the Ion Configuration Manager to successfully override any registry setting.
The second article, “Overriding an ActiveX killbit using Ion’s Custom Registry Manager” goes into detail about what ActiveX killbits are and how to override them through Ion.