OSD Syntax for Contexting
-
Tuesday, November 13, 2007 9:22 PM
Hi,
Is there some documentation on how to implement the new features, particularly contexting, also what are the limitations when using these features? I have had both Bloomberg and Reuters Office addins running, but wanted to find out all of the options.
May I just say from what I have seen so far MS Application Virtualization is head and shoulders above the competition. Keep up the good work.
Andy
All Replies
-
Wednesday, November 14, 2007 3:59 AMModerator
There is a pretty good answer to this over on www.softgridguru.com.
Summary: It is a pretty basic contexting. It is done by editing the OSD and running on a 4.5 client, and does not even require resequencing with a 4.5 (although it is unlikely that you have old packages ready for this). It only works with two packages at a time. The package being launched references the secondary "dependent" package. The client will create a single virtual environment from the two packages. Thus there are no barriers between these two packages.
So the major app would be this "dependent" package. You still probably put all the plug-ins in a single package since it is the plugin package that a user launches (and it is often hard to train users to launch different icons for different plugins to the same app). This plug-in package is where the OSD editing happens.
-
Thursday, November 15, 2007 7:17 PM
The "contexting" feature we introduced in SoftGrid 4.5 is called Dynamic Suite Composition (DSC). The feature was designed to allow customers to package and manage Plug Ins/Add Ins and Middleware packages separately from the applications that use them.
If you have a Office 2003 package that was sequenced with a previous version of SoftGrid (say 4.1 or 4.2) you don't need to resequence that. You can now package the plug ins that you want your users to have access to separately. For example, today I sequenced the Office Converter Plug ing and added the dependency to my existing Office 2003 package by editing the OSD files of the Office 203 package. The "editing process" is simple, you add a dependency tag for each Plug In you want to add:
<DEPENDENCIES>
<CODEBASE HREF="....OfficeConverter.osd" .... >
<CODEBASE HREF="....ExcelTableMerge.osd"...>
</DEPENDENCIES>
You can certainly add more than 2 packages, and the really cool thing about it is that you can define permissions for each plug in separately. So, you could have 40 dependencies defined for Office but each user only has access to 4-5 plug ins at a time. So the users will only load and see the plug ins they were granted access to see. But the folks managing the Office package have an entire view of all of the plug ins that have been defined as dependencies in Office.
Given that, we DON'T recommend putting all of the plug ins in a single package because you will not be able to manage the users permission with the granularity that you may want to. Plus, if a patch comes out for your plug in, you don't have to impact any of the other plug ins.
The experience for the user should be exactly like it would be if the application was installed. In my example above, the Office Converter Plug In, there is nothing the user needs to know. He/she launches Excel 2003 and tries to open a Excel 2007 file. The plug in kicks off when its needed and the file opens, the user gets their task done without a problem or having to worry about any icons. If the plug in actually adds icons to the task bar or the Office ribbon, the icons will look exactly like they do if locally installed.
The same concept applies for middleware (i.e. JRE, .NET, OLEDB, etc). You can package JRE, .NET, etc on their own packages and define depedency on all of the applications that use them. You won't need to bundle them with a number of applications, you will be able to keep a single version of the middleware for all of your applications that use them.
Tim is correct that the applications will share a single virtual environment, so the applications can interact like they would if they were locally installed. That is the primary reason why we recommend this feature for plug ins and middleware, since those are not expected to conflict. If you intend to do anything larger, then you will need to do some testing prior to using it.
Hope this helps clarify a bit. I'd be happy to go more in depth on it.
Lidiane
-
Friday, November 16, 2007 1:02 AMModerator
Thanks Lidiane,
This was much clearer than what another ms person posted (and given your sig I guess we can trust you). Allowing multiple dependencies from the major app makes this much more workable.
Just to clarify, if I put two plug-ins as shown in your post, it is the user assignments of the dependent OSD that define whether or not a plug-in is included in that user's session (so I only need one master OSD of the major app)?
-
Friday, November 16, 2007 9:41 AM
Thanks Lidiane for your reply. Do you know if there is going to be support added to enable an extra level of dependencies, for example an application has an office addin but also has a dependency on Java, would we be expected to add Java to Office? Also what about environment variables, Virtual Registry, etc.. how are they carried forward to the parent application or do they need to specified in the master OSD??
The good thing is that adding contexting support, sorry Dynamic Suite Composition is a very simple process, I had a thought we could add these entries dynamically from a wrapper application to control what gets loaded. This would be useful to us as some of our addins do currently conflict. Could this be added to the management console in someway???
Thanks,
Andy
-
Friday, November 16, 2007 7:35 PMModerator
At this time there is not support for multiple levels of dependencies, you can actually set them up but they are ignored right now.
So looking at your question if you had Office and an add-in that required Java, you would have to add Java into the dependecies as well as the add-in so it would be available.
As far as the variables, virtual registry, etc. it is my understanding that the secondary packages inherit the settings from the primary package, so whatever is in the primary OSD will be the only ones that are applied in that Virtual Environment. In other words it doesn't actually look at the .OSD of the secondary.
<VIRTUALENV>
<DEPENDENCIES>
<CODEBASE HREF="PATH TO SFT",GUID="GUID OF PACKAGE", SYSGUARDFILE="CP FILE", SIZE="SIZE OF PACKAGE", MANDATORY="TRUE/FALSE"
</DEPENDENCIES>
</VIRTUALENV>
So to finalize we aren't actually pointing to the other osd, just pulling these specific settings out of the OSD for the secondary application. Mandatory is the only one we can't copy out of the secondary OSD and it sets up whether or not this secondary is mandatory to load or the primary fails to load as well.
Hope this helps.
Matt
-
Monday, November 19, 2007 1:55 AM
Thanks Matt for responding. I was travelling and didn't get online again until today.
You are correct, we do not currently support multiple levels of dependency and the settings are always saved to the primary application. I think you responded to all of Andy's questions...
Just to respond to Tim's question regarding the users' permission, you would add permission per package in the management console. So, you would have the Office plug ins and Java packages in your server management console and you would give each individual package the appropriate permission. As Matt mentioned, the OSD is only used to get settings for the plug ins. The dependencies definition would only be in primary package (so for Office would have all of the dependencies, you wouldn't need to have them in the plug ins' OSD files).
I will be on holiday for this next week, but I will be posting more specific examples of Dynamic Suite Composition on our team blog soon: http://blogs.technet.com/softgrid/
Thanks,
Lidiane
-
Tuesday, November 20, 2007 8:38 PMModerator
Thanks for confirming that.
So it seems that we should have a solution (I haven't tested this yet) for handling conflicting plug-in's as well!
Lets say we have plug-ins A, B, and C; and Z conflicts with C. We sequence the major app and we sequence each plug-in separately. We make a copy of the major app OSD with a new name. In the original, we place A and B dependencies; in the copy we place B and C dependencies. Now assign the original and copy OSD and plugins as appropriate.
-
Tuesday, November 20, 2007 9:46 PMLidiane and Matt,
This is some of the best info I've seen on DSC thusfar. Thanks for the detailed explanations. Now all I gotta do is get some free time to start playing with it.
Thanks.
Shawn -
Wednesday, November 21, 2007 5:11 AM
Second that! Great info being passed here for DSC.
Question on the dependancy permissions:
For the sake to ease the overhead in who can use what plugins/middleware, would there be repercussions with unchecking all shortcuts(unless needed) for each one and assigning access to these plugins/middleware to Domain user? This way I only need to worry about the access permissions of the parent application and free to add any dependancy needed.
Now if only a new version of the OSD Editor utility came out to to include additional fields for dependancies, that would be golden!!
-
Wednesday, November 21, 2007 9:01 AM
Great to see my original post is bearing fruit, a couple things I would like to see would be for each dependency to optionally specify envrionment variables and virtual registry entries in the OSD.
I have an issue where I am having to include a Path variable that will include paths not available to some users, being able to conditionally add entries would be a benefit.
Also as an aside, my users make great use of Refresh Applications on the Task Bar icon, would it be possible to make the icon animated whilst it is perfoming this task, my users come from a NAL environment and are used to this feature as it can be useful.
Keep posting those great ideas around DSC.
Andy
-
Wednesday, November 21, 2007 2:55 PMModerator
You can put a script in the major app OSD to do this. The script would check for the existance of the path and if so update the path variable. Or just add them in as they do no harm in the Path variable (other than a tiny-teenie-weenie bit slower that you can't measure) even if they don't exist for some users.
The original version of the tray icon blinked anytime there was rtp activity. This was removed in some release - maybe about 3.5? - as customers complained about it. They should have just made it a config option I guess!
-
Wednesday, November 21, 2007 3:39 PMModerator
ixtc4233 wrote: Second that! Great info being passed here for DSC.
Question on the dependancy permissions:
For the sake to ease the overhead in who can use what plugins/middleware, would there be repercussions with unchecking all shortcuts(unless needed) for each one and assigning access to these plugins/middleware to Domain user? This way I only need to worry about the access permissions of the parent application and free to add any dependancy needed.
Now if only a new version of the OSD Editor utility came out to to include additional fields for dependancies, that would be golden!!
Here are the steps
1. Sequence Major App (office or middleware, I always think of database)
2. Sequence Add ins or in the case of middleware front end apps separately in its own package. (remember in these cases the major app will have to be on the sequencer prior to sequencing.
3. Use the Dependencies tag to assign all add-ins or front end apps (for middleware)
4. Assign permissions (AD Groups) to the Major app for all users that will need the base major app
5. Assign permissions (AD Groups) to the appropriate groups for each individual add-in or front-end app for the appropriate groups that need them.
This way you only need to have one modified OSD for the Major app and can control who gets what add-in or front-end app through the permissions to those packages. You are correct in stating that we would remove the shortcuts as we are depending on those being presented in the Major app for add ins. For Middleware this may not be the case as it might be database middleware and we would still need a shortcut to launch the front end app.
There are a few scenarios where this may not be the case. Tims proposed conflicting add-ins would be one another might be when a user needs to use the same middleware with multiple front ends where we need separate settings for each of those front end apps. And as always remember that all user specific settings are stored as part of the Major app and not the secondary appication.
So in summary you are correct with the way you are talking about doing this, but there would be some scenarios where we may have to have multiple major app packages to resolve certain issues. As far as the OSD editor presenting these options, I am not part of developing the sequencer and OSD editor so this question is for someone making those decisions, but I agree it may prove to be very useful.
Thanks for listening
Matt
-
Thursday, January 17, 2008 6:12 PMModerator
I think I need more guidance on sequencing the plug-in.
Does "remember in these cases the major app will have to be on the sequencer prior to sequencing" mean
A) Use the "dirty" sequencer system in the state it was after you saved the MajorApp.
B) Use a clean sequencer and natively install MajorApp.
When we sequence AddInApp, do we
A: Sequence into Q:\MajorApp
B: Sequence into Q:\AddInApp
I am guessing you mean answers A and A?
-
Thursday, January 17, 2008 10:07 PMModerator
Tim
Great question, if I understand you correctly it would actually be answer B and B
You would have your sequencer with say office installed locally and then you would sequence the add in as a completely separate app, not in a suite like we have done in the past.
Then you would use the <dependencies> tag in the Major app under <virtualenv> and copy the <HREF line with the previously discussed properties into the Major app OSD. This could be done for multiple Add INs, but the assumption is that all of the add ins would be sequenced separately as though they were going to be stand alone apps. Then we can control the access to the add-ins by using the Access Permissions in the app record in Data store, thru the MMC.
This really changes the view of what we did with the sequencer in the past which is have it will as little or no software on it at the time of sequencing. We may have a virtual machine that had OS and Office as a saved config so we could revert back to it for each Add IN. Or in the case of middle ware an OS and database tools as a saved config.
I hope this helps.
Matt McDermott
-
Thursday, January 17, 2008 10:59 PMModerator
Thank you - great stuff. I think that means I had the "other" scenario wrong. So please verify this:
I have 5 applications that all need a java. I can do this by:
A) Sequence Java on clean machine
B) Sequence AppA on machine with Java natively installed.
C) Sequence AppB on machine with Java natively installed.
D) etc for the other three apps.
E) Edit AppA.osd and add the codebase line (plus MANDATORY="TRUE") as dependency.
F) etc for other four apps.
-----------------
Also, can you address MANDATORY? If I leave it off what is the default? How does it work? I am guessing that MANDATORY="TRUE" means that the dependency must be assigned to the user and must be actually available on the server or the client will not launch the app, while a false means it can continue without it if not assigned.
-
Friday, January 18, 2008 3:09 PM
Yes, your steps are correct, as well as MANDATORY=TRUE. User must be able to run the dependency or the main app will not run. So the user needs permissions to the dependency and the dependency must be available for streaming or already cached.
FYI, the MSI Utility itself does not ensure this dependencies are available. We'll have to make sure the ESD delivers Java before App A.
-
Friday, January 18, 2008 5:01 PMModerator
Thanks for getting to this, I was just getting ready to post on this. And thanks for the extra on the MSI Utility. I haven't had time to test that yet and was wondering how it worked with it.
Matt McDermott
-
Thursday, February 14, 2008 5:53 AMah, very nice, wasn't aware of the MANDATORY TAG...
-
Thursday, February 14, 2008 11:18 AMJust a quick thought;
I'm happy with having to install the primary app natively to the sequencer prior to creating the secondary app package, but surely you must have to the same path as you did while sequencing?
If you don't, isn't there a chance that the 'helper' app will have recorded file locations (eg when mailto function is used, outlook.exe can be found in C:\Program Files\Microsoft Office\Office12\... instead of the actual path of Q:\Off2k3\Office12\...) which could cause problems if there are differences?
Am happy to be corrected though! -
Saturday, May 10, 2008 1:13 AM
Hi ,
Please let me know how do we do DSC if we are using standalone method i.e MSI installation method with out the publishing from softgrid server.
Thanks
-
Sunday, May 11, 2008 3:52 AMThere is no DSC in the Standalone method, you'll just have to suite those apps in with the parent, then generate and install the MSI.
-
Sunday, May 11, 2008 7:23 PMModerator
The MSI packages output by the current MSI Utility (January) will not install on a client with the 4.5 beta client.
I am guessing that those produced by the 4.5 sequencer internally, might. Maybe someone from Microsoft can cliarify.
-
Friday, June 06, 2008 8:56 PMModerator
Tim
The MSI packages created today use a different method of importing the application on a stand alone client and will not work with 4.5.
As you know the 4.5 sequencer allows you to create the msi as part of the sequencing process, these MSIs will be compatible with 4.5 only.
If you have created MSIs with the stand alone utility you would need to reopen the packages with the 4.5 sequencer and then resave the new (different) msi.
Since this is on an answered post I don't know if anyone from MS will get to it. I just happened to see that you posted on this May 11 and decided that if anyone needed an answer that I would provide.
mattmcdermott
-
Friday, February 06, 2009 8:17 AMReopening the package and saving with 4.5 was informative
Cheers
J.Caleb Kirubakaran
.png)
