Inside the Grid: Part 3

So I wanted to close of this series that Sean D has been progressing. I have been flat out in the UK and have not spent the time giving back to the community as normal! So this is part 3 or the 3 part series!! The first two series can be found below;

Inside the Grid: Part 1
Inside the Grid: Part 2

Enjoy and well done Sean!

Support

Besides the elimination of application conflicts, Microsoft SoftGrid Application Virtualization can solve many other support related issues. By running each application inside of its own protected SystemGuard environment, SoftGrid enabled applications remain immune to users inadvertently or intentionally deleting critical files needed by that application to run. Because the SoftGrid enabled applications are running inside of their own SystemGuard environment, a user or a local system administrator will never see any of the application’s files or registry entries if they look at the local resources. This can effectively reduce the number of Help Desk calls an organization requires.  And because the application never actually install itself, you don’t have to worry about the user who has tainted their system with who knows what software that will impede the installation of business applications.

License Control

Another issue facing the support personnel inside an enterprise is the concern surrounding licensing. SoftGrid enables organizations to control the number of users who can gain access to SoftGrid enabled applications concurrently. This licensing feature is administered centrally from the sole administrative utility for SoftGrid, the SoftGrid Management Console (SGMC).

The SGMC has several reports available by default that query against the Data Store. One such report is the Licensing report that, if configured properly, can display a graph of the number of licenses consumed on average, total and daily for any given SoftGrid enabled application.

Go Deep

Every time a user launches an application that has had the licensing feature enabled through the SGMC, that launch will create a record in the SQL Data Store indicating that the license is in use. On shutdown of the application, that record will be removed from the SQL Data Store allowing a different user access to the application in question.

Retiring an Application

At the end of an application’s lifecycle it becomes time to retire or terminate that application. In a traditional method this would require someone to visit every client PC or Terminal Server machine and physically uninstall that application. This leaves the potential for some of the files and registry settings to be left orphaned and create conflicts later on.

With SoftGrid enabled applications, the organization simply needs to deactivate or remove that retired application centrally from the SoftGrid Management Console. By doing so, the user population will subsequently have the application removed from their desktop and all previously cached data blocks of the application will be removed as needed.

Because applications are no longer truly installed when SoftGrid is utilized there is never a need to physically remove the application from the client’s computer.

Mobility

Let’s say that I am a mobile user who only comes into the office on occasion to “sync up”, either with people or the network. When I am logged into the Windows domain in the office, I go through the typical authentication process described earlier and receive all of my shortcuts, File Type Associations (FTA's) and OSD files. If I go one step further and invoke a preload of all of my applications then I can successfully leave the comfort of the office, go on an airplane and at 35,000 feet launch any of my SoftGrid enabled applications. This is accomplished through Disconnected Operation Mode.

What happens is that when I launch my application from the shortcut, it attempts to contact the SoftGrid server for its typical authentication and licensing check. At failing to contact the VAS, the client assumes that the user still has permissions to use the application and that a license exists in the Data Store. The application will launch for a configurable period of time (90 days by default). If at the end of that time period the user has not reconnected to the VAS then the application will stop launching. This time stamp is unique for each application. So if a user launches Word today and Adobe next week, it is 90 days from the date of first launch of that application.

Subsequently, the user could change their client to “Work Off Line” which will cause the client to assume that the VAS is not able to be contacted and will launch the applications, bypassing the time-out.

Regression testing

Regression testing has always been a top priority inside enterprises when deploying any new or updated application. In enterprises with formalized processes for doing this, every application is tested against every known configuration that could exist within that organization. In one major financial services organization this often exceeded 40 hours for a single application. However with a SoftGrid enabled application, this is reduced down to only the time required to Sequence that application. When it is deployed it will be isolated from any other applications that were Sequenced themselves or are still locally installed on the client guaranteeing a conflict free environment.

Pre-Configured Applications

During the Sequencer’s second Phase (The Installation Phase) it is the responsibility of the Sequencing Engineer to know the application thoroughly. The Sequencer Engineer uses this opportunity to configure the application exactly as the user should see it and use it. This could mean something as simple as configuring tool bar buttons, default fonts, grid lines or something more complex like a backend database connection. All of these configuration options will be stored in the SoftGrid enabled application's package and delivered to the client.

As the user uses the SoftGrid enabled application on the SoftGrid client, they may make user configuration changes to the package that they would normally be expected to do on a traditionally installed version of that application. When the user exits the application those user configured changes will be stored permanently into a file called “UsrVol_sftfs_v1.pkg” which is specific to that user. This file is stored in the User's Application Data directory, which by default is in the User’s Profile Directory (%APPDATA%).

Non Multi User Mode Applications

Another advantage leveraged by the use of a “UsrVol_sftfs_v1.pkg” file for each SoftGrid enabled application or suite of applications is that applications that previously would not run in a Terminal Server’s Multi-User Mode environment may now be able to do so. These applications require a User Identifier in the HKLM registry hive and were not designed to be run by different users simultaneously on the same device. This could also be true for applications that use certain files such as config or .ini files or even mailslots that the application does not expect to be accessed by more than one user per system. Because SoftGrid uses a configurable version of the HKLM settings for each user and stores them, as well as files that were modified by the user such as the .ini file, in the “UsrVol_sftfs_v1.pkg” specific to each user, those applications may now run successfully on a Terminal Server in Multi User Mode.

Multiple Versions

It is common for an organization to need to run different versions of the same application side by side on the same physical device. In a traditional setting this was accomplished by installing that application on separate Terminal Server computers to support each version and required that the user make separate RDP or ICA sessions to these Terminal Servers for each version they required.

When the Sequencer is used to make an application SoftGrid enabled, it allows different versions of the same applications to run their own protected SystemGuard 'bubble'. Because of this, each version of Microsoft Access will be unaware that any other version of Access is currently running on the same client machine.

Considerations

Although Microsoft SoftGrid Application Virtualization is capable of solving countless issues an enterprise could encounter, the fact remains that as a SoftGrid Administrator there are certain considerations that need to be addressed for a full appreciation of the SoftGrid environment.

Sequencing applications into SoftGrid enabled applications requires extensive knowledge of the application. During the Sequencer’s wizards, the Sequence Engineer must know not only how the application will behave during the installation but they must also know if there are any supported applications that need to exist or any network drives that need to have been configured. Also, part of this process is testing and configuring the application which requires even more extensive knowledge of the applications.

There are some limitations as to what can and cannot be SoftGrid enabled with the Sequencer. For example, boot time applications cannot be Sequenced because they would be expected to fire off before the SoftGrid Client executables have been loaded on the SoftGrid client. Background services that run in the background for an entire machine and not just one application cannot be Sequenced. Services that use system resources not virtualized by SoftGrid, such as RPC or device drivers, will likely conflict with other running instances.

If an enterprise consists of clients that are older than Windows 2000, such as Windows 9X, Windows NT, Linux, Macintosh, or Windows ME, a solution such as Terminal Server or Citrix MetaFrame must be used as the SoftGrid client.

SoftGrid Platform Review

In review, SoftGrid has three main parts: The first is the creation of the SoftGrid-enabled applications using the SoftGrid Sequencer. The second is the backend SoftGrid Virtual Application Server fulfilling requests from SoftGrid clients for applications. The last is launching the applications at the SoftGrid client, which happens in a protected environment (SystemGuard) without leaving any client footprint. At its core, the SoftGrid Platform consists of a SoftGrid Server and SoftGrid Client. The Server serves the applications, which run on the Client.

Pre-Launch Deployment

Application installations are packaged on the SoftGrid Sequencer, resulting in four files: An OSD file, an ICO (Icon) file, an SPRJ and an SFT File.  These files are then placed in the specified content directory configured for all SoftGrid Servers in the server farm.

Using the SoftGrid Management Console, application records are created by importing the configured OSD or SPRJ file. These applications are also assigned to a server group, assigned a license pool and assigned to groups of users.

The client is deployed through normal deployment best practices (ESD, unattended setups, manually, etc.).

SoftGrid clients communicate at login with the SoftGrid Server to receive shortcuts to applications that users have been granted access.

The Launch Process:

1. The target SoftGrid Client will request the application from the SoftGrid Server when the desktop icon is clicked. This icon actually points to a cached OSD file, which was sent to the client during the discovery of applications. This XML-based OSD file specifies the SoftGrid Server to connect to, and the settings for presenting the application to the user.

2. When an end user launches the SoftGrid enabled application, the SoftGrid Server and client negotiate the provider policies that are in place that will authenticate the user, check authorization and determine license compliance. The streaming process will then begin by sending pre-configured blocks of data from the application package’s SFT file.

3. Once a minimal launch threshold is achieved (approximately 20%-40% of the application), the application interface will appear and be ready for user interaction.

4. As the user continues using the application, additional code is delivered to the client as necessary.  For example, if the user decides to use the Mail Merge feature of Word, which was not used during sequencing, then the server will send it to the client.

5. Any custom changes the user makes are stored in the user’s data directory.  This is the user’s profile by default, but can be changed.

6. Since the application executes on the SoftGrid client, it performs as if installed locally. However, the application is never actually installed on the client. Instead, it executes within a protected virtual environment (SystemGuard), and has a Virtual File System, Virtual Registry and Virtual Service Control Manager to ensure that the application will not have conflicts with other applications either running locally or streamed through SoftGrid.

7. When the application is closed, all blocks of data that were streamed to the client are stored in the client’s local file system cache (SFTFS.FSD), so all subsequent application launches happen locally.

That concludes Inside The Grid.  I hope you found the information here informative and helpful, and as always, if you have any comments please be sure to leave them below.

- Sean Donahue