New SoftGrid for Terminal Services Case Study
I generally try to avoid too much marketing stuff but this is a really neat case study that recently came out and I thought you might be interested in seeing it. The overview is below but if you want to jump right in you can access the site here.
Solution Overview
Partner Profile
Gen, a subsidiary of Q-Comm Corporation, delivers office productivity and line of business applications on a “Software as a Service” basis to small and midsize organizations around the world.
Business Situation
Gen wanted to grow its business and expand its capacity to meet customer needs, but its existing service delivery infrastructure would not scale efficiently.
Solution
Gen deployed Microsoft SoftGrid Application Virtualization for Terminal Services and augmented the service delivery environment of Gen with load balancing technologies.
Benefits
Eliminated the application conflicts that created service delivery inefficiencies
Enabled existing server infrastructure to support more users with greater performance
Effectively converted existing infrastructure into one capable of supporting a nationwide service rollout
Hardware
HP Reliant servers
Vertical Industries
Hosting and Application Service Providers
Country/Region
United States
Link
http://www.Microsoft.com/casuistries/Cassidy.asp...
Posted: Tuesday, August 14, 2007 1:38 PM by jchornbe | 2 Comments
Troubleshooting SoftGrid with Process Monitor
Microsoft’s SoftGrid product can do some amazing things to help application compatibility issues. That being said, while administering your SoftGrid environment, you will undoubtedly come across problems with specific applications. You may successfully stream your application on one PC and everything works fine. You may then stream your application to another PC and the same application bombs.
The Problem
This was the case when I recently tried to stream Java 1.5 to a client that had Java 1.6 installed locally. In previous versions of Java, there was a setting in the Java applet in Control Panel that allowed this type of configuration to work. The newer version of Java, however, does not react quite like its predecessors.
What I found was that you could stream Java 1.5 (within Internet Explorer of course) and it would work fine until the local version of Java 1.6 is launched. The only way I could get the Java 1.5 virtual app to work again was to uninstall the local Java 1.6.
I determined that when Java 1.6 was launched, it must be laying down registry entries or files that the Java 1.5 is reading thereby causing a conflict.
What do you do in situations like this?
One of the most common tools, that can be used to track down the culprit of such problems, is Sysinternal’s Process Monitor. If you’ve never heard of it, it’s a great (not to mention FREE!) tool created by Mark Russinovich that combines the functionality of RegMon and FileMon.
In order to use Process Monitor (ProcMon) in the virtual environment, one must first modify the .osd file for the virtual application. For detailed instructions, see KB 939896.
Once you’ve created your log file, you can now begin hunting down the source of the problem.
When ProcMon logs are created, hundreds of thousands of entries are written in a matter of seconds. I captured data for less than 30 seconds and had over 100,000 entries. Thankfully, ProcMon makes it easy to weed out irrelevant data.
Since I deduced that Java 1.6 was creating something that was causing a problem, I first started my search by filtering my log file. The idea that Java would lay down registry keys, which would cause problems, seemed to make the most sense, so I began narrowing my results to registry keys.
I only wanted to show a specific operation: RegCreateKey. You can do that by simply right-clicking on a line that contains the operation in question, click ‘include’, and then click ‘Operation’.
Next, I filtered my results so that only the ‘iexplore.exe’ process was shown (use the same process as before, but choose ‘Process Name’ instead of ‘Operation’.
I had successfully shrunk my results from over 100,000 entries to only 612. Looking over my results more closely, I could see that most (over 500 of the 612) of the keys created were within the path: HKCU\Software\Classes\CLSID, so I focused my search there.
Looking closely at the ClassID’s I could see that the second, third and fourth portions of the ID look very similar to Java versions (ex. 0015-0000-0028 = Java 1.5.0.28).
Logically, this seemed a reasonable source of my problem, and I decided to test it.
I went through the following steps:
1) Launch the local Java 1.6 (In my case I went to www.javatester.org/version.html from the local Internet Explorer.)
2) Delete the registry (first export the key, so that it can be put back in place, of course).
3) Launch the virtual Java 1.5 (In my case I again went to www.javatester.org/version.html ,but this time from the virtualized shortcut to IE).
This did indeed fix my problem. I now had Java 1.6 running locally and Java 1.5 running in the virtual environment.
The Final Solution
Now that I knew what registry keys were causing the problem, I needed to make sure those keys did not exist whenever the virtual application is launched.
Here’s what I did:
I created a reg file (let's call it CLSID.reg) with the following info:
Windows Registry Editor Version 5.00
[-HKEY_CURRENT_USER\Software\Classes\CLSID]
I created a batch file (let’s call it JavaFix.bat) with the following info:
xcopy z:\JavaFix\CLSID.reg c:\ /D
regedit -S c:\CLSID.reg
I then placed both of those files in a shared directory that my client computer had already mapped(the z: drive in this case). *Note – I also could have created a batch file to map the drive.
Now all I had to do was edit the DEPENDENCY section of the OSD file for Java 1.5 to look like this:
<DEPENDENCY>
<SCRIPT TIMING="PRE" EVENT="LAUNCH" PROTECT="FALSE" WAIT="TRUE">
<HREF>"Z:\JavaFix\JavaFix.bat"</HREF>
</SCRIPT>
<CLIENTVERSION VERSION="3.1.2.2"/>
</DEPENDENCY>
Another problem solved with the help of Process Monitor and some good old fashioned determination!
-Mike Ory
Posted: Monday, August 13, 2007 2:37 PM by jchornbe | 1 Comments
Inside the Grid: Part 3
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
Posted: Thursday, August 09, 2007 2:45 PM by jchornbe | 3 Comments
Inside the Grid: Part 2
The SoftGrid Client (SGC)
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.
Go Deep
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.
The SoftGrid Launch Process
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.
The user Sean starts his Windows Vista laptop while he is in his office in Boston. He is prompted for Windows Authentication and enters his alias and password.
Conceptually the SoftGrid Client Service starts and sends the user name to the preconfigured SoftGrid Server.
The SoftGrid Server turns around and uses a standard user account with Read Property Rights to the AD tree and reads the “Member Of” group information for Sean.
The SoftGrid Server takes those groups and parses the Data Store over an ODBC connection for all of the applications that Sean’s groups have permissions to.
The SoftGrid Server sends the location of the .ICO and .OSD files to the client so that it can retrieve them.
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.
Later that day Sean double clicks the .ICO which indirectly calls the .OSD which is read line item by line item. One of the lines identifies the necessary .SFT file to stream. The client sends to the server the identifier of the .SFT and the VAS mounts portions of the .SFT in RAM and streams it to the client.
The .SFT streams from the VAS into the client’s cache and when the minimal launch threshold is met (FB1) the package decodes to Q:\ and runs for the user.
When the user closes the application all blocks of data that had streamed remain in the local cache so that subsequent launches happen immediately.
Go Deep
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.
A Common Question:
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.
User Customized Configurations
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.
Exit Applications
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.
Schematic Diagram
The diagram below is a blue print of all of the SoftGrid system components, who each one communicates with and via what protocol / service.
Central Management and Control
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.
Going Deep:
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.
Scenario:
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.
The NON marketing benefit of Active Upgrade:
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
Posted: Wednesday, August 08, 2007 7:55 PM by jchornbe | 3 Comments
The SoftGrid TechCenter is Live
In case you haven't seen it, we recently launched the new SoftGrid TechCenter site on Microsoft TechNet. It's just getting started but so far we have links to all kinds of great information, from the system requirements to case studies to webcasts, plus much, much more. New content is being added all the time so you'll want to add this to your favorites, and as the site grows I'll do my best to blog on what's new. The SoftGrid TechCenter site is all about making you and your SoftGrid implementation a success so if there's some documentation you'd like to see or a feature you want added please leave us a comment below. I can't guarantee that we'll be able to respond to every comment or implement every suggestion but with your help we can make this the go-to site for everything SoftGrid.
J.C. Hornbeck
Posted: Tuesday, August 07, 2007 4:45 PM by jchornbe | 1 Comments
Exploring SoftGrid with NetMon Part 2: Application Launch
In part 1 we took a look at what happens when a SoftGrid client does a DC Refresh. During DC Refresh we identified the applications we were allowed to run, downloaded the OSD and ICO files, and placed the icons on the host OS. So now that we have our icons populated, let’s take a look at what happens when the user actually double-clicks one of these icons.
Disclaimer: Just as last time, my goal here is to explain a concept, specifically in the context of a default SoftGrid installation. Certain technical details will be skipped and some degree of SoftGrid and packet sniffer proficiency is assumed.
So with that said, let’s jump right in. When the user double-clicks on our icon, in this case the icon for Foxit Reader, the client (111.1.1.69) knows where to go to find the SFT for that application based on the OSD it previously downloaded. We’re going to be streaming the app so our first step is to sync over RTSP (port 554). We see this in frames 1-3 below:
Once we complete our three way handshake, we next request some information about our stream and get ready to play it. This happens in frames 4-9 below:
What’s important above is what’s in frame 7. This is the response to our DESCRIBE method where the server provides our client with some critical information about our stream, including the high port we need to connect to in order to play it. In my example, when I opened this packet it looked something like this:
We can see in the example above that our server is instructing us to make our secondary connection over port 49152. As a side note, if you launch multiple streamed apps, each will use its own unique high port. There’s also some other cool information in here such as package names, GUIDs, etc. Now I’m not going to go into all of the details about the RTSP conversation but the important thing is that you’ll next see the client sync over our high port beginning in frame 10:
Once this completes we tell the server to begin playing. This request to play happens over port 554 and in our example is in frames 13-16 below:
Then the stream begins to play over our high port (49152):
Now I know that there were a lot of packets that I skipped over for the sake of brevity but to summarize this is what we do:
1. The client connects to the server using RTSP (port 554).
2. The client and server negotiate a high port to use when actually streaming the app.
3. The client connects to the server using the high port and streams the app.
Here’s my highly modified trace of the process one more time:
Hopefully this will give you a better idea of what the SoftGrid client does when a virtual application is launched and will help you troubleshoot these kinds of problems should you encounter them. As always, if you have any requests for content please send them my way.
J.C. Hornbeck
Posted: Monday, August 06, 2007 2:37 PM by jchornbe | 3 Comments
With the release of Windows Vista just around the corner, many home computer users are probably wondering if now is the right time to make the jump to Microsoft's latest addition to the Windows family. Some are perhaps concerned about security and stability, while many are probably wondering why they should even switch to Windows Vista, because Microsoft Windows XP seems to be doing the job.
