Making SoftGrid Apps Work On the Road

I’m a big Microsoft SoftGrid Application Virtualization fan. With Soft- Grid, I don’t have to actually install applications directly on my client machines. Instead, I get the sweet ability to let users run applications that are on a server but use the client computer’s horsepower—and I don’t have to worry about the dirty job of handling software conflicts. Even if users have never used an application before, they just click an application’s icon on the desktop or Start Menu and the application launches from the server— all the while, the application is never actually installed on the client machine.

Once you’ve set up SoftGrid on the server and clients (see “SoftGrid for Application Virtualization,” September 2007, InstantDoc ID 96625) it elegantly distributes the application: First, the SoftGrid client makes a request to the server, then the server streams as much of the application as the user needs at that moment. On the client, SoftGrid caches any part of an application that a user accesses. If a user has previously used an application, or even just part of an application, that portion comes from the cache, not the server. But if a user needs more of an application, say, Microsoft Word’s Thesaurus, the SoftGrid client then automatically connects back to the server and downloads (and caches) just the bits it needs and makes the cached feature available for next time.

SoftGrid’s a great solution for desktops, but what about laptops? If a user on the road wants to access Word’s Thesaurus feature, but has never used it before, that user could have a little problem. Well, a big problem. In fact, depending on the application, your user could receive a terse message to close the application in two minutes or it will shut down. Ouch! Harsh! I’ll show you some ways to avoid this problem and help your users get the most out of SoftGrid while on the road.

SoftGrid for Road Warriors

Problem: Without access to a server, users can’t access all features of their SoftGrid applications on the road. Solution: Pre-load applications by converting an existing SoftGrid sequence to an .msi file and deploying that file by using Group Policy, SCCM, or any systems management tool. What You Need: An existing SoftGrid implementation; MSI Utility for Microsoft SoftGrid Application Virtualization; and the SoftGrid 4.2.1 client Solution Steps: 1. Have a SoftGrid infrastructure already in place. 2. Get the MSI Utility for Microsoft SoftGrid Application Virtualization. 3. Make sure you have an updated SoftGrid 4.2.1 client running in Offline mode on your target system. 4. Convert an existing SoftGrid sequence to an .msi file. 5. Deploy the .msi file using Group Policy, SCCM, or any systems management tool. Difficulty: 3 out of 5

You have three options for helping users take advantage of SoftGrid on the road. Two unfortunately ask the user to do something (or to use an inelegant script). But the third is more robust and the one we'll explore further. As you’ll see, it lets you pre-load specific applications by using the software deployment infrastructure you already have, such as Group Policy, Microsoft System Center Configuration Manager (SCCM) 2007, or something else.

Option 1: Let your users do it. You can ask your users to try to use all the functionality in the office before they go, so they’ll have what they need while on the road. This option fails the moment you get a phone call from the CIO asking why Microsoft Excel Pivot Tables won’t run while she’s using her laptop at 30,000 feet. Of course, if the CIO had used that particular feature while connected to the network, you wouldn’t get the phone call, but obviously it’s not ideal to rely on users in this way.

Option 2: Force the entire application into the cache. The SoftGrid client has a command-line switch that can force all of a particular application (or all applications a user has access to) into the cache before users take off for a trip. You could teach users to perform this step. Or, you could use a Group Policy script to force this to occur under certain creative conditions. (For instance, you could create and deploy a shutdown script that asks users which applications they want to take on the road with them; however, that’s an exercise beyond the scope of this article.)

When you prepare an application for SoftGrid distribution, you have to “sequence” it (make it a streamable application from the original application media). Part of sequencing requires creating an Open Software Description (.osd) file. To tell the client to cache a specific application, you need to know the precise name of the .osd file that the client uses to pull information about the application from the server. The person who sequenced the application should be able to provide this for you (it’s a property of the sequenced application).

With the .osd file name in hand, you can ensure, for example, that 100 percent of your Adobe Reader sequence will be loaded on the client. Ask the user to execute the following on that client (or make a script to do it):

sfttray.exe /load “Adobe Reader 7.0 
  7.0.8.218”

sfttray.exe /loadall

Options 1 and 2 have drawbacks: Users still need a connection to the server to “get more.” And it’s still a manual or scripted process to either load additional pieces of the application or cache the application in its entirety.

It would be better if you could pre-load specific applications by using a technique you already use for other areas of software deployment. That would be Option 3.

Option 3: Deploy sequences wrapped up as Windows Installer applications to SoftGrid clients in offline mode. I’m a Group Policy geek. So I was disappointed that there was no way to deliver SoftGrid sequences via Group Policy. Well, that’s changed. You can configure the newest Soft- Grid client, SoftGrid Client 4.2.1, to work in a new mode called Offline mode. Then you can specially deploy sequences wrapped up as Windows Installer (.msi) applications. Upon deployment of these .msi files to SoftGrid client computers, 100 percent of the application is forced into the cache. This gives you the best of both worlds: You can deploy sequences using tools you love (Group Policy, SCCM 2007, LANDesk, or anything else that slings .msi files) and force specific applications into the computer’s cache. With this approach, you don’t have to leave the onus on users to do anything to ensure their applications are fully cached.

Continue on Page 2

   Previous  [1]  2  3  Next