Add-ins, Add-ons, Plugins and Fonts

Posted by Brad Rowland on Feb 27, 2015 2:05:00 PM

Find me on:

The topic of managing applications on a per-user basis usually focuses on the Big A of Applications, and leaves out all the various additional modules and components end-users need to be productive.  This can include things like browser plugins, toolbars, applications add-ons, and fonts.  But in many enterprises, it's exactly these additional components which add exponential management complexity above and beyond the application itself.

For example, in the world of application virtualization there's rarely such a thing as a standard browser package, since even the addition of a simple toolbar for a specific workgroup requires the creation of a second package, not to mention requirements around browser versions and versions of Java for browser based apps.  Each unique component requirement spead across the needs of different workers can cause the number of packages needed for just a single app to skyrocket.  Pretty soon your "IE package" has become a very large library of IE packages.

In an earlier blog post, App-V guru Tim Mangan talks about the challenges of sequencing IE with various plugins, and in his usual expert way he proposes solutions and workarounds to succesfully create packages.  With the right experitise you can do it, but is all this work really needed?

Obviously there needs to be a way to customize a user workspace.  Unnecesary components can dramatically add cost and burn resources, especially in RDSH environemnts.  A single commerical-use font package can be in the $200 range and should only be deployed to users who need the font.  A CAD plugin can take up valuable memory and CPU cycles and should only be loaded and active for CAD users who need it.

Today's standard practice of layering, re-packaging, and 'componentizing' is already far too complex for applications, let alone the myriad combinations needed to support every font, plugin and add-on that business critical apps require.

In the FSLogix alternative approach we use Image Masking, which determines the specific components made accessible to the user workspace from their base image.  This design allows administrators to build Unified Base Images, containing all applications and components required for a site, department, or workgroup in a single gold image.

The question really is, if you didn't have to repackage everything, create layers, and break down images into tiny little components, would you do it anyway?

This one and a half minute video demo is a demonstration of FSLogix Apps controlling the visibility of the Workshare Office Add-in. This shows how to control which users have access to the plugin. This has licensing, memory, and load time benefits and is easily controlled from a single image.

 

 

 

Topics: App-V, App Packaging, App Virtualization, Image Masking

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all

Follow Me