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

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”

Or, alternatively, you can tell the SoftGrid client to force load all applications the user has access to by using this command:

sfttray.exe /loadall

However, note that the client cache size can't be exceeded. The cache size is a hardcoded limit that administrators declare on the SoftGrid client at client setup time. The default size is 2GB and is changeable only during client installation. Also note that after the cache fills up, the application that’s currently streaming will stop streaming, then display a Launch Failed message.

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

To Get Started
The magic of Option 3 begins with two components. Here’s what you need to get started:

Component 1: The MSI Utility for Microsoft SoftGrid Application Virtualization. The MSI Utility is a tool that wraps up the necessary SoftGrid application bits and puts them into an .msi file—all the bits, that is, except the .sft file. This file might be too big to fit inside an .msi file because it actually contains the application. We’ll see how to perform this wrap-up of existing SoftGrid sequences in just a bit. Then, when you deploy the .msi application (using any tool you like), the installation doesn’t actually install the application. Rather, the .msi installation is simply directed to fetch the .sft (the actual application sequence) file and stick it all in the local SoftGrid cache. (See the sidebar “Using the Softgrid SMS Connector,” page 50, to see why you must use the MSI utility instead of the Softgrid SMS Connector.)

Component 2: The updated SoftGrid Client (at least 4.2.1) running in Offline mode. Just because you wrap up SoftGrid sequences as .msi files, and deploy them using Group Policy (or another method) doesn’t mean that regular SoftGrid clients will know what to do when they receive the .msi package. To be able to run the .msi files you’ve created with the MSI tool for SoftGrid, you’ll need to upgrade (or freshly install) SoftGrid Client (at least 4.2.1) over your client population for those clients you want to work in Offline mode.

SoftGrid Client (at least 4.2.1) is available at support.microsoft.com/kb/941408. A quick note to save you heartache: Be particularly careful that you’re downloading at least the 4.2.1 client (as of press time the latest is 4.2.2.15) and not the 4.2.0 client, which is also confusingly located on the same Web page. I spent four or five hours pulling my hair out, only to find out I downloaded the wrong client.

Also note that the SoftGrid 4.5 beta Client (not on the same Web page, thankfully) won’t accept .msi packages created using the MSI Utility. You must use at least 4.2.1 to perform the magic. A warning, though: If you upgrade your older SoftGrid Client to the newer Soft- Grid Client (at least 4.2.1), the applications cache is flushed and all packages need to be redownloaded.

Force the SoftGrid Client to Offline Mode
For this article, we’ll install SoftGrid Client 4.2.1 into Offline mode manually. To do so, just run the setup using the msiexec /i command with the MSIDEPLOYMENT= TRUE flag, like this:

msiexec /i softgrid-wd-setup.msi  MSIDEPLOYMENT=TRUE

Next, set up the SoftGrid client as you normally would through the standard Wizardbased installation. However, when you get to the Desktop Configuration Server screen, which Figure 1 shows, enter nothing and click Next. That’s because the client doesn’t require a connection to any server. Remember, it will be working offline.

Because you used the special MSI-DEPLOYMENT=TRUE mode during installation, the client should put in some special registry entries that tell it to work in Offline mode. A quick test you can do after the client is finished installing is to open up the client’s registry editor and dive down into HKEY_LOCAL_MACHINESOFTWARE SoftricitySoftGrid ClientCurrentVersion Network and look for a subkey called Online. If Online is present and set to 0, your installation into Offline mode succeeded.

However, note that one registry option isn’t automatically set correctly and really needs to be changed. That subkey is HKEY_LOCAL_MACHINESOFTWARE SoftricitySoftGrid ClientCurrentVersion Network and the value is DOTimeoutMinutes. DOTimeoutMinutes should be a DWORD set to ffffff (that’s six fs). This setting instructs clients to cache applications offline for 31.9 years, as opposed to the default of 90 days. It would be pretty inconvenient if on the 91st day these applications suddenly stopped working.

Convert the SoftGrid Sequence to an .MSI Package
Again, the whole point of working in Offline mode is to be able to run a sequence entirely in cache, without any maintained connection to a server. To do this, you use the MSI Utility to convert your existing packages and projects to an .msi package. You can find the MSI Utility at tinyurl.com/2zlpyq.

After you run the MSI Utility, you simply point it toward an existing .osd file (with the .sft file in the same directory). In Figure 2, you can see how I’ve pointed the MSI Utility toward my Adobe Acrobat Reader project file and how the output .msi file is created in the same directory. The whole wrapping process takes about two seconds for each application.

Note that the large .sft file isn’t included in the new .msi file. The .msi file is simply a new way to launch the installation. The .sft file still needs to stick around and be available at install time. Again, we’re not actually installing an application on the client; we’re installing the .msi, which pushes Acrobat Reader into the local SoftGrid cache.

Continue on Page 3

Test the New .MSI File
Now that you’ve got your new .msi file, you’re ready to test. Figure 3, page 50, shows a Group Policy Object (GPO) that I used to deploy the newly wrapped sequence of Acrobat Reader (as an MSI) to computers. Note that the .msi and .sft files are in the same share (in my example, it’s called sgContent), which you can also see in Figure 3.

Remember that users need to be able to read the .msi file and the .sft file through the share. So, be sure that the permissions are set to Read for Authenticated Users on both the share and within the underlying NTFS permissions. That way, users and computers, which are both considered (strangely enough) Authenticated Users, can access the files. Without Read permissions to Authenticated Users your deployment will fail.

When a SoftGrid client that’s set up for Offline mode reboots, Group Policy looks to see whether any .msi applications are ready to install. If they are, at this point 100 percent of the .msi application is placed into cache. Now, whenever a user logon occurs and a user tries to run the SoftGrid application, the application is simply pulled from the local cache and not from the server.

Mitigate the Downside of Offline Mode
Yes, there are several disadvantages to using the SoftGrid client in Offline mode. Here’s a breakdown of the top issues and how to mitigate them.

Once in Offline, always in Offline. The SoftGrid Client can’t switch on the fly between Offline mode and original streaming (Online) mode. So, you have to specifically dictate which SoftGrid clients will work in Offline mode and which SoftGrid clients will work in Online mode.

To mitigate this issue, have a plan about specifically which client computers should get the Offline client and document them. Troubleshooting SoftGrid Online clients is going to be different than troubleshooting SoftGrid Offline clients. In short, you’ll likely want to stay with the Online mode for desktops and switch to the Offline mode for laptops.

All Online clients suffer for the good of the Offline clients. If the .msi package gets targeted for regular SoftGrid clients (those not set to Offline mode), you might still see the .msi try to install each and every time regular online SoftGrid clients reboot. That’s because the .msi package tries to process but can’t successfully install to an online client, so it just times out. This timing out adds to the computer startup time for regular online clients. To counteract this, be sure to target your .msi packages only for Offline SoftGrid clients.

Offline clients are exempt from some key SoftGrid features. Any clients that use Offline mode are automatically exempt from SoftGrid’s nifty auditing feature and software metering. This is because the whole sequence is running locally, not off the SoftGrid server, so there’s no checking-in process and no way to audit or meter for license overuse. No solution exists currently to mitigate this problem. If you need to ensure an audit trail each time a SoftGrid application is run, you must use Online mode.

Take Clients Off the Network
The MSI Utility and the new SoftGrid Client 4.2.1 can help you take your clients off the network and let them work with applications anywhere. And you can use the tools you already know and love to deploy your SoftGrid sequences (now wrapped as .msi files). Many more options exist for using the SoftGrid Offline client. For instance, you might also want to mass-upgrade and configure existing older SoftGrid clients that are currently in Online mode to SoftGrid 4.2.1 while converting them to Offline mode. You can do this by using Group Policy or your own scripting method.