Streaming with Virtualization Primer
Now that you've installed both Symantec Workspace Virtualization and Streaming, you are looking to utilize the benefits both offer in a teamed manner. First let's take a brief look at what each one offers before we glance at how they work together. We'll wrap up this week with a look at how you can help streamline the support process through proper client logging and log readiness.
Symantec Workspace Virtualization uses a unique technology to capturing an application installation and creating what is called a layer with a .VSA extension. This layer contains all to pieces that you would normally see go into the programs installation directory, but they are located inside a hidden folder on the root drive (c:\fslrdr). This area of the layer is referred to as read only. There is also a writable section that captures per user information such as HKCU changes and/or any customized changes to any area of the file system not listed as an "exclude entry" that are made while using this layer. While in an inactive state the file system has no awareness that this program exists. It is as if it was never installed. Once this layer is activated the file system is "tricked" to seeing the installation as if it was actually installed conventionally. In fact, to any user browsing through the file system it will look no different as well.
Symantec Workspace Streaming provides a centralized delivery mechanism for what are called Packages. The Streaming Composer uses a traditional snapshot process (baseline, post-install, delta) to capture the content that makes up a streaming package. What is specifically related to this article is the ability to take an exported layer or VSA file and create a virtualized streaming package. This package is automatically delivered to the virtualization agent and activated on the endpoint via the streaming agent. With SWS 6.1 one of the biggest and most exciting new features is taking a pre-made MSI file and streaming it directly into a layer on the endpoint. What this means is that the streaming composer takes the MSI and creates a package that will on the fly, be converted to a VSA and be a fully virtualized layer.
By combining both of these technologies, you are now able to utilize the benefits of launching large applications before the entire application is fully brought down to the endpoint. Leveraging the streaming technology startup block, the application (during packaging) learns the exact portion of the program that is needed to run. A program that may take up 1.5GB of disk space may only require 25MB worth of data to run and be operational. Additional blocks will be brought down as needed, fully transparent to the end-user. Since you have now deployed these agents to your endpoints and started streaming packages, let's look at some important configuration details to be aware of.
Svscmd.exe or AppMgrCmd.exe
When working with virtualized applications which have been streamed, AppMgrCmd.exe is the utility that should be used for any changes, such as layer deletion. It is possible to utilize svscmd.exe, but it is not recommended since this can destabilize the layer and break the streaming agent's ability to properly interact with it and continue managing it. While Svscmd.exe is added to the system path and can be executed from any location, AppMgrCmd.exe is not and can only be run inside "%programfiles%\Altiris\StreamingAgent\bin". Alternatively this can be manually added to the system path post-install if you prefer.
The streaming agent contains a set of instructions in the file called AppstreamCfg.txt. There are many settings that can be added to this file besides those present to control the behavior of the agent, but for the purpose of this article I want to point out how to control log files, since these are a critical component when calling for support. The actual file contains additional lines for this section, but we are only concerned with the following three for now.
; --- LOG FACILITY DEFINITIONS --- Debug.LogFile.TxtPath=C:\~AC\Logs\MgrLog.txt Debug.LogFile.BytesSize=500000 Debug.LogFile.MaxLogFiles=50
TxtPath points to the location were the streaming agent will store all the logs. By default this resides in the Logs folder of the cache directory, set as ~AC by default.
ByteSize indicates the maximum file size allowed for the logs in bytes. This represents the total of all the log files created.
MaxLogFiles indicates the total number of log files to write prior to rolling over and starting from MgrLog1.txt.
The naming convention for the logs is MgrLog1.txt - MgrLog[n].txt, where [n] represents the value set for MaxLogFiles.
In general the default configuration is adequate and recommended. Setting the size lower can result in not collecting enough data to debug when contacting support. The number of log files can be lowered without losing needed debug info, but keeping the default provides better manageability without having to look through hundreds of lines in a set of fewer files. In most cases one of the first things support will request is a collection of client logs, so if the situation is critical you can help expedite the time to resolution by preparing these logs prior to contacting support. Whenever possible make sure to generate these logs on an affected machine immediately or as close to as possible following the problem in question. If it is easily reproduced, then it should not be a problem doing this. To generate the logs you will need to execute some instructions using AppMgrCmd.exe via the command line. Once you have opened the command prompt and changed directory to the "\bin" folder of the streaming agent, you can type in and run "appmgrcmd.exe -gr -all". Once completed it will place a folder called RecoveryInfo, one level up under the "\StreamingAgent" folder. Browse to this location using your preferred file explorer, and you will find a series (if logs have been collected multiple times) of folders labeled "AppStreamRecoveryInfo.1 through .n". The contents of each folder make up the entire set of logs collected for one execution of the above command. The most recent set can easily be identified by sorting by the date modified column of the file explorer. All you need to do is zip up the entire folder matching the most current date and time stamp.
With this information, and of course other relevant details collected at the time of troubleshooting, EndPoint Virtualization Support can troubleshoot most client related issues. In some cases server logs will be requested as well, but I'll save those details for next time.