Virtualization

1) Context menus can be solved by using something like a43 or xplorer2 published as an icon but that might not be useable. The other solution is to deliver an MSI that changes the context menus to call SoftGrid applications via command line.

2) Yes, this is by design and does suck.

3) There are two schools of thought. Keep your sequences clean to prevent unforseen issues such as your sequence superceding settings in the OS or just run with it and not care because it is virtual.

Thanks for the response - that's useful info [:)]

The other solution is to deliver an MSI that changes the context menus to call SoftGrid applications via command line.

With this suggestion are you saying to deploy a standard MSI package (not virtual) with just the context items / command lines? If so they isn't it just easier to deploy packages like this in the traditional way and forget SG?

I've read that SG isn't suitable for apps that rely on services which run on startup and apps which require drivers over and above the standard windows ones. So perhaps this should also include apps which integrate into the windows shell?

I'll check out the a43 and xplorer2 stuff you mentioned - thanks again.

Cheers,
Rob.

Apps that need shell integration (document management products, Adobe, WinZip etc...) should be considered candidates for a physical install if being creative is considered unsupportable and I don't blame you. Services and drivers do get dicey because services that run in system context aren't supported but may work depending on what the service is doing. License services might need to be managed because the license service will be started per-user and not per-machine so you might need a pre-launch script to manage that. Drivers can be used if you can find a way to deploy it seperately from the app (DIFx) but you have to keep in mind if the driver initiates communication with the application then it'll likely not work at all.

You shouldn't have to clean up a sequence but in some cases it could be an issue depending on what the sequencer captured and what changed in the physical world that the application needs to see. Maybe you delivered a series of locked down Internet Explorer sequences and now you need to change the proxy configuration. You may have wanted your sequences to pick that information up from the physical registry but the sequences aren't built that way. Not the best example but you get an idea that the potential issue does exist but likely not as severe as deploying a bad MSI because it's much easier to deploy a new virtual environment. I still clean my sequences but I don't give it the same analysis I would with a setup captured MSI.

Thanks again for your time kkaminsk

The other solution is to deliver an MSI that changes the context menus to call SoftGrid applications via command line.

Regarding this suggestion - can help with an example of a command line to call a SoftGrid application? Obviously the softgrid command to launch an app is something like "C:\Program Files\Microsoft SoftGrid\Microsoft SoftGrid Application Virtualization for Desktops\sfttray.exe" /launch "WinZip 18.0.6028.0" but I don't get how you'd specifically call the WinZip.exe since the Q:\ can't be accessed...?!

I am a SG noob so apologies if this question is plan stupid [&:]

Regards,
Rob.

Yeah with SoftGrid you call applications either via name or OSD and that gets translated to the exe under FILENAME in the OSD. Remember that the call with SFTTRAY.EXE is case sensitive with regard to the application name and to reduce pain you might try to leave the OSD version out of the call unless you need to have multiple versions of the exact same SoftGrid application name in production. The database requires that each application must have a unique name + version so there can't be duplicates.