Workspace Streaming

 View Only

Workspace Streaming - Stream from a Network File Share 

Oct 21, 2010 12:19 PM

Beginning with Symantec Workspace Streaming (SWS) 6.1 Service Pack 4, we have added the ability to stream from an external repository. The external repository can be a UNC share or some other network attached storage.  This has the benefit off-loading some of the work from the Streaming Server, which will reduce the number of servers required in large implementations. This technology also makes it so users will use the nearest server if configured correctly.

Create the Repository

At this point there is not a link to access to the respository configuration tool from the Configuration and Management console. Log in to the Managment console and then type the URL directly into the browser. The link to the configuration tool is http://servername:<port>/externalRepos.awe, where the servername is your management console server, and the port is 9842 unless you modified it. You will be presented with a link to create a new repository.

New Repository

You have the option of creating a UNC fileshare (file:////), SMB fileshare (file://), or http (http://) share. When complete your setup screen should like the following:

Repository Created

Repository Rules

One of the most interesting parts of this feature, is that it is possible to define rules for which repository a user should access. For example, if you use the IP address rule it is possible to have users stream packages from the nearest streaming server based on that address. The type of rules that can be used are:

  • User - using wildcards if necessary, you can select users to stream packages from a specific repository.
  • Group - if a users is a member of a listed group, the user will use the specified repository
  • IP Address - Probably the easiest way to create location awareness. You have the option of using wildcards (192.168.11.*) or Classless Internet Domain Routing notation (192.168.11.0/32 which will match 192.168.11.0 through 192.168.11.32).
Repository Rules

The rules can also be ordered according to priority of processing. You can drag each of the windows above or below each other. For example, in the diagram above I can drag the second rule to the top to make the IP rule a priority over the rule for Scot.

Populating Packages in the Repository

After you’ve loaded your package to the Streaming Engine and enabled in your Server Groups you will need to manually copy the package to the repositories. Copy the packages from the following location on your Launch Server:

Package Location

You will need to copy all folders beneath the pkgRepo folder and place them in your external repository (you do not need copy the PackageStore file). The share that you use as your external repository need only have Read permissions set for all users that will access the repository.

How It All Works

Once the rules are defined they are immediately saved on the Launch Server. When the streaming agent makes a request for an application the rules get read by the streaming agent and the client processes them accordingly. For example, if my client’s IP address matches an IP rule then I will receive my package from the repository from which the rule is assigned. The streaming server will always be a fall back in the event the package is not on the repository or the repository is inaccessible.

To verify you are streaming from your external repository you can check the client logs. The easiest way to find this is to stream the application then search the latest client log for the name of your repository. Below is an example pulled from my client log file (by default this file is located at C:\_AC\Logs\MgrLogsome number ,sort by time and look for the log that was in use while performing the test):

[1392] GENERAL_FLOW,XPFRepositoryHandler::createSourceProvider#277| XPF repository initialized from \\sevdc\eastshare\71869e8381b74a4cbb1f50645b80f223\1\71869e8381b74a4cbb1f50645b80f223_1.xpa

Statistics
0 Favorited
1 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Feb 02, 2011 11:28 PM

Hi & thanks a lot this "not in the manual" important article !

Most of the time in software delivery, we would like to avoid a reading right from all the users, on the Software Library. For sure, that is not any more MSI format, and most user will not be able to reuse XPF... But as SWV is free of charge for home users, not easy to guess if some XPF can copy from the share to an USB, and unwanted company licensed softwares to be reused at home...

I am surprise that is not the "system account" or "network service" account from the computer to be the "reader" of those XPF repository share ! If it was the case: only the "domain computers" should have read rights, or a service account.

Best regards.

Jan 05, 2011 08:50 AM

Hey, this is good article. I am facing one issue. For already imported applications, this solution works fine. If I am importing new application then the repository is not get created in alternate location. As I am running out of space in my front end server, is there any alternate for this?

 

Thanks

Zak

Nov 20, 2010 12:59 PM

Hi Will,

that's a pretty good questions!

First off, a few facts

  • all matching rules will be accounted for (starting SP6 MP1)
  • ordering of rules play an important rule
  • rule can point to an abstract name, for instance, a DNS entry

Now, here are some ways you can approach this:

1. Define multiple rules and order them such that their scope grows wider - this could be a combination of user groups, ip ranges, subnets, etc. In the example Scot defines, he starts with users like "Scot" and then the IP range. In this case, user named Scot, will match the 1st rule and 2nd rule (if he happens to belong to that IP range) and 1st takes precedence. For other users, only the 2nd rule will match if they belong to that IP range.

2. The repository that the rule points to can be a virtual / abstract name - you could define a DFS share that has a DNS entry, where the DNS can round robin. It can be a virtual IP defined on a load balancer with multiple nodes behind them and can be managed with some persistence and routing rules. Typically load balancers manage http traffic better. So, in this case it would be a repository that supports http. Another possible (not so much preferred) option would be to define hosts file enter per machine at logon so that the load is distributed acorss the multiple repositories.

Hope this helps.

Nov 19, 2010 12:14 PM

Thanks Nirmal, you did answer my disaster recovery question. Here's another one.
We have several repositories that service each subnet. For example, for all IPs in 10.5.x.x, we may have several repositories,(server 1, server 2, server 3) that service clients within that IP range.
How can we configure external repository rules such that, if a client IP address falls in the 10.5.x.x range, that they will hit the repositories in either a round robin or load balanced fashion, such that one repository does not get overloaded at any one time?

Nov 13, 2010 02:55 AM

Hi Will,

external repository rules configurations are stored in the database so, yes, restoring the database in case of disaster will recover these rules.

External package repository has no direct connection to front end servers with or without load balancers. All that happens is, when the application is initially requested by an end point, based on the rules the user is directed to an external location that is independent of the front end from where the application blocks can be streamed. These rules, at this point are not even related at server group level.

Does this answer your question?

Nov 12, 2010 10:06 AM

Is there a way to export this configuration such that, in the event of a disaster recovery scenario, to restore the rules, we simply have to import the old config? Or is this stored in the backend streaming database, and therefore the recovery method is to simply restore that database?

Also, how does this scenario work behind a load balancer for the front end servers?

Nov 03, 2010 06:22 PM

If you are using a network share, it uses the currently logged on user's windows credential to authenticate against the network share when streaming from this network share. So, the flow would be as follows:

Pre-pop icon use case (for example):

1. User double clicks the pre-populated shortcut from desktop

2. Request sent to the front end server, which then responds with the list of possible repositories the user could stream from (based on the rule defined)

3. Streaming agent "on behalf of the user" makes streaming request to the repository, which in this case (let's assume) is the network share location

Note:

If you are not sure which users are going to be routed to this network share, it is better to have read access to all domain users. Worst case, if access to this repository fails, it will fall back to (the next repository in the list if its 6.1 SP6 MP1, then to) the front end server.

Nov 03, 2010 11:31 AM

Are you asking from the agent to the file share or the server to authenticate the unc's?
Is your environment single or multiple domain?
Neil

Nov 02, 2010 11:39 AM

Great article, thanks for posting Scot.

I have a question regarding authentication into the remote network shares. Do we know what credentials streaming will use to authenticate into the remote network share?

 

Thanks,

Lito

Oct 22, 2010 09:45 AM

Thank you for bringing this up.  As dpowell2 states, this functionality is only available if you have packaged your applications in XPF format which was released with Workspace Streaming 6.1 SP4.

I will create an article that documents the steps of coverting your existing VSA files to XPF format.

Thanks for the comment.

Scot

Oct 22, 2010 06:02 AM

I only have one app in the packageRepo folder, do the packages have to be uploaded in XPF format only? 

Related Entries and Links

No Related Resource entered.