A tongue in cheek saying we used to use at Softricity went something like this; “With SoftGrid you NEVER have to install an application again, (cough), except our client”. While this may be true, the SoftGrid client does in fact need to be installed on any Windows 2000 professional or greater system that is going to stream and run SoftGrid enabled applications.
At present there are two clients, Windows Desktop (Windows 2000 Pro, Windows XP, Windows Server 2003, Windows Vista) and the Terminal Services client (Windows 2000 or greater with T/S installed). Each has their own separate installer executable which is also available in .MSI format to make distributing the client with an ESD easier.
Just like we said before regarding the VAS minimum requirements, the overhead of the SoftGrid client is very small. As such, I will not insult you by listing the minimum hardware requirements here since they do not differ from the specs of the Operating System.
Once the client is installed, it lays down the SoftGrid client service and several executables that allow the client to stream SoftGrid enabled applications and run them inside their isolated virtual environment (SystemGuard). In addition to this, the client will also now have a virtual drive that takes the letter Q:\ by default. It also creates a single system wide cache file that will be used to store the package’s .SFT files that users stream and launch their applications from.
Note that the Q:\ drive is not a real drive, it has no space and is not accessible from Windows Explorer or “My Computer”. It is in fact a mount point and the SoftGrid enabled applications “run” from this Q:\ drive. If Q:\ is already assigned at the time the client is installed, it will select the next available drive letter by default. This drive letter can be selected during or after the client’s installation as well.
The name of the Softricity File System Cache is SFTFS.FSD and can be found in the C:\Documents and Settings\All Users by default. It is where all of the .SFT files stream to and get cached by every user of the client. It has a maximum size of 64 GB which can be set at anytime during or after the install.
Now that we have the concepts and a grasp of all of the necessary components that make up the SoftGrid System, let’s explore what happens when the user logs in. The following is a conceptual explanation of the SoftGrid Launch Process.
Sean sees Microsoft Word appear as an icon on his desktop and is elated to see that Word was “installed” on his laptop. He gets up and goes to get a cup of coffee.
In reality, the SoftGrid client service starts and captures the token and passes it to the clients preconfigured SoftGrid server. The SoftGrid Server gets the group information from the application records in the Data Store for each application. The SoftGrid Server uses the standard Windows Security API to determine if the user belongs to any of the groups for each application
When a user Logs into a workstation using the standard Windows Authentication (based on Kerberos v5) the SoftGrid Client captures the token constructed by the Local Security subsystem for that user. This token consists of the user SID and any SIDs of groups that the user is a member of.
The SoftGrid VAS uses an ODBC connection back to the Data Store and retrieves the permission information for the published application records. The VAS compares the information in the user’s access token to the groups that have been assigned permissions to the application records. For any applications that are determined to have been provisioned to the user, the VAS will send the location of the .ICO and .OSD files. The user will then go to those locations and retrieve the designated .ICO and .OSD files and copy them to their local system.
When a user launches an application, the VAS uses an ODBC connection back to the Data Store to see if that user still has permissions to the application record. If licensing is implemented on that application the VAS will also query the Data Store to see if there is an available license for that user.
Given that the user is allowed to launch the application, the VAS will stream the required blocks of data to the SoftGrid Client. After the data blocks necessary to launch the application have been streamed to the client, the VAS will sit idle waiting for additional application requests.
Note: Alternately the .ICO and .OSD files could be placed onto a Web Server’s directory and delivered to the SoftGrid client via HTTP.
Note: If configured properly File Type Associations and DDE information can be delivered at this time as well.
One of the first concerns I hear from people when describing this launch process is “How long is it going to take to stream the .SFT file? I mean, for Office 2003 the .SFT file could likely be 850 MB or larger. It sounds like you are doing a straight file copy over the LAN of that file to every user.”
Not exactly. If you peel back the layers even further, what really happens is an example of the on demand delivery feature of SoftGrid.
On Demand Delivery is a feature of the SoftGrid platform that will only stream the blocks of data that make up the SoftGrid Enabled Application’s Packages when the user requests the application. Until such time, no application code is delivered to the client by default.
When a user requests an application by selecting the shortcut, it invokes a launch of the .OSD file associated with that shortcut. The .OSD file is then read by the SoftGrid client, specifically one of the lines that tell the client the name of the SoftGrid Server that hosts that application’s associated .SFT file.
The SoftGrid server receiving the request from the client goes to the Data Store to ensure that the user still has permissions to that application and that there is an available application license. At this time the SoftGrid Server will use the RTSP protocol to stream the .SFT file in preconfigured blocks of data. These blocks are 32 Kb by default.
As part of the On Demand Delivery feature, the entire contents of the .SFT file are not delivered at this initial launch. The SoftGrid Server will stream these highly compressed blocks of data until the “Minimal Launch Threshold” is achieved. This is known as Feature Block 1 (FB1) and is often referred to as being 20 – 40% of the entire Package. Once the Minimal Launch is met on the client, the interface of the application will appear and the user will be able to use the application.
It is the responsibility of the Sequence Engineer to ensure that the proper components of an application are contained within FB1. This is performed during the third and final phase of the Sequencer known as the “Launch Shortcut Phase”.
Any component that is not contained inside of FB1 will remain on the SoftGrid server by default. As the user requests these additional features that are stored in Feature Block 2 (FB2) the client will retrieve only those blocks necessary to use this feature. This process is known as an Out Of Sequence Operation.
All blocks of data that make up the .SFT file in FB1 and FB2 are streamed to the client machine and cached into the local File System Cache called SFTFS.FSD by default. All blocks of data for the .SFT files of all applications delivered to the client are stored centrally in this local cache file.
If the user makes changes within the SoftGrid Enabled application that would have been written to the registry or an .INI file in a traditional installed version of the application then these changes are written to a User settings file. This file is stored in the User’s profile directory of C:\Documents and Settings\username\Application Data\SoftGrid Client\PackRoot+GUID\UsrVol_sftfs_v1.pkg by default.
When the user exits the SoftGrid enabled application, all of the blocks of data that had been streamed to the client will be saved into the file system cache, SFTFS.FSD. All subsequent launches of this application will happen instantly from this local cache file without any additional streaming of data from the SoftGrid Server.
The diagram below is a blue print of all of the SoftGrid system components, who each one communicates with and via what protocol / service.
As stated before, the SoftGrid Management Console (SGMC) is the only point of management for a SoftGrid admin. What we didn’t discuss in detail yet is that all updates to applications can also happen and be controlled centrally.
It is a natural part of an application’s lifecycle to have updates in the form of service packs or hot fixes become available. These updates need to be applied to the application and is often done by the support engineer visiting every client PC or Terminal Server machine and manually applying the update in question. This can be very time consuming and can also increase the likelihood of causing an application conflict as the update modifies files and registry settings on the client.
With a SoftGrid Enabled application, updates happen centrally and occur at only one time. The Sequence Engineer would take the original SoftGrid Enabled application’s package back to a clean Sequencer Workstation and perform a Package Upgrade, appending the original package with the updates. This updated package will then be used to replace the original package on the SoftGrid Server and the SoftGrid Client will receive only the updated files at the next launch of the application.
When the Sequence Engineer brings the original package back to a clean Sequencer and performs an Open for Package Upgrade, the .SFT file is decoded to the real Q:\ of the Sequencing workstation. This, in essence, puts the package back to the state it was in at the time of the previous Sequence.
The Sequence Engineer will then start the Installation Phase which will place the Sequencer into a monitoring state. At this time they can install the service pack, install the hotfix, or manually modify the files and registry settings in the package. Once done they would stop the monitoring, perform the Launch Application Phase to recompile FB1 with the updated information and then save the package again.
During the save, the name of the .SFT now gets modified with a version identifier in the form of original_package_name_2.sft. They copy this file to the \Content share and enter it into the SGMC as a new version of the package. When the user closes the original application and later launches it again they will be connected to the new version of the package but only receive the files that were changed in the upgrade.
The user, Patrick, launches Adobe Reader 6.0 for the first time. The SoftGrid client sends the Package GUID from the OSD file to the SoftGrid server. Since the client had not previously sent a version number, the SoftGrid server will stream the SFT file associated with the latest version of the package to the client (e.g. Adobe_Reader_60_MNT.sft). Since this is a new package, the client will note the version number. While Patrick is connected and actively using this package all of his requests will be sent to the server in the form of the Package’s GUID and the version number that he is currently using. Even if the Administrator upgrades the Adobe 6.0 to package version 2 (e.g. Adobe_Reader_60_MNT_2.sft) Patrick will continue to use his existing version during his session.
When Patrick leaves for the night he shuts down Adobe Reader and this will end his connection to the SoftGrid Server. The next morning when Patrick returns to work he launches Adobe Reader again, but because this is a new connection his client will not send a version number with the package GUID. The SoftGrid Server will determine, when no version number was specified, the latest version of the package file to send to the client (e.g. Adobe_Reader_60_MNT_2.sft). The client processes the Package as a normal Package Upgrade, noting the newer version number.
If Patrick loses the connection to the SoftGrid server and the client reconnects while Adobe Reader is active, the SoftGrid client will send the version number to the server along with the Package GUID. The server will use the Package GUID to determine the Package, and the version number to determine the correct Package version (Adobe_Reader_60_MNT_2.sft) that Patrick had been accessing before the connection loss and continue to stream it to his client.
On a Terminal Services client the same scenario would also be true. The only exception is that a “connection” to a package is not considered to have been ended or closed until all users on that physical device have closed all applications in the specific package.
You will hear and read literature from product marketing professing the advantages of Active Upgrade with SoftGrid for those 24/7 shops that never have true “down time”. However, I like to look at it from the perspective that even those shops do have a certain type of “down time”. This time usually occurs on a Saturday night or early Sunday morning when network activity is low. Typically the Net Admin would have to come in on a Sunday morning and perform the upgrade. Now this Admin can upgrade the package on a Tuesday afternoon, copy the _2 file to the \Content share, add the version in the SGMC and leave knowing that the next time users disconnect and reconnect to the VAS they will seamlessly get the updates in the package.
No more off hour upgrades!!!
Coming up next will be Part 3: Support.
- Sean Donahue
<p>Sean kept his promise and posted part 2 and 3 of his &#39;Inside the SoftGrid &#39; series. Part 2 covers</p>
<p>Inside the Grid: Part 1 Inside the Grid: Part 2 Inside the Grid: Part 3</p>
<p>So Sean D this time has updated his series on inside the grid ! Part Two has kicked off and it has some</p>
<p>Just a small comment on...</p>
<p>"...If Q:\ is already assigned at the time the client is installed, it will select the next available drive letter by default. ...."</p>
<p>Well the next available drive starting from the c: drive and normally the C: & D: is usally used for the system and the cd-rom so if the Q:, C: & D: is already in use when you are installing the SoftGrid client by default your drive letter will be E:.</p>