Recent Changes

Monday, August 9

  1. page SWV - Virtualizing a Print Driver edited Virtualizing a Print Driver with SWV {…

    Virtualizing a Print Driver with SWV
    {} Jordan's picture
    JordanJuly 9th, 2009
    Filed under: Workspace Virtualization, Basics, Features, Windows, Tip/How to, Virtualization, Endpoint Virtualization
    Long time packagers know that the only way to capture a print driver, the most common being the Adobe Acrobat PDF Printer, in SVS is to use a Global Capture. At the same time they know that your Global Capture can cause problems with a layer (you never know what's going to be inside it.) So there's always been a catch-22 when dealing with this situation.
    With SWV 6.1 there's a method for making sure that print drivers get into a layer by using single program capture, it takes a little extra work on the packager's end but in the long run it's much better than using the unpredictable Global Capture. And while, currently, I'm only aware of this method working for print drivers there are possibly other troublesome applications that can be captured as well.
    To understand this new method for capturing you'll need to understand what is going on when a print driver is being installed and why SWV doesn't track this part of an install. When a print driver needs to be installed it's handled by the Window's service Print Spooler, spoolsv.exe in the process list, and this process\service is not getting launched by the installer but instead Windows itself. SWV cannot track it as a child process of the Adobe process-which is why a Global Capture has previously been required to get a print driver into a layer.
    So if we've got a system process running that is being indirectly called by an installer, how do we virtualize it without a Global Capture? In SWV 6.1 we introduced a new feature called "Auto Run From Layer" which is a tab inside of the Layer Properties Window. When you add a process to this list any time that process is launched (by Windows or another application) it will run as if it was virtualized itself. In other words, all changes it makes will get captured into the layer. This behavior is more or less the same as Run From Layer (Execute from layer in SVScmd) which is a feature that's been in SVS for quite some time but not exposed via a GUI before SWV 6.1. You'll need to pass in the full path to the process because the feature doesn't use Path Variables. There are a lot of uses for this feature and this is the first that will explain how versatile it is.
    When capturing a print driver we need to add its process, spoolsv.exe, to the Auto Run list so when the installer tells Windows that it has a new printer to install and the process is launched it will run as if it itself was virtualized. Then when the process is done you need to stop the Print Spooler service and immediately delete the Auto Run Process item because Auto Run From Layer will activate a layer if any process it's watching launches.
    Before I get into detailed steps on how to capture Adobe Acrobat 9's print driver there's one more thing that needs to be brought up. If you open up Task Manager on a computer there's a good chance that spoolsv.exe is already running. In all my tests with Acrobat that process gets re-launched by the installer so our Auto Run item will execute. However, if that doesn't happen the process will not get tracked by SWV because Auto Run From Layer only works when a process is launched and not on processes that are already running?
    So if you're noticing that your install isn't re-launching spoolsv.exe and your print driver isn't getting captured properly what can you do? Go old school with SVScmd's Exec from layer (Run from layer is SWVadmin) and a command file.
    Here are the steps: (note this is not required for Acrobat 9)
    Open up Task Manager and get the PID for spoolsv.exe
    Create a new CMD file
    Inside it add following line: SVScmd myLayer exec -p myPid where my layer is the layer name or GUID and myPid is the PID you got from step 1.
    Next add a line that points to your installer (remember if it's a MSI to use Msiexec)
    Save the file
    Create a new layer in SWVadmin and point to the CMD file when browsing for a single program capture.
    To Capture a Print Driver Using Auto Run From Layer
    Create a new layer is SWVadmin or SVScmd, it doesn't matter if you have anything else in the layer (if you want to combine an existing program with Acrobat Pro) but this guide will assume you're using an empty layer.
    Double click your layer to open up the Layer Properties window and navigate to the Autorun Applications tab.
    Right-click and select New AutoRun Entry.
    Add C:\WINDOWS\system32\spoolsv.exe to the text entry and close the Layer Properties window. {}
    With the window closed right-click your layer and select Add to Layer which will place our layer back into capture mode. {}
    In the window that opened up select Single Program Capture and point it to our Adobe Installer and click Next twice. {}
    Install Acrobat as normal. To end capture you may need to kill acrotray.exe and other related background processes to actually end capture. See this blog post for more information on how Capture has changed with SWV.
    Once capture is done you'll need to stop the Print Spooler before you'll be able to deactivate the layer, since spoolsv.exe is running a SYSTEM a force deactivate will not work. So open up the services manager, navigate down to Print Spooler and stop it. {}
    Deactivate your layer.
    Open back up the Layer Properties window and navigate to the AutoRun tab.
    Right-click and select Remove Autorun Entry {}
    Once you've got the layer you'll need to either flag it to Start On System Startup or run a script that will restart the Printer Spool after a layer is activated so you can use the PDF printer, since the printer service has to be restarted to load new printers that were just installed.
    More @

    (view changes)
    12:42 pm
  2. page SWV - Automatic Pré-Provisioning Virtualized Software edited Symantec Workspace Streaming - VDI Pre-Population Provisioning {…

    Symantec Workspace Streaming - VDI Pre-Population Provisioning
    {} Scot Curry's picture
    Scot CurryAugust 9th, 2010
    Filed under: Workspace Streaming, Configuring, Integration, Tip/How to, Endpoint Virtualization
    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.
    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.
    More @

    (view changes)
    12:39 pm