Symantec’s new app virt import/export tool lets you run IE6 on Win7

I attended Symantec Vision in Las Vegas last month. Even though Symantec didn't make any major desktop announcements, there were still some cool little things worth discussing here.

I attended Symantec Vision in Las Vegas last month. Even though Symantec didn’t make any major desktop announcements, there were still some cool little things worth discussing here.

First is that Symantec created something called a “Layer Definition Tool for Symantec Workspace Virtualization.” (Workspace Virtualization is the new name for what was Altiris SVS—Symantec’s app virtualization product.) The Layer Definition Tool allows anyone to import/export XML configuration “definition” files to and from app virtualization packages. The idea is that a customer could create and perfect a virtual app package and then export its configuration. A different customer could then import the definition file which would rebuild the final package with the second customer’s binaries. This is useful in situations where people want to share packages but the original package creator doesn’t have legal rights to redistribute the binaries.

The Layer Definition Tool actually came about because Symantec’s own IT department uses Workspace Virtualization to deploy Microsoft Office to Symantec employees. And of course they have access to the team who created the product, so you know they can build the world’s most perfect Office package. The problem is that customers who want to use Symantec Workspace Virtualization to deploy Office have to start from scratch. So you have Symantec Corporate with this awesome package while customers have this amateur next-next-next effort that’s not cool at all. And up until now the only solution has been for Symantec to publish huge step-by-step documents that walk customers through all the boring steps.

This situation led Symantec to create the Layer Definition Tool. Now Symantec’s own internal IT department can export the definition file from their Office package which they can post publicly. Then any customer can download that file and use the Layer Definition Tool to rebuild the final package using the customer’s own copy of Microsoft Office. (And for packaging apps whose source installation files are available on the web, the Layer Definition Tool can automatically pull those in on its own, making even easier for the final customer to build the package.)

At this point Symantec has quite a few Layer Definition Files available for download, but I think the ultimate benefit will be the peer-to-peer sharing this can enable. I imagine that the app deployment forums of the future can be full of people sharing their Layer Definition Files instead of text-based answers to questions like, “How did you package X?”

And once admins download a Package Definition File, they’ll be glad to know that they can just import the definition and rebuild the package on whatever machine they happen to be on—there’s no need to use a “pristine” packaging environment like when a new app is packaged from scratch.

If you’re interested in seeing this tool in action (and hearing more about it), check out the video I recorded of my conversation with Symantec’s Erik Hughes from the Internet Lounge at the Vision conference.

Internet Explorer 6 on Windows 7

Another side benefit of this whole import/export concept is that it now becomes possible for customers to access packages that wouldn’t otherwise be easy to make. A great example of this is Internet Explorer 6. Packaging IE6 is tough because it’s not easy to find an installer that will work on whatever platform you happen to be on. So Symantec created a definition file for IE6 that pulls the IE binaries directly from when the package is rebuilt. This means that anyone on any platform can easily create an IE6 package that will run on any platform. (To be clear, Symantec Workspace Virtualization has always been able to virtualize IE6. The new aspect here is the fact that it was previously really hard to find the source files and create an environment where you could even create this package in the first place.)

So anyway Symantec now has the ability for users to get an IE6 package they can run on Windows 7. No Terminal Server! No Windows XP Mode! And no excuses not to run to Windows 7! :)

I posted a video of a conversation with Symantec’s Randy Cook (creator of SVS and past BriForum presenter) if you’d like more info or you want to see it in action.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Is this not strictly prohibited by Microsoft EULA ? I thinked I've seen something like that which said "this is strictly forbidden to use any kind of technology to run IE6 on Win7"... The only legal way were to run it somewhere else on an officially supported plateform (Med-V, VDI with XP, XenApp on W2K3...)...


Cool - If this works it will allow me to upgrade to Windows 7.  I have two legacy web apps (internally developed) which are going to be a pain to move to IE 8


Anything made by Symantec blows...ask any former Altiris, Veritas, Bindview, IMLogic (I can go on) customer.   Their sales reps are criminals and their support is almost as bad as their end products.

Gripping - An old shitty browser running in Windows 7.  I can't understand who actually buys net new Symantec products anymore?!?!?  Every Symantec customer, colleague, friend, etc is just a customer by acquisition or association from a legacy product.

This is the brain-child of their innovation?  How is this easier then dealing or managing MED-V/TS/VDI, etc to support a legacy application?

I'm happy for RTO that VMware bought Virtual Profiles because Symantec was right on track of destroying that fine product too.


@Tony  - That might be the case but MedV is going to require more expensive hardware. I don't care how I get IE6 to run on WIN 7 as long as I don't have to buy all new PC's or pay for VDI to do it!



I have downloaded several Windows 7 EULAs from the MS website (link below) and saved the PDFs to my drive.  I can't find any reference that, to me, looks even close to the language that you mention.  Could you please specify the exact EULA where you saw this and the exact language?

Cancel expensive compared to licensing + support and maint on a new Symantec product?  MED-V requiring VT CPU is going away with 7 SP1, so how much really?  Some extra RAM?


EULA : was mentionned by customer... Let me dig for the EULA...


@Kata Tank

If company can't migrate to Win7 because a critical web site requires IE6, is MS going to force the issue\kill the migration?


Thinstall, now VMware's ThinApp has long had this capability, in fact it used to be one of my favourite demonstrations when I was working with Thinstall.

From my experience virtualising IE is often the start of your work, not the end - you'll also need to ensure that common plugins are tested - e.g. Flash, Acrobat Reader and Java!

Full set of how to do it with ThinApp here



This is much easier to support then MED-V, XP Mode, TS, because your not having to manage another shared operating system (TS), or additional operating system for each user (one XP and one Win7).

This layer definition thing also makes me think of its similarity to MSI transform file.  I know a Transform can contain binaries ,but typically they're just created to auto answer the install dialogs from a base MSI, which seems like what this layer definition files is doing.


@Tony I'm taking the following into account.

Cost of Ram

Cost for Tech to install it

Cost to manage another OS.

4X to 5X the cost of buying and supporting a virtual version which my company is going to end of life as soon as they can find an alternative web app to the ones that cost too much to port.


IE via App Virt is a half baked solution.  Anyone who's really tried this at scale knows that.  It's a nice parlor trick, but the plugins make it a PITA.



I have to agree with Shawn here.  Not only is it the plugins, but what about supportability?  For an enterprise of 10K desktops, a half-baked IE virt package that needs to be debugged and picked apart for every plugin needed is not feasible, nor would the support issues faced every time something goes wrong.


The issue with plug-ins is easily resolved with the Symantec solution.  It appears that some here are projecting the shortcomings of the architectures of the App-Virt products (that run everything from the "bubble") onto Symantec's solution.

I agree that the result of these architectures is that plug-ins are not visible to the virtual process.  No disagreement from me that this is half-baked.  

The difference is that Symantec's IE is normally visible, meaning the virtual process is not run from a "bubble".  The result is that most plug-ins just work with virtual IE!  

The plug-ins don't have to be packaged together with IE.  They can be installed normally OR run virtually - it makes no difference.  

Look Ma!  No hands!  


Have a look at VMware's thinstall - we are using it tfor the IE6 virtualization on Win7

Another option is InstallFree ( - featuring URL redirection !


Regarding my preivous post on legal issue to do so, here so additional info from my cust :

- sorry, not in EULA but in Support Agreement.

- running 2 version of IE on a single OS is not supported



Just tested Symantec's solution.   At first glance it works great!  There is no problem with Plugins!


I was clearly short on time during my last post about this topic because I had intended on highlighting the challenges of IE plugins as one problem, but the vendor support being the bigger issue.  So I'm 100% in agreement with Mike Burke's follow on post and thanks to Kata for finding the MS KB article that clearly shows that this is an unsupported scenario.  So all of you that are virtualizing IE6 on an IE8 platform, are you not concerned with being completely unsupported?  Also, how are you managing ensuring that you IE6 platform is kept up to date with the latest relevant patches, or are you just flying blind here hoping that there aren't any IE6 vulnerabilities?



The KB article noted here is quite interesting for a couple of reasons.  First, it states that multiple versions of IE cannot be supported on a single kernel.  Nothing here about licensing being an issue - only a support issue.  (NOTE: MSFT didn't support running Windows on a VM for SEVEN years and that didn't seem to slow anyone)

Second, it looks as though MSFT is saying they have no way to do this other than running a second kernel.  Problem is that is exactly what I'm looking to solve.  I'm not interested in the complexity and cost of the second kernel route.

Now, regarding support, If I use Symantec to virtualize IE and break the environment, of course MSFT is not going to support it.  If that were the case, I would deactivate the layer and see if the environment is working again.  If so, I have a Symantec support issue, not a MSFT support issue.  If something is working in the base, but not in a virtual layer, I contact Symantec support.

As a side note, patches and updates are easily done for IE.    I simply clone the layer, apply any MSFT issued patch, compare the old layer to the new one and have a delta update.  I can then distribute this patch w/o having to redistribute the entire layer.  


Eventually, when the firm grows and new shares are issued to raise additional capital, its shares will be widely traded. Such corporations are known as  public companies.