Post to Twitter |
Comments (2) |
Views (7556) |
This is the 3rd post in a series on Inter-Isolation Communication. I previously shown the layers of glass with IIC and how the streaming profiler can mount sub-profiles as a part of running an installer for a new profile. This post describes how ANY profile can be "sub" to another profile and how "profile trees" result that are potentially far deeper than one level.
Consider that before inter-isolation communication, administrators wanted to allow communication between sandboxes. They want to have two profiles that they know are good; but want the applications in those sandboxes to be able to talk at runtime. With inter-isolation communication, any profile can be part of an IIC profile. The existing profile can even be made with a profiler that had no idea what IIC was. The IIC supporting profiler and client first shipped with XenApp 5.0 (Streaming Client 1.2), but the profiler/client at this level can define IIC links to profiles created at earlier levels.
It is easy to consider that an IIC profile links 2 or more sub-profiles. What is not so obvious is that IIC profiles may themselves be the item that is linked. That is, the IIC profile may be the "linkee" rather than the "linker".
Consider this graphic 
It is much to consider, but "TOP" is a dependent profile that links to 3 other profiles. As TOP has its own isolation target, the profiler will mount everything underneath as a part of running the profiling activity to support creation of the Target at top. The profiler supports setting the relative height of isoaltion spaces within a profile, so the order of A, B and C can be adjusted. The layers of B1 and B2 though are defined as part of profile B and must be adjusted at that level.
Configuration of the profiles
A.profile may have come from an ealier version of the streaming system, where it did not know about IIC.
B.profile is "links only" and this means that it was created with the IIC supporting streaming profiler and since it is an associative profile, it is merely "pointers" to the dependent profiles, which are B1 and B2.
C.profile is very much like TOP. It mounts the C1 profile and then C has a produced execution target of its own which is the result of running installation activities while editing C.
Eventually, TOP exists and all of this stuff is stored on an Application Hub, somewhere on your network.
NOTE: All profile links are by name only and are required to be on the same application hub/file server. This is on-purpose so that all links are "relative" and the profile content can be moved from one server to another without having to edit any of the profile information.
PUBLISHING
When publishing applications, the Access Management Console will open TOP.profile and will present a set of applications for publishing which is the SET UNION of all of the sub-profiles. It is possible that you want to publish all of the applications, but possibly more likely that you want to publish a subset. Either way, as the administrator, you have the full set available for selection and it doesn't matter which target provides the initial executable.
That pretty much puts it all together. This stuff has been out for a while, its complex - but powerful.
Joe Nord
Citrix Systems
Comments (2)
May 18, 2009
Anonymous says:
Hi Joe. Always great articles. I've been a big fan of application streaming si...Hi Joe. Always great articles. I've been a big fan of application streaming since the early days.
On a somewhat related IIC profile tree topic I'd like to ask a question regarding Internet Explorer plug-ins. I've spoken briefly to our local Citrix representatives about this topic but they suggested I post the question to you.
I love the idea of being able to stream plug-ins, whether it be to XenApp servers, XenDesktop or simply workstations. What has always bugged me however is the best way to provide the entry point to gain access to the plug-ins. Plug-ins are often frequently updated - Flash, SilverLight and even Adobe Reader (when integrated with Internet Explorer - which works great when installed as a 'plug-in' by the way). A user often has a shortcut to Internet Explorer embedded (pinned) in their Start Menu and sometimes another on the desktop and Quick Launch bar. If I stream Flash Player, I don't want to have to tell a user '...don't launch Internet Explorer using the default pinned Start menu shortcut - use the shortcut I published for you'. This just isn't intuitive. Is there anything in the pipeline that will be able to replace the default Internet Explorer shortcuts with an 'entry point' in the 'Top Profile' that has been defined by the Administrator with all the required plug-ins provided as sub-profiles? I can see some of the issues that this would raise, but none that perhaps couldn't be overcome with some solid work. Perhaps there are some other more intuitive means that I haven't considered?
Any comments on the topic ar emore than welcome. It might it even deserve it's own complete discussion on your blog
Thanks in advance.
Steve.
May 18, 2009
Joseph Nord says:
Good points Steve and thanks for the nice comments. As for conflict betwee...Good points Steve and thanks for the nice comments. As for conflict between streamed vs. not and how the users tell the difference, the obvious response is that the users shouldn't have any idea which is what, and you know this already. It's a particular headache, an hour after the user launched the browser and then uses what ever browser window they find to browse to the next website, where the right plugins may or may not be in place. With IE, the launched app (streamed) will at least take the user to the right place, with the right plugins, but it would be easy to confuse up the windows later in the session.
The "easy" answer is to replace all the "regular" start menu and quick launch icons with icons of your own, which call the streamed app that has the plugins. Some of this can be done via AMC (Start menu), but the quick launch isn't exactly covered. You can code your own calls to RadeRun.exe to get this going. If stream to server, you're good here today, if stream to client, this direct use of raderun will be enabled in ... some day. Another good topic for a blog post. I demoed this at Synergy presentation 2 weeks ago.
The complications you describe also apply to programs that pass execution off to earlier instances of themselves at runtime. In these "problem cases", the application launches, and says "OH!, I'm already running" and hands the command line over to the already running version, then terminates. Examples here include firefox with same "profile" and winword from MS Office.
Enjoy, Joe
Anonymous replies:
Add Comment