Last week I talked about collecting streaming agent client logs and mentioned that I would discuss server logs another time. Well, what better time than the very next article? I suppose your response to this depends on your interest in the information. :)
Ok, so let's take this from the top and look at what components make up the server side piece of Symantec Workspace Streaming (formerly AppStream).
Installation Types
The first and simplest is the single-node install. This takes every single component and installs it on a single host with the exception of the database if it happens to reside on a different box. To clarify, if you are connecting to a SQL 2005 database the installer will build the tables and schema on the database to which you provide a dbo account for, in the install wizard. The installer will also generate an account with dbo privileges to the SWS database, and this account will be used going forward for any DB related read/writes to the SWS DB only. So tell your DBA not to sweat, we are only briefly taking over your television set.
The single-node install consists of the following components.
Front-end (FE)
- Streaming Server (STS)
- Launch Server (LS)
Back-end (BE)
- Console (Admin console)
- Streamlet Engine (STE)
- Data Access (DA)
The piece that ties everything together is the AWE Agent. This is the communication agent between all SWS components. On the installation type noted above, there is a single instance of the agent.
Multi-node installations can take various forms depending on how you decide to implement it, but the general result is that you are taking the components of SWS and splitting them among multiple hosts. A couple of the biggest benefits are redundancy and load balancing. (Note: A load balancing device is required to set up LB among Launch Servers)
The most common configuration is to have the back-end installed on one host and the front-end installed on one or multiple hosts. You can also choose to add a stand-alone DA (for DB connectivity redundancy) to each FE or on yet its own host. Once again all these components are tied together via the AWE Agent which at this point is installed on every host.
I wish I had the time to go into the details of all the great features available with Workspace Streaming, but there is one that I do want to mention and that is Proxy-Caching support. The reason I thought this would be important to include here is because in a way this is an optional component that we have build functionality to take advantage of. Here is why. Let's say you have a proxy server at your remote locations, you can configure SWS to pre-cache all the streaming blocks for a package to the proxy server. When the endpoint requests blocks for a package the user is provisioned for, the blocks are collected from the proxy server and not the Streaming Server. Here are a few things to keep in mind when configuring your environment for Proxy-Caching.
. The Streaming Server should be installed to communicate over the same HTTP port as supported by the proxy server for caching and distribution.
. You will need to configure direct block requests on both the server and client.
- Server
- Browse into the installation folder on the streaming server (..StreamingServer\server\bin)
- Edit AppstreamServerCfg.txt
- Make sure UseDirectRequests= is set to true.
- Client
- Browse into the installation folder on the client (..\StreamingAgent\bin)
- Edit AppstreamCfg.txt
- Make sure the configuration options in the section --- DIRECT BLOCK REQUESTS --- are not commented out.
- USE_DIRECT_REQUESTS=
- This value may not be here by default. It should be set to true to enable this functionality.
- PROXY_CACHE_MAX_BLOCKS_PER_REQUEST=
- Default is 0 which sets no max. If you have very large packages you can indicate a value to break up the number of blocks that will be requested in one direct request.
- PROXY_CACHE_MAX_LENGTH_OF_RANGE_REQUEST=
- Default is 5000. This sets the max length of the range for the HTTP header sent by the client.
- PROXY_CACHE_OFFLINE_BANDWIDTH_LIMIT=
- Default is 400000. This sets the allowable bandwidth when the client is requesting offline blocks using the direct block request functionality.
Can I submit this as the official admin guide for SWS? Yes ladies and gentlemen, it's that simple. There isn't that much to know here. Seriously though, in the real world there are many variables at play and at any given time the success or failure does not only depend on the product you are implementing. Think about this...In a lab environment either one of the aforementioned installation types can literally be setup and deployed within 30 minutes to 1 hour. Sure, increasing the number of components and adding configuration requirements will increase this time, but this is an increase due to volume, not complexity. Workspace Streaming has been optimized to be efficiently functional out of the box, in just about any environment using only the default configuration. It's a relief to know that my deployment planning is not constrained by the installation time of the solution I am implementing.
Where was I, oh yes. So I told you all of that so I can tell you this...
If you are having problems with, or suspect any SWS server components you can help expedite the troubleshooting process by preparing server logs prior to contacting support...and here is how to do this.
Logon to the admin console. http://BackEndHostName:9842
- Click Collect Logs. This is the very last option at the bottom of the left navigation menu.
- Scroll to the very bottom of the page and click Get All Logs and Config Files.
- Left-click the file link with the current date/time stamp and It will pop-up a file download dialog box. Click Save to save the file to your preferred location.