Inside the Grid

8/8/2019 Inside the Grid

1/39

INSIDE THE GRID


2/39

CREDITS

Courseware Layout: Sean M. Donahue, John Flanagan, Brian Kelly, Anthony M. Kinney

Courseware Content: Sean M. Donahue, Brian Kelly, Anthony M. Kinney

Courseware Labs: Sean M. Donahue, John Flanagan, Brian Kelly

Courseware Editing: Sean M. Donahue,John Flanagan, Brian Kelly

Courseware Experts: Sean M. Donahue, John Flanagan, Brian Kelly, Anthony M. Kinney, Edwin

Yuen, Andrew Lanoix

Courseware Graphics: John Flanagan, Eric Kim, Victoria Richardson

REFERENCES

Schulzrinne, H., Rao, A., Lanphier, R., Real Time Streaming Protocol (RTSP), RFC 2326, Columbia

University, Real Networks, Netscape, April 1998. Handley, M., SDP: Session Description Protocol,

RFC 2327, ISI/LBNL, April 1998. Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., RTP: A

Transport Protocol for Real-Time Applications, RFC 1889 GMD Fokus, Precept Software, Xerox

Palo Alto Research, Lawrence Berkeley National Laboratory, January 1996.

Using RTSP with Firewalls, Proxies, and Other Intermediary Network Devices White paper.

http://docs.real.com/docs/proxykit/rtspd.pdf

http://www.microsoft.com

http://www.F5.com

http://msdn.microsoft.com

COPYRIGHT NOTICE

This material is protected by the copyright laws of the United States and other countries, and is the

property of Softricity, Inc. (a wholly-owned subsidiary of Microsoft Corporation). It may not be

reproduced, distributed, or altered in any fashion by any entity (either internal or external toSoftricity), except in accordance with applicable agreements, contracts or licensing, without the

express written consent Softricity. Softricity shall have no liability for errors, omissions or

inadequacies in the information contained herein or for interpretations thereof.

Trademarks


3/39

Softricity, SoftGrid, Softricity ZeroTouch, SystemGuard, Virtually Anything is Possible, and Virtual

Application Computing for the Always-On Enterprise are trademarks or registered trademarks of

Softricity, Inc. Microsoft, Windows, Windows 2000, Windows XP, and Terminal Services are

trademarks or registered trademarks of Microsoft Corporation. Other names appearing in this

white paper are trademarks of their respective owners.

Notice

The information in this publication is subject to change without notice.

THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR

PURPOSE OR NON-INFRINGEMENT. SOFTRICITY, INC SHALL NOT BE LIABLE FOR TECHNICAL OR

EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL,

CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE,

OR USE OF THIS PUBLICATION, EVEN IF SOFTRICITY HAS BEEN ADVISED OF THE POSSIBILITY OF

SUCH DAMAGES IN ADVANCE.

Rev. 022207


4/39

TARGET AUDIENCEThis document is intended as a supplement to the formal training program offered by Softricity.

It is intended to be read in place of attending the lecture on the Technical Details of the SoftGrid

Technology or as a Instructor led presentation. As such, it has been written in the voice of the

lecture.

This document focuses on the benefits of and the technical description of exactly how those

benefits are realized. The sections entitled Go Deep are intended to take the reader under the

covers of SoftGrid and explore the deepest level of the technology without revealing the

intellectual property.

We will focus on senior architects and Subject Matter Experts (SMEs) within the core group of

MCS/PSS, CSS and SI partners that have proven deployment expertise and leadership. From

these organizations, we will invite a minimum of 15 primary and secondary select deployment

specialists who will have the most impact on carrying the training content into the rest of their

organizations, influencing the future of the partners flagship offerings and delivering internaltraining to others.


5/39

PREREQUISITESThis courseware covers the SoftGrid Platform. Knowledge in the following areas will assist in the

SoftGrid Systems planning, installation, and administration:

Knowledge of Windows XP including installation options and configuration Knowledge of Office 2003 including installation options and configuration Some programming/scripting experience Knowledge of deployment tools and technologies including User State Migration Tool

(USMT), Remote Installation Service (RIS)

Knowledge of Active Directory Basic Knowledge of Windows Pre-installation Environment (PE) Basic Knowledge of SMS2003 Basic Knowledge of SQL2000 Basic Knowledge of PC hardware Basic Knowledge of Microsoft Virtual PC 2004


6/39

INTRODUCTIONThis section will give the participant a thorough understanding of the SoftGrid platform and all of

its components. This Training Guide will detail what problems enterprises encounter in the

standard application management lifecycle and how SoftGrid addresses those issues.

At the end of this section you will be able to:

Understand Microsofts Software as Service. Describe the benefits of SoftGrid computing in a technical nature. Define SoftGrid computing. List and explain all the SoftGrid System Components. Understand the SoftGrid environment. Understand new features and benefits of SoftGrid 4.0.

SOFTWARE AS SERVICEIn the Fall of 2005 Ray Ozzie, Chief Software Architect for Microsoft, released an internal memo to

all Executives and their direct reports in which he outlined the next great change in the softwareindustry. This change, as he described it, is a dramatic move to treating computing technologies as a

service based model.

The ubiquity of broadband and wireless networking has changed the nature ofhow people

interact, and theyre increasingly drawn toward the simplicity of services and service-enabled

software that just works. Ray Ozzie

In fact, at a Microsoft company meeting in 1998 a vision was outlined in which software would

become more of a service over time. With the addition of SoftGrid in the tool belt of Microsoft this

vision is rapidly becoming more and more a reality.

By treating software as something that follows a user around from any PC they log into and running

on that system without the need to install itself or modify the host OS in any way, software can beas easily and readily available as the electricity that powers the computer. As you will see in the

upcoming pages, a user simply logs into a Windows based PC with their existing Active Directory

credentials and based on their group memberships all of the applications that are appropriate to

them will appear on their desktop, as if they were installed. In reality portions of these applications

will stream to their PC from a SoftGrid server with all of their necessary assets in tow, including

registry entries, system files, COM, embedded services and run them in an isolated environment.

All the while these service-enhanced software are centrally controlled by the SoftGrid

Administrator .

In the following pages we will explore more of the benefits of the SoftGrid computing model.


7/39

MAJOR BENEFITS OF SOFTGRIDThe following are some of the major benefits of SoftGrid that we will explore:

Simplify Operating System Migrations Central Management and Control Eliminate Application Conflicts Simplify Updates to Applications Multi Tenancy Reduce Server Silos Run Multiple Versions of the same application on one system Terminate or Retire Applications Easily Configuration Control

EASIER DEPLOYMENTSThe thought of migrating an Enterprise Organizations base operating system can make even the

most veteran IT professional spend many sleepless nights. In the near future organizations will befaced with the perceived burden that they will have to upgrade their systems to Vista which will in

turn start a flurry of concern around application compatibility and manageability. A common

thread of this concern is maintaining user up time, reducing time spent on regression testing and

even uninstalling existing software.

Many organizations will attempt to ease this burden by employing an ESD solution to automatically

deploy their applications once the new OS has been installed. However, even with an automatic

installation of an application a vast array of Windows based applications conflict with each other.

When an application is allowed to install onto a host or client computer its programmed behavior is

to add or modify files and registry settings on that clients Operating System. If that application didnot add or modify settings in the registry and was contained exclusively in its own directory on the

file system then conflicts would never occur. However, with the advent of thousands of applications

after 1995 the application will almost always place its own files (.DLL, .VXD, .SYS, etc.) in numerous

directories all throughout the file system. It will also populate the Registry of that client with its

own values or modify existing values.


8/39

Back in My Day

Back in Windows 3.1 applications would install all of their assets into their own exclusive

directory. This also included their settings files in the form of an .INI file, the registry was largely

unused. Conflicts did not occur since the applications were isolated into their own directory

structure such as C:\Winword\.

This problem would not be so abundant if Enterprises ran only one or a very select group of

applications. Since most Enterprises will need to run countless applications the chances of these

applications causing a conflict with one another is almost a guarantee. Until SoftGrid, the solution

for many organizations was to separate these applications on different computers. In essence a

User would have two or more computers on their desk, one to run Application A and another

separate computer to run Application B. Although this is a solution, it is very impractical from an

expense and support perspective.

Regardless of the ESD solution, if one is used, to roll out an application set over time settings and

configurations will build up on the operating system making it polluted like the water the HudsonRiver. Even if an organization were to deploy Windows Vista the day it becomes available it is only

a matter of time before this occurs. The only way to truly purge a system of this clutter is to

perform a radical system rebuild or restore it to a clean state.

These major pain points of deployments are eliminated when SoftGrid is used in conjunction with

Microsofts SMS for new Operating System Migrations. Because SoftGrid enabled applications are

never installed or allowed to modify the client operating system and are made to run inside of their

own virtual environments complete with all of the necessary assets (system files, registry, COM,

embedded services, etc.) . The end result is the isolationistmentality of yesteryear with todays

complex and sophisticated applications.

To explore this further we will dig deeper into what makes an application SoftGrid enabled.


9/39

When an application is SoftGrid Enabled it is made to run inside of its own virtual environment.

Applications that are SoftGrid Enabled are never allowed to install or modify the local file system or

local registry; instead they are made to run inside of their own Virtual Environment. Contained

inside of this virtual environment are all of the files, registry information, fonts, COM, embedded

services and environment variables that the application would have normally installed and be

expected to use on the client PC. Instead, with all of these assets residing inside the virtual

environment (SystemGuard) the application will leverage them from this virtual environment and

remain isolated from other applications that are also running inside of their own separate Virtual

Environment (SystemGuard).

The process of creating the Virtual Environment (SystemGuard) is known as Sequencing.

Microsofts SoftGrid Sequencer is the component in the SoftGrid system that is vital in creating the

SystemGuard for an application or suite of applications. The Sequencer will be covered in detail

throughout the entire SoftGrid curriculum.

SoftGrid Enabled applications will be able to use local and network drives, CPU, RAM, the local

Windows Installer Service, printers, USB devices and other local resources on the SoftGrid client to

which they are streamed into cache and run.


10/39

SystemGuard virtualizes many different operating system components,

including:

Virtual COM: SystemGuard virtualizes COM communication, protecting one program

from another.

Virtual Registry: SystemGuard creates a Virtual Registry for each application. Registry

settings created are not seen by other applicationsincluding the Windows Regedit

program. Rather than copying the entire Registry, the Virtual Registry of SystemGuard

utilizes an overlay" (or copy-on-write) methoditems in the real Registry may be read

by the application as long as a virtual copy of the item is not available. All application

writes to the Registry are contained within the Virtual Registry.

Virtual File System: SystemGuard also handles requests made by applications to files in

specific directories by redirecting the requests. For example, if an application looks for a

file located in a specific directory on the local C: drive, SystemGuard redirects any

requests to the Virtual File System. Dynamic Link Libraries (DLLs) specifically needed by

the application are made available within SystemGuard, avoiding conflicts with different

versions of the same DLL that may be installed locally or running in another SystemGuard

on the machine. These components are shared and tracked inside the Virtual File System.

Virtual Services: New in 4.0 is the ability of SystemGuard to virtualize embedded

services and the locally installed Windows Installer Service (MSI). For embedded services

the service itself and its definition will only be visible within the environment it is created.

Any program external to the environment which queries the Windows Service Control

Manager will not see this service. Any number of services or versions of services will be

able to be run, only constrained by how they are defined with the SystemGuard

configuration. The locally installed Windows Installer Service will be virtualized at run-

time, using its configuration from the SCM as a template for execution.

Virtual .INI: SystemGuard allows each application or instance to have private settings

within virtual copies of standard Windows .INI files.

Virtual Process Environment: SystemGuard stores environment variables including the

path environment variable.

Virtual Fonts: SystemGuard makes each font added during sequencing available to only

the specific application during runtime on the SoftGrid Client. This prevents these fonts

installation on the local machine, which would consume valuable system resources.

Go Deep


11/39

ADEEPER LOOK AT SEQUENCINGIn order to understand this new concept of application virtualization, let us first take a closer look

at where it all begins. The first major component in creating a SoftGrid enabled application that can

run in its own virtual environment is the Sequencer. After we dig deeper into the SoftGrid System

Components and see how they all work we will revisit the benefits of SoftGrid in a technical

description.

Sequencing is a wizard based process that consists of the following 3 phases.

1. Package Configuration2. Installation Phase3. Launch Application

Each phase of the Sequencing process has distinct objectives that are performed and are critical in

the overall success of a SoftGrid enabled application. Before someone Sequences an application it isrecommended that they complete the necessary training on this utility.

Package Configuration

During the Package Configuration Phase the Sequencer Utility prompts for information necessary to

complete the OSD file which is a critical file in the launch of a SoftGrid enabled application.

Installation

During the Installation Phase the Sequencer component monitors an applications installation in

order to pack all of the assets of that application into the SystemGuard virtual environment. In

order to get the most complete and unadulterated installation of an application it is vital that the

workstation on which the Sequencer component runs be as clean as possible and reflects the client

that will run the SoftGrid enabled application.

Launch Application

During the Launch Application Phase the Sequencer component is responsible for compiling and

ordering the blocks of code necessary to launch the application on the client initially. This is

referred to as Feature Block 1 (FB1). In order to optimize performance the default behavior of

SoftGrid is to deliver the contents of FB1 to the client initially, allowing the user to use the

application but not requiring them to stream the entire package. This will be described in more

detail later in this document.


12/39

SOFTGRID PACKAGESBecause each application, or suite of applications, runs inside their own isolated SystemGuard

virtual environment they are allowed to remain conflict free. At the end of the 3 phases of

Sequencing the person performing the Sequence completes the File Save feature which results in

the following four types of files. These files comprise a SoftGrid package.

File (Approximate Size) Definition

ICO (~24 Kb)

*One per Published Application

The icon file is a shortcut that when properly

published through the SoftGrid Management Console

will appear on the SoftGrid clients desktop. When

clicked by a user this Icon file will point to the next

file in the package which is the .OSD file.

*Technically a user does not need a .ICO file to launch

a SoftGrid enabled application. They could instead

launch it directly from the .OSD file.

.OSD (~2Kb)

*One per Published Application

The .OSD (Open Software Descriptor) is an XML

based file that instructs the client on the necessary

details to retrieve the SoftGrid Enabled Application

from the SoftGrid server and run in its SystemGuard.

.SFT (up to 4 GB)

*One per Suite of Applications

The .SFT (Softricity) file is the largest and most

critical file in a SoftGrid Enabled Applications

package. It is inside of this file that all of the

applications assets, including files, registry, fonts,

COM, virtual services and the SystemGuard itself

reside.

.SPRJ (~13 Kb)

*One per Suite of Applications

The .SPRJ (Softricity Project File) is the newest file in

the SoftGrid Enabled Applications package. The

Sequencer stores its Exclusion Items and Parse Items

information in this XML based file. This file is used

heavily in the creation of application records as well

as during an upgrade to a package.

Because each Sequenced Application or Suite of applications is composed of these files they are

allowed to remain separate from all other applications thus eliminating application conflicts.

SoftGrid Enabled Applications are delivered to the SoftGrid Clients using these files, eliminating the

need to install the applications onto the clients computer.


13/39

More detailed information about these files can be found in the official Softricity SoftGrid

curriculum.

Analogy:

When I (application A) travel on the road for business I Sequence myself by packing my suitcase

(SystemGuard). Anything that I normally have installed at home and use during my normal

routine is virtualized into my suitcase. I pack my socks (system files), my shirts (registry keys), my

shoes (embedded services). I save my suitcase (my SFT file) and I stream over the network by

traveling on the air plane. When I get to the client (hotel room) I do NOT unpack the suitcase,

instead I open the virtual environment and live out of it. If I unpack my suitcase this would be the

equivalent of installing myself into my client (hotel room).

When it comes time for me to perform my programmed behavior of getting dressed in the morning

I may make a call to my socks in the dresser, as if I had been installed. Instead, SystemGuard stops

that call and tells me to use the socks that are in my suitcase. It is only when I can not find

something in my suitcase (e.g. Shampoo) that SystemGuard allows me to fall through to the localhost and use the resource, but with read only rights. It is essential to understand that the

Sequencer component made an intelligent assumption that the resource in question (shampoo)

would always be on every client this package streamed to. It did this because that same resource

was in fact available on the machine that was used to perform the Sequence operation. This adds

credence to the earlier statement that the Sequencing Workstation needs to be clean and reflect the

clients that will run the SoftGrid enabled application.

At the end of my stay when I leave with my suitcase there is no evidence that I was ever in that

hotel room. I have left no visible foot print.

If my wife (application B) travels to the same hotel room (client) as I do, she will remain isolatedand conflict free from me because she has packed herself (Sequenced) into her own separate suite

case (SystemGuard). In this example there is no way that I can accidently go into my wifes suitcase.

Yet, if we know that my wife and I are compatible and we are meant to be integrated with each

other, we could be sequenced into the same suitcase.

THE PROCESS CONTINUEDSince we have started the process of making an application SoftGrid enabled we will continue to

build on that momentum instead of ending it prematurely leaving you feeling incomplete. I assure

you that we will revisit all of the benefits of SoftGrid later in this document.

Now that the Sequencer Engineer has saved their package, and has the four golden files as a result,

it is time to move those package files to the SoftGrid Server. This needs to be done in order to make

the SoftGrid enabled application available to the user population.


14/39

THE SOFTGRID VIRTUAL APPLICATION SERVER (SGVAS)During the installation of SoftGrid the SoftGrid Virtual Application Server Service (SGVAS) was

installed. Because the overhead of this service is so low the minimum hardware requirements of

this box are not so taxing. In fact, a server with a single processor, 1 GB of RAM, and ample storage

space for the package files will suffice for most normal situations. There should be a formal analysis

in place to calculate a best effort on the amount of HDD space that will be required based on the

number and size of anticipated SoftGrid packages. As you will see shortly, once the initial stream of

the package has occurred to the client this server has very little to do and can often sit idly waiting

for additional requests. Dont forget, unlike Terminal Server the applications do not run on the

SoftGrid server at all. They merely stream from the SoftGrid Server, and once cached on the client

locally, they run from that local device.

The installation of the SGVAS prompts the Admin with an essential question, Where isthe Content

location? By default the SGVAS thinks this is C:\Program Files\Softricity\SoftGrid Server\Content,

but this can be located on any network accessible resource including a DFS, SAN or like device. This

Content share is where the SGVAS will look for the .SFT file requested by users when they launch aSoftGrid enabled application.

To continue the flow of the process, once the package was saved by the Sequencer the four golden

files should be copied to this \Content share. Once this is done you have accomplished nothing. You

still have to publish the application to make it available to the users.


15/39

Requirements of the SGVAS:

C:\Program Files\Softricity\SoftGrid Server\conf: All required license files must

be present to start the server service. This directory is used to store the license file

(softricity.lic). When the SoftGrid server service starts it will parse the softricity.lic

for a valid signature, Customer Name, Date Created, License ID, MaxWDClients,

MaxTSServers, License Type, and Expiration Date. It will not match a MAC address to

the Network interface card.

C:\Program Files\Softricity\SoftGrid Server\content: This directory is used to

store all the SFT, SPRJ, ICO, and OSD files created by the SoftGrid Sequencer. These

files may be located on a network share via a configurable Registry key, or specified

during installation.

Ports and Protocols: The SGVAS uses multiple protocols, determined when a

particular action is triggered. When the SoftGrid Client talks with the SoftGrid Server

it uses RTSP (554) or RTSPS (332) for open and close. Once the connection has been

made it continues to send information over the RTP and RTCP high ports (49152 and

greater up to 65535).

Services: When the SGVAS is installed it adds the SoftGrid Virtual Application Server

service and sets it to start automatically.

Executables: The following executables are also installed and run by the SGVAS.

sftdispatcher.exe: The dispatcher process is the controller for the SGVAS,and routes all connections to an available core process.

sftcore.exe: This is the core process for the SGVAS. Three run by default andassist in reserving the buffer in RAM to mount packages to for streaming.

Go Deep


16/39

THE SOFTGRID MANAGEMENT CONSOLE (SGMC)The next logical step in the Administrative process is to launch the central management utility of

SoftGrid, the SoftGrid Management Console. This utility is the one and only place an Administrator

needs to go to in order to fully Administer the SoftGrid environment. From this utility you can

publish application records, assign permissions, create file type associations, control application

licensing, run reports and a plethora of other functions.

The SGMC is a snap in to the MMC version 2.0 or higher. It can be installed on any device using the

setup.exe program supplied by Softricity. By default it is installed on the same device as the SGVAS.

For a complete experience on the SGMC please refer to the official SoftGrid curriculum.

In a concerted effort not to mislead anyone let me state very clearly that no data is actually stored

in the SGMC. All of the actions performed in the SGMC are actually stored in the SoftGrid Data Store.

The SGMC is, in simple terms, a GUI peephole into the SQL database that is the Data Store.

SOFTGRID DATA STORE

All, and I do mean all, information regarding the SoftGrid environment is stored in the Data Store

that by default gets created at the time the first SGVAS is installed. The database can be created on

either a SQL 2000, SQL 2005 or MSDE (recommended for test or demo environments only). Now,

whenever someone approaches a DBA and tells that person they are going to create a new database

on their SQL server the first response from that DBA is usually Like Heck you are!. Once the dust

settles the next response is How big is this new database going to get?. Although sizing any

component in a system is never an exact science and is something that needs to be monitored and

adjusted as time passes, the expected size of the SoftGrid Data Store is very small at approximately

1 MB per 100 applications.

In short, almost everything you see in the SGMC is read from the Data Store and everything you doin the SGMC is written to the Data Store. Not so fast. Make no mistake here, the SGMC does not do

any direct read or write operations to the SQL server. Instead it uses an intermediary component in

the SoftGrid Management Web Service (SGMWS).

When the SoftGrid Server starts up it will contact the Data Store it was configured to use at

installation and request its startup configuration. This Data Store must also be available to the

Administrator using the SoftGrid Management Console in order to add or modify anything about

the SoftGrid environment.


17/39

SOFTGRID MANAGEMENT WEB SERVICE (SGMWS)Like the mediator in a conversation between two delegates at the United Nations, the SGMWS acts

as a go-between for the SGMC and the Data Store. When you perform an action in the SGMC such as

publishing an application record and assigning permissions to it for a group of users in AD, it is the

SGMWS that performs the write action to the Data Store. Conversely, when you see objects

displayed in the SGMC it is the SGMWS that performs the read action to the Data Store and AD.

The SGMWS requires the IIS 5.0 or greater with ASP.Net installed and the permissions set to allow

in the IIS Manager. The easiest way to accomplish this on a Windows 2003 Server is to add these

components prior to installing SoftGrid through the Add /Remove control panel applet. Also,

because .Net Remoting is used as the method of interaction between the SGMC and the SGMWS,

both of them require .Net Framework 1.1 or greater to be installed.

And like the cherry on top of the SGMWS sundae, MDAC 2.7 or greater is required since the SGMWS

is going to make OLE DB hooks into the SQL Data Store. Of course the same data access components

of MDAC 2.8 are available on Windows 2003 by default.

Once you launch the SGMC it will prompt you for the name of the SGMWS to connect to. The SGMWS

will attempt to authenticate the user account as being a member of the group designated as the

SoftGrid Administrators. Only members of this group are allowed to launch the SGMC.

Designer Tip:

Because the SoftGrid Management Web Service will be accessing the Data

Store for read / write operations it would be a good design principle to place

the SoftGrid Management Web Service and Data Store on the same high speed,

reliable segment.

OUR PROGRESS SO FARSo far we have taken an applications installer and monitored it through the 3 phases of the

Sequencer creating the 4 golden files of the SoftGrid package. We have copied those to the \Content

location of the SGVAS and published an application record to a group of users from our AD domain

using the SGMC who used the SGMWS to write the information to the SQL Data Store. Up next, the

SoftGrid Client (SGC).


18/39

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

2000 or 2003 without T/S) and the Terminal Services client (Windows 2000 or greater with T/S

installed). Each has their own separate installer executable which are also available in .MSI format

to make distributing the client with SMS easier.

Just like we said before in the SGVAS 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 virtualenvironment (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 packages .SFT files that users stream and launch their applications from.

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 installs it will select the next available drive letter by default. This drive

letter can be selected during or after the clients installation as well.

The name of the Softricity File System Cache is SFTFS.FSD and can be found in theC:\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

Go Deep


19/39

THE SOFTGRID LAUNCH PROCESSNow that we have the concepts and a grasp of all of the necessary components that make up the

SoftGrid System lets explore whathappens when the user logs in. The following is a conceptual

explanation of the SoftGrid Launch Process.

1. The user Sean starts his Windows Vista laptop while he is in his office in Boston. He isprompted for Windows Authentication and enters his alias and password.

2. Conceptually the SoftGrid Client Service starts and sends the user name to thepreconfigured SoftGrid Server.

3. The SoftGrid Server turns around and uses a standard user account with Read PropertyRights to the AD tree and reads the Member Of group information for Sean.

4. The SoftGrid Server takes those groups and parses the Data Store over an ODBC connectionfor all of the applications that Seans groups have permissions to.

5. The SoftGrid Server sends the location of the .ICO and .OSD files to Sean so that he canretrieve them to his client.

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.

6. Later that day Sean double clicks the .ICO which indirectly calls the .OSD which is read lineitem 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 SGVAS mounts portions of the .SFT in

RAM and streams it to the client.

7. The .SFT streams from the SGVAS into the clients cache and when the minimal launchthreshold is met (FB1) the package decodes to Q:\ and runs for the user.

8. When the user closes the application all blocks of data that had streamed remain in the localcache so that subsequent launches happen immediately.


20/39

In reality the SoftGrid client service starts and captures the token and passes it

to the clients pre configured 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 SGVAS uses an ODBC connection back to the Data Store and retrieves the

permission information for the published application records. The SGVAS

compares the information in the users access token to the groups that have

been assigned permissions to the application records. For any applications thatare determined to have been provisioned to the user the SGVAS 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 SGVAS 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 SGVAS 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 SGVAS 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 SGVAS will sit idle

waiting for additional application requests.

Note: Alternately the .ICO and .OSD files could be placed onto a Web Servers

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.

Go Deep


21/39

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 ondemand 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 Applications 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 applications associated .SFT

file.

The SoftGrid server receiving the request from the client goes to the Data Store to ensure that theuser 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 pre configured

blocks of data. These blocks are 32 Kb by default but can be configured during Sequencing.

As part of the On Demand Deliver 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 Block1 (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 anapplication 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 that 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.


22/39

USER CUSTOMIZED CONFIGURATIONSIf 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 these changes are

written to a User settings file. This file is stored in the Users profile directory of C:\Documents and

Settings\username\Application Data\SoftGrid Client\PackRoot+GUID\UsrVol_sftfs_v1.pkg by

default.

EXITAPPLICATIONS

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.

Tech Tip:

In order to eliminate latency of the Out Of Sequence Operation, especially on a Terminal

Server Client, it would be beneficial to preload the entire contents of the .SFT file (both

FB1 and FB2) to the SFTFS.FSD.


23/39

SCHEMATIC DIAGRAMThe 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 CONTROLAs we stated before, the SGMC is the only point of management for a SoftGrid Admin. But, what we

didnt discuss in detail yet is that all updates to applications can also happen and be controlled

centrally.

It is a natural part of an applications lifecycle to have updates in the form of service packs or hot

fixes become available. These Updates need to be applied to that 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 Applications Package back to a clean

Sequencer Workstation and perform a Package Upgrade, appending the original package with theUpdates. 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.


24/39

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, hot fix, manually modify the files or 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 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.

Go Deep


25/39

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 Packages 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, this will end his connection to the

SoftGrid Server. The next morning when Patrick returns to work he launches Adobe Reader again,

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

Upgrades with SoftGrid for those 24/7 shops that never have true down time. However, I like to

look at itfrom the perspective of even those shops that do have 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 SGVAS

they will seamlessly get the updates in the package.

No more off hour upgrades!!!

The Package Upgrade process will be covered in detail in the SoftGrid Sequencing portion of this

course.


26/39

SUPPORTBesides the elimination of application conflicts, Softricitys SoftGrid Platform 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 applications files or registry entries if they look at those local resources.

This can effectively reduce the number of Help Desk calls an organization requires.

And because the application never actually install itself you dont 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 CONTROLAnother 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.

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.

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.Go Deep


27/39

TERMINATIONAt the end of an applications 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

remove the application from the clients computer.

MOBILITYLets say that I am a mobile user who only comes into the office on occasion to synch up, either

with people or the network. When I am logged into AD in the office I go through the typical

authentication process described earlier and receive all of my shortcuts, FTAs and OSD files. If I go

one step further and invoke a pre load of all of my applications then I can successfully leave the

comfort of the office, go on and 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 SGVAS the

client assumes that the user still has permissions to use the applications 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 SGVAS the application will stoplaunching. 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 SGVAS is not able to be contacted and will launch the applications, bypassing the

time out.


28/39

REGRESSION TESTINGRegression 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. With a SoftGrid

Enabled application however 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 APPLICATIONSDuring the Sequencers 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 tool bar buttons, default fonts, grid lines or something more complex

like a backend database configuration. All of these configuration options will be stored in the

SoftGrid Enabled Applications 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 specific to that user. This

file is stored in the User's Application Data directory, which by default is in the Users Profile

Directory (%APPDATA%).

NON MULTI USER MODE APPLICATIONSAnother advantage leveraged by the use of a UsrVol_sftfs_v1.pkg file for each SoftGrid Enabled

Application or Suite of Applications is applications that previously would not run in a Terminal

Servers Multi-User Mode environment are now able to. 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 can now run successfully on a Terminal Server in Multi User

Mode.


29/39


30/39

CONSIDERATIONSAlthough Softricity 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 theapplication. During the Sequencers wizards the Sequence Engineer must know not only how the

application will behave during the installation 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 are run for an application that runs 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, NT,

Linux, Macintosh, or Windows ME devices a solution such as Terminal Server or Citrix MetaFrame

must be used as the SoftGrid client.

SOFTGRID PLATFORM REVIEWThe SoftGrid Platform has three main parts. The first part is to create the SoftGrid-enabled

applications using the SoftGrid Sequencer. The second part is the backend SoftGrid Virtual

Application Server fulfilling requests from SoftGrid Clients for applications. The last part islaunching 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.


31/39

PRE-LAUNCH DEPLOYMENT1. Application installations are packaged at the SoftGrid Sequencer, resulting in four files: an OSD

file, an ICO (Icon) file, an SPRJ and an SFT File. (These files will be discussed in detail later in

this course.)

These files are then placed in the specified content directory configured for all SoftGrid Servers inthe server farm.

Using the SoftGrid Management Console, application records are created by importing the

configured OSD 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

users have been granted access to.


32/39

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.

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 packages SFT file.

Once a minimal launch threshold is achieved (approximately 20%-40% of the application), the

application interface will appear and be ready for user interaction.

As the user continues using the application, additional code is delivered to the client as necessary

(for instance, 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).

Any custom changes the user makes are stored in the users data directory (the users profile by

default, but this can be changed).

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).

2.

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

locally.


33/39

PRE CLASS SETUP GUIDE (OPTIONAL)

The following is work to be performed by Microsoft employees who have read and passed the

assessment exam of the preceding information. The goal of this section is to assist the student in

preparing their systems in order to continue on to the condensed hands on training. The finished

installation here is to be brought to class with the student in order to continue with the hands ontraining. This is not intended to setup a SoftGrid system in a production environment.

This will guide the experienced network administrator through the steps necessary to get a

SoftGrid Windows Desktop client installed as well as the core SoftGrid System components (SGMWS,

SGMC, SGVAS and a Data Store using MSDE).

This work must be completed prior to classroom attendance in order to maximize the classroom

experience and minimize time out of the field.

SYSTEM REQUIREMENTS

It is assumed that the student will run their SoftGrid environment on multiple Microsoft Virtual PC

disks. During class a maximum of 3 virtual disks will be used simultaneously and as such the

following is the minimum hardware required of the host laptop.

Pentium class processor PIII or greater Windows XP SP2 or greater 2 GB RAM or greater 30 GB HDD free space or greater Microsoft Virtual PC version 2004 SP1


34/39

VIRTUAL MACHINE #1This first virtual machine will be the one that is used for the Active Directory Domain controller, IIS

web server, SGVAS, SGMC, SGMWS and Data Store. This slice should have a minimum of 512 MB of

RAM reserved for it and the LAN settings should be set to host only. This needs to be done so that

all students in class can run the Server with the same name and domain name and not conflict since

each will be on their own isolated virtual LAN.

*NOTE: use the word password for all instances of any password. Again, since this is only a

classroom lab setup tight security does not need to be strictly adhered to.

SoftGrid VirtualApplication Server with

MSDE Data StoreSoftGrid Management Web Servicew/ SoftGrid Management Console

Domain Controller

RDP/ICAClient

Terminal Server 2003SoftGrid TS Client

RDP/ICAClient

RDP/ICAClient

Mobile UserWindows 2000

SoftGrid UniversalDesktop Client

w/ Mobile Agent

`

Windows XPSoftGrid Universal

Desktop Client

sgbrowser SoftGrid

Administrators

SoftGrid

Users


35/39

It is necessary to aquire the following software prior to setup:

Windows Server 2003 R2 SoftGrid License File (Softricity.lic) SoftGrid Distribution Software (ver. 4.0.0.524 or greater) Windows XP SP2 or greater

Setup Steps

1. Install Windows Server 2003 R22. Name this server SGServer3. Configure this Server to be a Domain Controller for a Domain named Training.soft4. During the creation of the Domain say yes to allow this server to be the DNS Server5. In Active Directory create the following users and groups

Domain Global Group called SoftGrid Administrators

Domain Local Group called SoftGrid Users

Users Accounts with the following names

SGAdmin

SGUserSGBrowser

6. Set this accounts password to never expire7. Add the following users to the appropriate groups

SoftGrid Administrators Administrator, SGAdmin

SoftGrid Users SGAdmin, SGUser, SGBrowser

8. Install IIS and ASP.NET through Add / Remove programs

NOTE: Since this VPC operating system is Windows Server 2003 the SoftGrid requirements of

MDAC 2.8 and .Net Framework 1.1 are already installed.

Use the following steps to complete an install of the necessary SoftGrid System components. Thesesteps are meant for a single box solution and follow the Typical installation steps with an MSDE

Data Store. Following these steps will place the big 3 (SGVAS, SGMC, and SGMWS) on this VPC.


36/39

Step by Step

Follow the steps below to complete a typical SoftGrid Platform installation:

1. Insert the SoftGrid Platform CD.2.

SelectNexton Welcome to the InstallShield Wizard for SoftGrid Virtual ApplicationServer screen

3. Read the License Agreement. CheckI accept the terms in the license agreement. ThenselectNexton the License Agreementscreen.

4. Enter User Name and Organization, then selectNexton the Customer Informationscreen.

5. CheckTypical, then selectNexton the Setup Type screen.6. CheckInstall MSDE, then SelectNexton the Database Server screen.7. Enter two passwords and confirm both, then selectNexton the Database Password

screen.

Note: The top password is used as the Administrator account of the MSDE Database (SA).

The bottom password is a user password (softricity) used by the SoftGrid Virtual

Application Server to connect to the database. It is recommended to use separate passwords

and document these passwords.

Note: MSDE will create a database named SOFTRICITYby default in the location you

specify.

8. Enter your Domain Name, User Name and Password for your directory server. Then selectNext.

Note: Supply the sgbrowser account that was created in Active Directory. This account will

access the Account Authority on behalf of SoftGrid.

9. Type the name of a User Group that will have access to the SGMC (SoftGridAdministrators), then select Next on the Administrator Group screen.

Note: The group selected here will be given access rights to the SoftGrid Management

Console, which controls all administration within the SoftGrid System. It is recommended to

select the SoftGrid Administrators on this screen, but any existing group within your

account authority may be selected.

10.Type the name of a User Group, then selectNexton the Default Provider screen.Note: The group selected here will be given access rights to the Default Provider which

controls policies for how applications may be run. This group is also assigned access rightsto the Default Application. It is recommended to select the SoftGrid Users Group on this

screen.

11.Specify the SoftGrid Licenses location, then selectNexton the License Location screen.Note: Simply point to the Softricity.lic file and setup will place the license in the correct

conf directory.


37/39

12.Leave Default Server Group as is, then select Next on the Server Group screen.13.Leave the default location for the Content Path, then select Next on the Content Path screen.

Note: Setup will create a directory called C:\Program Files\Softricity\ SoftGrid

Server\content by default, and adds a test application called Default Application. All

applications that will become SoftGrid-enabled must be present in the content path of all

SoftGrid Virtual Application Servers that will be responsible for streaming them.

14.Select Install on the Ready to Install the Program screen.15.Select Finish on the InstallShield Wizard Completed screen.

Note: Softricity does not recommend using MSDE as the Data Store in a production

environment due to several limitations of MSDE. This type of database should only be used

in demonstration, test or Proof Of Concept installations.

Continue the setup of the SoftGrid Server:

1. In order to make the SoftGrid Package files available for streaming in the class it isnecessary to create a UNC share for the SoftGrid Content Directory.

Default permissions on this share are acceptable.

2. Test your system by navigating to the \Content share and double click on the testapplication called DefaultApp.osd.

Note: You will fail to launch this application because you do not have a client installed yet.

Next, is the client install.


38/39

VIRTUAL MACHINE #2This second virtual machine will be the one that is used for the Windows Xp Professional machine

that will act as the SoftGrid Client. This slice should have a minimum of 256 MB of RAM reserved for

it and the LAN settings should be set to host only. This needs to be done so that all students in

class can run the Workstation with the same name and domain name and not conflict since each

will be on their own isolated virtual LAN.

*NOTE: use the word password for all instances of any password. Again, since this is only a

classroom lab setup tight security does not need to be strictly adhered to.

1. Install Windows XP Professional with SP 2 or greater using a standard install.2. At least 6 GB of Disk Space3. Computer Name: SGClient4. Join it to the Training.soft Domain using the Training\Administrator user account5. After Reboot access the SoftGrid Installation Media

Step by Step Client Install

Follow the steps below to complete a typical SoftGrid Windows Desktop Client installation:

1. Navigate to and double-clicksoftgrid-wd-setup.exe to begin installation.2. When prompted, accept the Software License Agreementand select Next.3. Leave the default location for the client destination.4. Leave the default cache size (2048 MB) or type the amount of disk space that should be

allocated to the cache here. (64 GB maximum.) Leave all default values and select Next.

5. Leave the box Skip Advanced Data Storage Settings selected and select Next6. Specify the SoftGrid server that this client will use:

Display Name: SGServer Type: SoftGrid Virtual Application Server Hostname: SGServer Port: 554

7. Select Next.8. ClickInstall to install the client.9. Click Finish on Install Wizard Complete.10.When the installation is complete reboot the client.11.Login to Windows as the user SGAdmin

Note: No application will appear on the desktop because you have not published any applications

as of yet. You will get a full exposure to this in the class to follow.

Test your client and server communication

1. Select Start to Run


39/39

2. In the Open dialog box type\\SGServer\Content\Defaultapp.osd3. This should launch the default SoftGrid application and show you the Softricity Logo.

VIRTUAL MACHINE #3This Virtual Disk will be used as the Sequencing machine during the classroom portion of

Sequencing. It is vital that this Virtual Machine be a clean install and have nothing but the base

operating system and latest service pack on it.

Do a fresh install of Microsoft Windows XP Professional SP2 or later to a virtual machine. DO NOT

use your "standard desktop image" or install any other applications on this image, at this time.

Add a second dynamically expanding virtual hard disk. Within the virtual machine, set the drive

letter to "Q". Enable Undo disks and commit the existing configuration. After each time you

sequence an application, you will "Turn off Virtual Machine and Discard Undo Disks" to this VM in

order to get back to a "clean" operating system.
http://sgserver/Content/Defaultapp.osdhttp://sgserver/Content/Defaultapp.osdhttp://sgserver/Content/Defaultapp.osdhttp://sgserver/Content/Defaultapp.osd