Workspace Streaming

 View Only

Symantec Workspace Streaming - VDI Pre-Population Provisioning 

Aug 09, 2010 02:49 PM

Symantec Workspace Streaming (SWS) is an ideal tool for user based provisioning. It is a key component in virtualization strategies that focus on freeing users from specific devices, giving them access to their applications from any device.

While this is the primary use of SWS, I often run in to customers who are implementing streaming in conjunction with a VDI initiative. In the environments I have been involved with, the customer spins up a number of VM session that just sit there for users to access, avoiding the boot process on initial connection.

These users would like to stream packages down to these VM's prior to user login. This will eliminate the start-up penalty associated with launching an application for the first time that has not yet been streamed to the local cache. With a couple of minor updates to the VDI image registry, pre-provisioning of the package can be accomplished.

User Configuration

To make the applications stream to the VM's we are going to use a generic user account. If you are using Active Directory or LDAP, you will either need to create a user in the directory, or determine a generic user account that will be used to stream the applications to the VDI sessions. The Symantec Workspace Streaming agent will use this account on boot up to look for packages that should be streamed to the machine. In this example we will be using SWSUser as the generic account.

LDAP Settings

Package Configuration

Symantec Workspace Streaming provides a number of option as to how packages can be delivered to users. In the case of a VDI implementation, we need to update the package configurations to allow the packages to stream down to the computer as soon as the session starts, which will be at system boot time.

To do this select the package that you want to stream down automatically and click on the link to that application. Note: You don't want to click the plus.

Select Package

Once you have the application open, set the Options on the packages to be as follows:

Package Options

Provision the Package

Now that the package is ready to go all we need to do is provision it to our generic user. It is possible to put the generic user in a group, and provision the package that way, but it is considered best practice to control this process through a single user. To do this click on the Provision tab, and enter the generic user name in the search box.

Once the user is selected click the provision button.

Provision Button

and assign the package to the generic user.

Provision Package

Client Workstation Configuration

Up to this point, everything has been very standard configuration information. This step is where the "secret sauce" to make this work comes into play.

There is a registry key HKLM\Software\AppStream\AppMgr\Apps\Licenses, with a string (REG_SZ) for AppStreamUser. When we create the base image this value has to be set to our generic user account. When the SWS Streaming agent starts at boot up, it will look to this key to check for provisioned applications. Based on the package options, those packages will be automatically streamed down to the client machine in the background. This registry key needs to be set to our generic user.

Registry Setting

Best Practices

It has been our experience that the best candidates for this type of pre-provisioning are core apps that will be used by all user every day, that for some reason have not been included in the base image to either to keep the image smaller and more manageable, or to enable the applications to be managed for metering, licensing, and upgrades.

It should be noted that this configuration does not allow for "user randomization" which we normally experience with Workspace Streaming. Because all of the machines come on line, and start the streaming process at essentially the same time, this configuration will need planning to make sure it operates efficiently. If you plan on implementing this technique, I would encourage you to contact one of the Streaming specialists to assist with the optimal configuration.

Summary

Using the techniques described here you can pre-deploy applications to your VDI environment. This is has the advantage of keeping your non-persistent images as small as possible while providing your end users a very responsive system where applications are complete available when they launch the application.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Nov 16, 2011 06:55 AM

Beware the Orcale Virtual Desktop Client (v2 only tested) compared to a Sunray. We found that in our site the VDC didnt populate the user but the Sunray did due to the way each works with the current software.

Sep 16, 2011 10:30 AM

Hi Ryan, thanks for the info, i've used this successfully now. Is there any more info on how the client picks up the logged in user? I noticed, and was especially drawn to, where you said it should be an "integrated login environment". Does this mean something like where the remote computer is NOT being logged into via a terminal services/rdp session? We noticed with our Oracle Sunray VDI setup that the appstream client doesnt' enter a username as a value in that regkey. That issue we can script around but I suppose this may be something many others come across and is worth highlighting (if this is the reason of course).

May 20, 2011 07:43 PM

The password is not needed, the provisions are retrieved by just the username.  The packages will be installed as SYSTEM sessions, which do not need this username or a password for authentication.

You can deactivate the user in AD.  As long as the SWS server can lookup the user and assign provisions to it, that user can be used for "userless prepopulation" on the client.  The user account does not need to be able to logon to a system or be impersonated.

May 20, 2011 07:38 PM

That should work.  Rather than restarting the AppMgrService, you could run "AppMgrCmd -cpn" (Check Packages Now command, same as doing "Update Applications" from the SWS GUI's systray icon).

Make sure the other values in the key point to the correct server and the server is reachable when the client starts.  Also, this should be an integrated login environment, otherwise at user logon the SWS client will still use the same generic user name for the provision information request instead of the user that just logged in's name.

May 18, 2011 03:20 AM

Hi all,

 

Hi would like to know how we can do a pre-population of package after the first boot of the machine --> Can we reuse this registry for (re)populate new packages during night, offline users ? E.g. force the registry to the value the generic user name, and restart the AWE service on client ?

We are looking about this with Pascal, but we aren't sure that it works correctly.

Here the script that we have included in Altiris console to do for pre-populate during the night:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\AppStream\AppMgr\Apps\Licenses /v AppStreamUser /t REG_SZ /d s-package_populate /f

net stop AppMgrService

net start AppMgrService

 

Has someone allready test this function on is domain?

Thanks for you help yes

May 12, 2011 08:46 AM

it seems not need any more to enter registry

SWS.USER_NAME=useraccountprepopulatesoftpackages

May 12, 2011 08:26 AM

Thanks scot: If I understand well, we do not need to know or store the pwd this "package prepopulation" user's account ! Well, can we deactivate this user ? (Some CSO will do not like this user never used :)

Aug 12, 2010 08:21 PM

Thanks so much for posting this!  We have been looking at pre-populating our streamable apps and this is a perfect example with great pictures to boot.  Thanks Scot!

Related Entries and Links

No Related Resource entered.