You will soon have this tool called “Inter-Isolation Communication”.  Great!  What do I do with it?

Answer: You have less points of maintenance for Application Streaming while retaining isolation and centralized updates.

Example scenario: 1 Big app + 1 small addition = single thing you want to publish.

Lets call the big application “MS Office” because everyone knows that MS Office is big. Its also a convenient example because there are numerous add-on programs that install “on top of” the base application.  

Let’s also assume that you have different “add-ons” to install for the different groups that you support.  Everyone uses “big app”, but they all use it differently based on their job function.  To get this to show the power of single point of maintenance, we’re going to say that you have a really big shop that has 10 different deriveratives of “big app” that you have to publish.  Back-step: I ran out of job titles, so we’re gonig to use 5 different deriveratives!

The groups:

  • Execs
  • Sales
  • Finance
  • Accounting
  • Programming

NOW – Each of these groups has different requirements for add-ons.  You as the administrator install the base “big app” and then install the add-on and then you store the application away where folks of that group can access it.  Before Isolation and Streaming, you create a MSI that gets pushed down to end user machines with the correct package set for that user.  With Isolation and Streaming, you still use the MSI, but you instead use it to create a centralized profile.

With Streaming, but before IIC, what did you have?

Answer: 5 different installation images for MS Office where each was really MS Office + some other installer. 

If you want to update the add-on installation, no problem, you update your profile and store it – the streaming system then kicks in to get the profile update out to all your users.  Great.  BUT!  What if you want to update “big app”?   In the App Streaming or (insert other streaming system here), you now have 5 points of maintenance compared to 1 when the application could be locally installed.  Notice that this is a univeral problem to all application isolation systems.  Streaming and Isolation are great!  Centralized publishing, isolation, resolution of DLL Hell and a variety of other good things. BUT if you have 5 points of maintenance on “big app”, then that rather reduces the value of going to streaming.

Inter Isolation Communication gets Streaming back on the same maintenance foot print with locally installed.

With IIC, you have only 1 instance of “big app” and you also have 5 profiles of deriveratives of “big app”.  Interestingly, the applications you are interested in running are all from “big app”, but the profile you publish from will be “sales on top of big app.profile” and “execs on top of big app.profile”.  Inter-Isolation Communication will RUNTIME MERGE the profile for big app with the deriverative profile and this is why it is so important.

A single update to “big app” will immediately benefit ALL of the derived profiles.  This makes maintenance just as easy as locally installed, while retaining isolation!  Great stuff.

A studious reader will notice that IIC to some degree also brings back some of the issues that isoaltion is intended to make go away.  True.  Its rather a balancing act.  In the first releases of Application Streaming, we had isoaltion on the brain and when no other decision exists, we isolate!  This isn’t always what the administrator wants.  The admin wants to isolate the isolated application from the system and they want to isolate the isolated application from other applications, but they do not want to isolate “big app” from “addition to big app”.   The later is “known to work” with big app and this is how the IIC subsystem runs the apps.  Big app and addition to big app run in the same isoaltion space – but they are still separetly cached and they are maintained in their separate profiles.  

Is DLL Hell back

Yes!  You can control it though.  Given that two profiles linked at runtime both have a single DLL and that the order of installation of the linked profiles MATTERS!  Then there exists a scenario where defining a link relationship between apps can expose a DLL Hell dependency.  The 1.2 Streaming Profiler allows control of this on the page where the relationship between linked profiles is defined.   Here’s a picture.

Notice the “Move up” and “Move down” buttons on the right.  When a sub-profile is selected on the left, its position in the isolation stack can be adjusted.  Using the layers of glass analogy, the higher profile in the GUI is the highest layer of glass.  That means that IT WINS compared to lower profiles.  If DLL Hell is detected, you could just erase the offending file from a higher level profile and let the lower level shine through – you can also adjust the relative position of the isoaltion layers to have the same effect.  This GUI is where that configuration occurs.

IIC will be a powerful tool in the XenApp adminstrators toolbox.  I expect to be surprised at how it is put to use. 

Happy Streaming!

Joe Nord, Product Architect – Application Streaming, Citrix Systems