Workspace Virtualization

Virtualizing Internet Explorer Using the SWV Layer Definition Tool 

03-26-2010 12:22 PM

The SWV Layer Definition Tool allows administrators to export Virtual Application (i.e. layer) information to a “Layer Definition File” (LDF file) and to create or modify a layer from a layer definition file. This article highlights how to create a virtual application package for Internet Explorer using the new SWV Layer Definition Tool.
Symantec Workspace Virtualization provides the capability to capture an application installation to a redirected area (i.e. sub-layer) in which all of the files, folders and registry information that comprise the application are stored. After the application has been captured, it can be exported to a package (VSA file) that can be deployed to endpoints. While this is the typical case for creating a virtual application, there are scenarios where it might be useful, or even necessary, to have a mechanism to reliably create virtual applications where capturing the application installation is not possible.
For example, suppose you want to create a virtual application package for Internet Explorer 6 (IE6). Because IE6 is included with Windows XP, it is not well suited for the capture mechanism described above.  To virtualize this application, the Layer Definition tool lets us handcraft an IE6 layer using the SWV Administration tool, and then export the definition to a layer definition file, which can later be used to re-create the virtual application layer in a reliable way. Some might question why Symantec doesn’t just package Internet Explorer 6 and make the package available for download. The answer lies in the fact that an IE6 virtual package is comprised of Microsoft system files that can’t just be packaged up and made available to customers due to file redistribution restrictions. Therefore, the Layer Definition Tool tool was created to ensure that customers could reliably create virtual applications where installation capturing is not feasible.
To capture IE6, we need the ability to supply a layer definition file that contains all the information required to create an IE6 virtual application layer, without including the vendor-owned files. Enter the Layer Definition tool. Let’s take a closer look at how this tool can help us address this problem.

Creating a Layer Definition File

The Layer Definition tool is a command-line driven application that performs two operations: 1) Exports a virtual application package to a layer definition file and 2) Creates or Modifies a virtual application layer using a layer definition file. If the Layer Definition tool is invoked from a command prompt with no parameters, the following usage information is printed to the screen:
Usage: swvldf.exe [-x <ldf file> | -i <ldf file> ]
Export Layer Definition: swvldf.exe -x <ldf file> -l <layer name or ID> options -[rwRWmoeLF]
   Valid Options:
   l = Layer name or ID of the layer whose definition is to be exported.
   r = Include RO Sub-layer files in layer definition file.
   w = Include RW Sub-layer files in layer definition file.
   R = Include RO Sub-layer registry entries in layer definition file.
   W = Include RW Sub-layer registry in layer definition file.
   m = Include Sub-layer meta registry in layer definition file.
   o = Overwrite layer definition file if it exists.
   e = Embed all export data in single ldf file.
   L = Turn on Logging. Must be followed by log level (0-3) (e.g. -L 3).
   F = Log to file (e.g. -F c:\logfile.log). Ignored if -L is not specified.
Create or Modify Layer: swvldf -i <ldf file> [-MlnvsopkLF]
   Valid Options:
   M = Modify Existing Layer. Note: -l <layer guid> must be specified.
   l = Layer name or ID of the layer to be modified. Ignored if -M is not specified.
   n = Create using new layer ID. If not set, Layer ID from ldf definition file used.
   v = Turn off file version checking.
   s = Only process <file-source> tags within the layer definition file.
   o = Overwrite package file if it exists. Ignored if -p is not specified.
   p = Export Layer to package file (e.g. -p c:\package.vsa)
   k = Keep layer when creating a package. Ignored if -p is not specified.
   L = Turn on Logging. Must be followed by log level (0-3) (e.g. -L 3).
   F = Log to file (e.g. -F c:\logfile.log). Ignored if -L is not specified.
At first glance, considering all the parameters that can be passed to swvldf.exe, it might appear to be a complicated tool to use. Fortunately, most of the parameters simply provide a way to customize the import and export LDF file operations.
The minimal command-line syntax for creating a LDF file from an existing virtual application layer is as follows:
Swvldf.exe –x c:\myfiles\IE6v1.ldf –l “Internet Explorer 6”
The “-x” parameter specifies the command (export) and must be followed by the path to the LDF file to be created. The “-l” parameter specifies the layer name and must be followed by the target layer name (the layer ID can also be specified) for the operation.  By default, all layer information is saved to the specified LDF file. The additional flags provide the option to filter what layer information is exported to the LDF file.  For example, the “r, w, R, W, m” flags, if specified, constrain the LDF to include only the data specified by the flag. For example, consider the following command-line:
Swvldf.exe –rwx c:\myfiles\IE6v1.ldf –l “Internet Explorer 6”
Notice the addition of the “rw” parameter flags. This causes swvldf.exe to generate only the RO and RW sub-layer file information to the specified LDF file.
As a brief aside, just a word on how command-line parameters are handled.  The parameters can be coupled with “-x”, or can be placed separately on the command-line. For example, the following command-line syntax is equivalent:
Swvldf.exe –x c:\myfiles\IE6v1.ldf –l “Internet Explorer 6” -rw
Be careful to follow the instructions outlined on the help screen. Some parameters must be followed by additional information, as is the case with the “-x” and “-l” parameters.  If a parameter associated with the import operation (“-i”) is included with the export (“-x”) operation, it is simply ignored. The parameters can be specified in any order on the command-line, so long as valid parameters are specified and parameters that require data to follow them (such as -i, -x, -l, -p, -L and –F) are specified properly. If an unsupported parameter is specified, swvldf.exe displays the help screen to the console and exits. Parameters are case-sensitive. Ensure that you specify the proper case when passing parameters to swvldf.exe.
Let’s get back to taking closer look at some of the other parameters associated with the LDF export operation. The “–L” and “–F” parameters control logging. The “-L” parameter turns on logging and must be followed by an integer between 0-3, which defines the level of logging.  The log level values have the following meanings:
0 – Errors. Only errors are captured in the log.
1 – Warnings. Errors and Warnings are captured to the log.
2 – Information – Errors, warnings and informational messages are captured to the log.
3 – Trace – Verbose logging – all levels of log information are captured to log plus more granular tracing of what is taking place during each operation.
The “-F” enables logging to a file and must be followed by the path to the log file.  
The final parameter we’ll discuss as part of the LDF file creation operation is “-e”. This parameter controls how registry and file ACL information is stored. If  “-e” is specified, then all registry and file/folder ACL information is embedded within the LDF file. If “-e” is omitted, then two directories are created in the directory where the LDF file is created: “regs” and “dacls”.  The “regs” directory might contain two files, one for the RW sub-layer, and another for the RO sub-layer. These files contain all of the registry information for the specified sub-layers in “regedit.exe” textual format. Allowing these files to be referenced outside the LDF file enables other tools to be used to generate, edit, or modify these files if required without parsing the LDF file itself. The “dacls” directory contains all of the file and directory ACL information stored in a textual format.  If the registry and ACL information is not embedded in the LDF file, it is important to remember that these directories need to be distributed with the LDF file.  The easy route is to always specify the “-e” parameter to ensure that the registry and file/folder ACL information is embedded in the LDF file.
Invoking swvldf.exe with the “-x” parameter reads all of the specified layer information and outputs an LDF file. A natural question at this point is “What is contained within the LDF file”? To answer that question, let’s take a closer look at the contents of the generated LDF file.

What’s an LDF file?

The simple answer to the question is that it’s an XML file that contains four categories of information:

  • File information
  • Folder information
  • Registry information
  • Layer Settings information
The top-level hierarchical organization within the LDF file is as follows:
<pkg-config version="1" name="Package Name">
                                    <dest-file sublayer=”ro|rw”/>
                                    <file-source />
                                    <file-acl-entry  sublayer=”ro|rw”/>
                                    <file-import sublayer=”ro|rw”/>
                                    <dest-folder sublayer=”ro|rw”/>
                                    <reg-entry sublayer=”ro|rw”/>
                                    <reg-import sublayer=”ro|rw” />
                        <settings sublayer=”ro|rw”>
                                    <!—Contains layer settings à
A detailed description of the LDF file format is found in the appendix of this article so we’ll not cover this in detail here, but each top-level category contains child categories that are containers for all of the virtual application files, folders, registry entries and layer settings.
The good news is that unless you are interested in modifying or handcrafting LDF files to be consumed by swvldf.exe, it isn’t necessary to know anything about the contents of this file, except for perhaps the <file-sources> tags (more on this later).
A final note on generating LDF files with swvldf.exe concerns the possible use of a “merge” directory that can be created in the same directory as the LDF file for the purpose of merging LDF content when generating an LDF file.  The purpose of this “merge” directory is to allow content for the LDF file to be merged from external files. Why might this be useful? There are cases where you might want to define default content that can’t be defined in the virtual application layer that you’d like merged into the LDF each time it is generated. The supported tags for merge files are for defining shortcuts, file sources and for creating files at layer creation time. Following is an example of a merge file that shows the use of all the supported tags (see appendix for detailed description of the tags and attributes):
<pkg-config  version="1" name="Internet Explorer 8" tool-version="">
                                  <created-file name="iexplore.exe.local" version="" sublayer="ro" encoding="Ansi" destpath="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8"/>
                                 <shortcut target-file="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8\iexplore.exe" target-args="" link-file="[_B_]COMMONDESKTOP[_E_]\Internet Explorer 8" desc="Internet Explorer 8" show-mode="" curr-dir="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8\" icon-file="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8\iexplore.exe" icon-index="0" />
                        <file-sources enabled="true">
                                   <file-source name="IE8-WindowsXP-x86-ENU" srcpath="" type="path" file-repo="%cfgpath%\filerepo\IE8-WindowsXP-x86-ENU" search-paths=".;support" dwnload-dir="%cfgpath%\downloads" />
                                   <file-source name="WindowsXP-KB936929-SP3-x86-ENU" srcpath="" type="path" file-repo="%cfgpath%\filerepo\WindowsXP-KB936929-SP3-x86-ENU" search-paths="" dwnload-dir="" />
Virtual application layers that are created using the “installation capture” mechanism create or copy files and create shortcuts as part of the installation. Virtual application layers that are generated using swvldf.exe and a LDF must have a way to define the source for files to be copied to the layer, to create text files and the ability to create file shortcuts (*.lnk files)  at the time the layer is created. These tags provide a mechanism for doing this and the “merge” directory proves a means for ensure that this content is added to the LDF each time it is generated. If the “merge” directory is not used, these tags must be added “by hand” to the LDF before an attempt to create a virtual application layer is made. Otherwise, the attempt to create the layer will fail because the required files cannot be found.
The “merge” files must be formatted according to the <pkg-config> XML format (described briefly above and in detail in the appendix). The names of the files do not matter, however, they must have an “.ldf” extension or they will be ignored by swvldf.exe. All files found in the “merge” directory are processed and merged in to the LDF file.

Creating a Layer with an LDF File

Creating an IE6 virtual application layer from an LDF file is accomplished by invoking swvldf.exe with the following command-line syntax:
Swvldf.exe –i c:\myfiles\IE6v1.ldf
This command causes swvldf.exe to parse each section of the LDF file and add the files, folders, registry, and layer setting information to a new layer. The “-i” parameter identifies the operation as “import”, followed by the LDF file to import.
It is also possible to modify an existing layer by using the following command-line syntax:
Swvldf.exe –i c:\myfiles\IE6v1.ldf –M –l “Internet Explorer 6”
The “-M” indicates that the LDF file should be used to modify an existing layer. The “-l” parameter identities the virtual application layer to modify.
A brief discussion of the other parameters associated with the LDF file import follows:
-n – This parameter, if specified, creates a new layer ID for the created layer. If not specified, the Layer ID found in the layer settings within the LDF file (under <settings> tag) is used.
- v – This parameter, if specified, turns off file version checking when copying files to the created layer. File checking ensures that the proper files are copied from the file repository to the layer.
-p – This parameter specifies to create a package from the layer in addition to creating the layer. The –p parameter must be followed by the path to the package file to be created (file should have .VSA extension).
-k – This parameter specifies that when creating a package (-p must be set) to keep the layer. Otherwise, it is removed after creating a package.
-o – This parameter specifies whether a package file should be overwritten if it exists. This parameter is ignored unless –p accompanies it on the command-line.
-s – This parameter specifies that only the <file-source> tags should be processed when processing the LDF file. This is useful when building a file repository and testing it before processing the other tags within the LDF file.
The “-L” and “-F” parameters have already been described in the section on exporting an LDF file. They operate in identical fashion as the import operations.
If you have been following closely you might be wondering where swvldf.exe retrieves the files required to create a virtual application layer. The answer lies within the content that resides beneath the “<file-sources>” tags within the LDF file.  These tags instruct swvldf.exe to create a file repository from which the required files can be copied to the layer.

Creating a File Repository

The LDF file would be of little value if the files defined within it can’t be referenced when building the layer. The <file-source> tags provide a very powerful mechanism for instructing swvldf.exe to download, copy, or reference existing file paths to access files during the layer creation process. The best way to tackle understanding how this is done is by looking at an example. Following are the <file-sources> tags used to create the Internet Explorer 6 virtual application layer:
<file-sources enabled="true">
        <file-source name="Cab Extraction Tool" srcpath="" type="http" file-repo="" search-paths="" dwnload-dir="%cfgpath%\downloads">
                <src-file name="extract_setup.exe" type="cust" cmd-line="%src-file-path% /Q /C /T:%dwnload-dir%" />
                <src-file name="extract.msi" copy=”false” type="cust" cmd-line="msiexec /a %src-file-path% /qn  TARGETDIR=%tools-dir%" />
       <file-source name="WindowsXP-KB936929-SP3-x86-ENU" srcpath="" type="http" file-repo="%cfgpath%\filerepo\WindowsXP-KB936929-SP3-x86-ENU" search-paths="" dwnload-dir="%cfgpath%\downloads">
               <src-file name="WindowsXP-KB936929-SP3-x86-ENU.exe" type="mssp" />
        <file-source name="KB976325" srcpath="" type="http" file-repo="%cfgpath%\filerepo\KB976325" search-paths="SP2GDR;SP3GDR" dwnload-dir="%cfgpath%\downloads">
                  <src-file name="WindowsXP-KB976325-x86-ENU.exe" type="mssetup" />
        <file-source name="Manually Generated Files" srcpath="" type="path" file-repo="%cfgpath%\filerepo\manual" search-paths="" dwnload-dir="%cfgpath%\downloads" />
These tags reside beneath the <pkg-files> tag within the LDF file. Before we look closely at the example, let’s take a look at the meaning of the <file-source> and it’s child <src-file> tags and associated attributes:

<file-source> element attribute descriptions:

name – Describes the file source purpose.
srcpath – location of a file. This can be a file path or location on the Web (http URL).
type – defines the type of file source.  The value of this attribute determines how the file is acted upon. Following are the support values:

  • http – srcpath points to an http URL.
  • path – srcpath attribute points to a path in the local file system from which to copy files. Useful if a file repository of required files already exists. Files in the “srcpath” are not copied to the path specified by “dwnload-dir”.
  • drive – srcpath attribute points a path in the local file system from where files should be copied to local file repository. This differs from the “path” attribute in that files are copied from the srcpath to the path specified by “dwnload-dir”.
file-repo – defines a file repository location. Swvldf.exe builds a list of all “file-repo” attributes that together comprise the “file repository” when processing <dest-file> tags (which are used to identify the files to be copied to the layer). It might be blank in the case where the file is used as a tool, not a source of files for a layer.
search-paths – defines paths beneath the “file-repo” to reference for files. Each path should be separated by a semi-colon “;” delimiter. Each path must reside beneath the “file-repo” path.  
skip-existing – specifies whether child <src-file> tags should be copied if they already exist in the “dwnload-dir”. If not specified, the default is “true”.  Supported values: “true”, “false”.
dwnload-dir – defines the location to where files are to be downloaded and/or copied (depending on the value of the “type” attribute).

<src-file> element attribute descriptions:

 name – The name of the file. If its parent <file-source> tag has a “type” value of “http”, the <src-file> tag defines the file to be downloaded.  Files are always initially copied to the path specified by “dwnload-dir”.
copy -  specifies whether the source file (<src-file name=”filename”>) should be copied from the srcpath (defined on its parent <source-file> element). If not specified, this defaults to “true”. Supported values: “true”, “false”.
type – defines how the file should be operated on.  Based on this type, the file might need to be extracted to the file repository. The supported values are:

  • cust – custom operation. The “cmd-line” attribute must also be defined as it defines the operation to be taken on the file.
  • cab – the file is a Microsoft “Cab” file.
  • zip – the file is a zip archive.
  • self – file is a self-extracting archive.
  • mssetup – file is Microsoft setup file.
  • mssp – file is Microsoft service pack file.
As you look at the Internet Explorer 6 example you’ll notice several attribute values that are surrounded by % characters. These are macros that are expanded by swvldf.exe to their associated values. Following are the supported macros and their meanings:
%cfgpath% - expands to the path where the LDF file is located.
%ENV_VAR% - expands to the system %ENV_VAR% (only supported when used in the “file-repo” attribute value). Example: %windir% expands to c:\windows.
%dwnload-dir% - expands to the value of the “dwnload-dir” attribute. (Only supported when used in <src-file> element attributes).
%src-file-path% - expands to the path of the <src-file>. (Supported only when used in <src-file> element attributes).
%src-file% - expands to the name of the <src-file>. (supported only when used in <src-file> element attributes).
%tools-dir% - expands to the path of the “tools” dir. By default this “tools” directory resides in the directory where the LDF file resides.
Now that we have a handle on these tags and their associated attributes. let’s look at the specific example of the Internet Explorer 6 <file-sources> tags.
Each <file-source> tag identifies a source for files that comprise part of the file repository that is used as a source for files to be copied to a new or modified virtual application layer. These tags can also be used to download tools that won’t be included in the layer, but are required to extract files that are part of a file repository.
Let’s look at each tag:
<file-source name = “Cab Extraction Tool” … >
The  “Cab Extraction Tool” is not intended to be part of the file repository. Its purpose is to download the “Cab Extraction Tool” from a public Microsoft site, extract it, and then place the extract.exe binary into a “Tools” directory that resides in the same directory as the LDF file.  The <src-file> elements coupled with its “type=cust” and “cmd-line=…” attributes define how to extract the files to the proper locations.
<file-source name="WindowsXP-KB936929-SP3-x86-ENU" …>
The “WindowsXP-KB936929-SP3-x86-ENU” file source defines the location from which to download the Windows XP SP3. The type of the <src-file> tag is “mssp” which means it is a Microsoft Service Pack file and must be handled as such. 
<file-source name="KB976325" …>
The “KB976325” file source defines the location from which to download the KB976325 hotfix. The type of the <src-file> is “mssetup” which means the file is a Microsoft setup file and must be handled as such (the syntax for expanding an Microsoft Setup file is specific to that type. Set the log level to 3 and then look at the log file to see the command-line syntax used to expand these file types).
<file-source name=”Manually Generated Files” …>
The “Manually Generated Files” file source defines a path where files that are manually generated are made available in a local path (“type” attribute = “path”).  For example, a shortcut file (.LNK) for Internet Explorer is placed in this path so it can be found and made available during creation of the layer.
If the <source-file> tags are defined properly, then once they are processed, there should exist a local file repository that contains all the files required to create a layer with the corresponding LDF file. Once the <file-source> tags have been processed, it is much more efficient to change the <file-source> tags to point to local paths where the files exist to make creating a layer much faster on subsequent invocations of swvldf.exe.
For example, once the LDF file for creating the Internet Explorer 6 has been run for the first time, the content within <file-sources> tags could be changed to the following:
<file-source name="WindowsXP-KB936929-SP3-x86-ENU" srcpath="" type="path" file-repo="%cfgpath%\filerepo\WindowsXP-KB936929-SP3-x86-ENU />
<file-source name="KB976325" srcpath="" type="path" file-repo="%cfgpath%\filerepo\KB976325" search-paths="SP2GDR;SP3GDR" />
<file-source name="Manually Generated Files" srcpath="" type="path" file-repo="%cfgpath%\filerepo\manual" search-paths="" />
These tags simply point at existing paths where the files already exist. The point is that the file repository needs to be created only once. After it exists, the LDF can simply point to the existing files.
The capability to point to existing files to create a virtual application layer makes it possible to create a virtual application layer from an application that is already installed on the system. This capability is used to virtualize Internet Explorer 8 on Windows 7. Internet Explorer 8 is installed by default on Windows 7, so there is no installation whichinstallation, which can be used to capture IE8. Following are the <file-sources> tags from an LDF file that is used to create a virtualized version of IE8 on Windows 7:
<file-source name="IE8 Windows System32 Files" srcpath="" type="path" file-repo="%windir%\system32" search-paths=".;en-US" dwnload-dir="" />
<file-source name="IE8 Program Files" srcpath="" type="path" file-repo="%programfiles%\Internet Explorer" search-paths=".;en-US;" dwnload-dir="" />
<file-source name="Windows Help Files" srcpath="" type="path" file-repo="%windir%\help" search-paths="" dwnload-dir="" />
<file-source name="Manually Generated Files" srcpath="" type="path" file-repo="%cfgpath%\filerepo\manual" search-paths="" dwnload-dir =”" />
Notice that all files are referenced from the local system. This, of course, implies that when building this package that swvldf.exe must be run on a Windows 7 system with Internet Explorer 8 installed.
The ability to create a local repository from an LDF file makes it possible to generate virtual application layers and packages simply by supplying an LDF file and the swvldf.exe utility. A very powerful capability!

The Value of swvldf.exe and LDF Files

We’ve already discussed the fact that using swvldf.exe and LDF files provides a mechanism to create virtual application layers where capturing is not possible. However, there are other uses for LDF files that are interesting to consider.
The capability to create textual representation of virtual application layers makes it possible to use a version control system to manage different versions of packages. While it was possible to have a repository of virtual application packages (VSAs) before the existence of LDF files, because these are binary archives, it is very difficult to know what differences exist between versions. LDF files can be stored, managed and version-controlled just like HTML/JavaScript or C++, Java or C# assets are managed for Web sites and applications.
The use of LDF files can also provide a solution for cases where capturing an application on different systems yields inconsistent packages. This can happen due to differences in software that is installed on systems when capturing. Using swvldf.exe and LDF files ensures that identical layers get created each time. To ensure that customers can generate consistent layers and packages, the workflow can change to the following: Capture a virtual application layer. Ensure it works, and then use swvldf.exe to generate an LDF file. Handcraft the <file-sources> tags to create a local file repository from the application installation file.  Make the LDF file available to creating a consistent package. The virtual application layer can then be created by anyone, on any system.
Generating an LDF file of a virtual application layer in an original state and then again after an upgrade, can provide a quick mechanism to discover differences between versions.  You might update an application using a service pack, and then generate an updated LDF for the updated state. You can then use any text “diff-ing” tool to look at the changes between the original and updated versions of the LDF files. This can be a very handy troubleshooting technique when an application upgrade causes problems.
You could also create a library of LDF files that can be used by an on-line community. Application packaging can be part art and part science. Imagine the benefit of having a library of “tested”, “tried” and “true” LDF files that contain all of the necessary tweaks and modifications to generate rock-solid virtual application layers.


The SWV Layer Definition Tool provides a mechanism to create virtual application layers from a textual definition of a layer coupled with a file repository in cases where capturing a layer is not possible or proves not to be feasible. It includes the capability to create, on the fly, a local file repository by downloading files from public Web sites or by retrieving them from a local drive, network share, or local DVD drive. The key benefit is the ability to generate consistent virtual application layers on any system.




Download The SWV Layer Definition tool from the following link:
Download IE6 for Windows XP LDF from the following link:
Download IE7 for Windows XP LDF from the following link:
Download IE8 for Windows XP LDF from the following link:
Download IE8 for Windows 7 LDF from the following link:

Error Codes returned by SWVLDF.EXE

6000   Invalid LDF File – XML file format is not valid.                             
6001   Invalid XML attribute was specified on an element.                                
6002   Package name attribute missing.                           
6003   Package element missing.               
6004   Failure during attempt to invoke external process.                     
6005   Package type attribute not defined.
6006   Required file attribute not defined.           
6007   Invalid virtual application sublayer defined.
6008   Import file not found.
6009   No meta-data substitute value found.                               
6010   Invalid source file.
6011   Invalid file version.                                      
6012   Source file not found in any file repository.                                  
6013   Error during copy file.
6014   Attempt to save temporary import registry file failed.                
6015   Attempt to save substituted import registry file failed.               
6016   Package action not defined.
6017   Invalid layer ID specified.   
6018   Download type not defined.                       
6019   Source path attribute not defined.                        
6020   File repository path attribute not defined.                                   
6021   Download directory attribute not defined.                                   
6022   Source file name not defined.         
6023   Source type not defined.     
6025   Http file download failed.                                                    
6026   Copy download failed.
6027   Invalid download type.
6028   Run expand failed.
6029   Run mssetup failed.
6030   Run custom failed.   
6031   Unzip failed.
6032   Open zip failed.
6033   Invalid download type specified.
6034   Move file failed.
6035   Specified download directory does not exists.
6036   Unknown source type.
6037   Invalid copy file specified.
6038   File sources not defined.                                         
6039   Invalid attribute value.        
6040   Missing registry file attribute.
6041   Missing destination layer attribute.
6042   Missing destination path attribute.
6043   Missing acl file attribute.
6044   Acl file not found.
6045   Config file exists.
6046   Invalid directory.      
6047   Failure during load file.
6048   Failure during save file.
6049   Invalid registry value: hex7
6050   Invalid registry type for value.
6051   File name not defined.
6052   Missing content value.
6053   Failure during processing multi-value reg string.
6054   Failure during processing string reg value.
6055   Failure during processing dword reg value.         
6056   Failure during processing binary value.
6057   Failure during process excludes.
6058   Failure during run of mssp type.
6059   Layer ID not found in LDF file.
6060   Error layer already exists.
6061   Failure during retrieve event string.                                 
6062   Required version attribute no present.
6063   Failure attempting to add version info to layer settings.
6064   Required file shortcut tag attribute missing.
6065   Failure during attempt to expand varialized path.
6066   Failure during attempt to create shortcut file.              
6067   Failure attempting to expand macro.
6068   Failure during attempt to create file.
6069   Failure during attempt to create directory.

Layer Definition File XML Tags and Attributes Description


Tag Name
Tag Attributes Description
<pkg-config>   Child of: None. Root tag.
  name Name of the virtual application layer.
  version Version of the LDF file.
  tool-version Version of tool used to create the LDF. The tool-version and LDF version information is added to the layer settings metadata as LDFToolVersion and LDFVersion respectively when creating a layer.
<pkg-files>   Child of: <pkg-config>. Contains definitions for source files, destination files, file shortcuts, created files and file/folder ACLs.
<file-destinations>   Child of:<pkg-files>.  Contains definition tags for all files destined for the layer.
<dest-file>   Child of: <file-destinations>. Defines  a file to be copied to the layer.
  name Name of the file.
  version Version of the file. Used to ensure proper version of file is copied to layer. May be set to “” for undefined. The –v parameter can be passed to swvldf.exe to have the tool ignore file versions when creating a layer.
  sublayer Specifies the sub-layer in which the <dest-file> will be copied.
  scrpath Location from which to copy file.
  srcpath-type Defines how to operate on srcpath if value exists. Supported values are:
- abs = srcpath points to an absolute path.
- srch = use search paths to find the source file in a file repository.
- xlate = Expand the variablized path to use as the source for the local file. (Used for Physical to Virtual)
<file-acl-entries>   Child of: <pkg-files>. Defines the file and folder ACLs within the layer.
<file-acl-entry>   Child of: <file-acl-entries>. Contains the text-based ACL definitions for layer files and folders. Used if –e param is passed to swvldf.exe with –x param.
  sublayer Defines the sub-layer to which the ACLs apply.
<file-acl-imports>   Child of: <pkg-files>. Contains definitions that point to external ACL import files.
<file-acl-import>   Child of: <file-acl-imports>.  Defines the location of an externa ACL file that contains all sub-layer file and folder ACL definitions.
  sublayer Defines the sub-layer to which the ACLs apply
  aclfile Path relative to the LDF file that contains an external export of the file and folder ACL definitions. If swvsdf.exe –x is invoked without the –e flag, then the ACL file export is found in %cfgpath%\dacls.
<file-sources>   Child of: <pkg-files>. Contains <file-source> elements.
  enabled Defines whether contained <file-source> tags should be processed.
<file-source>   Child of: <file-sources>. Define a file repository from which files will be copied when creating a virtual application layer.
The order of <file-source> elements matters! When processing <dest-file> elements where <dest-file srcpath-type="srch"> then these paths will be traversed in the order specified in <file-sources>.
The <file-source> element MAY contain <src-file> elements which defined files to be copied from "src-path" and extracted to "file-repo".
For example, src-path may point to an HTTP url from which to retrieve .CAB files. These files will be downloaded to "dwnload-dir" and extracted to "file-repo".
  name Describes the file repository.
  src-path Specifies the location from which files will be retrieved.
  type specifies the type of the src-path. [drive | share | http | ftp]
-  drive = local drive
-  share = use unc path
-   http = url to files base on http server
-   ftp = path on ftp server
  conn-str Specifies relevant connection info given the "type" attribute specified. Not used if type is drive or share.

If "type" attribute is set to http and http proxy is required then the conn-str attribute should contain:
"pxydomain;pxyport;pxylogin;pxypwd" where:

- pxydomain is the http proxy server domain. 
- pxyport is the proxy port.
- pxylogin is the proxy login id.
- pxypwd is the proxy password.

If conn-str value contains ONLY the value “IE”, then the proxy settings defined for IE will be used.

If "type" attribute is ftp it is formatted as follows:"usr;pwd".

  file-repo Specifies the location from which files will be referenced when building a package. Extracted files will be placed in this location!
  dwnload-dir Specifies the location to which files will be downloaded in the case of type=http | ftp. If not defined %cfgpath%\downloads is used.
  search-paths Specifies locations within the extracted archive path in which to look for files when processing files to copy to package.
 Each path MUST be relative to the extracted archive and should be semi-colon-delimited. Swvldf.exe will concatenate these paths with the file-repo path to define the full path to files within the archive. Order MATTERS. FIRST file found within the paths will be used.
If "." is used as a value, the "file-repo" attribute will also be added as a search path.
  tool-path Path to tools used to process <file-source> files. If not specified, %cfgpath%\tools is assumed.
Default tools: cab=extract.exe, zip=[internal], http=[internal], ftp=[internal]
Useful for using existing tools on the system or when downloading tools to use as part of processing files.
  skip-existing If not present or set to "true", skip files that already exist in the "dwnload-dir" directory. If false, copy down all files to "dwnload-dir", every time.
<src-file>   Child of: <file-source>.  Element that defines src files to be placed in "file-repo" for use by swvldf.exe when generating a layer.
  name Name of the file.
  type Type of the <src-file>. Supported values are [ file | cab | zip | self | mssetup | mssp | cust]
- file = standard file
- cab = MS archived cab file
- zip = zip archive
- self = self-extracting zip
- mssetup – Microsoft Setup file
- mssp = Microsoft Service pack
- cust = Defines a custom command to be executed to operate on the file in some way. (If “cust” is specified, the “cmd-line” attribute must be defined).
Defines the cmd-line to be used to handle this particular file. Examples include custom archiver (e.g. c:\temp\MyUnarchiver %fn% /extract). The following macros can be used as part of the cmd-line value:
- %src-file-path% - expands to the full path of <src-file>
- %src-file% - expands to just the name of the <src-file>
- %file-repo% - expands to the full path of the file repository path specified on parent <file-source> tag.
- %dwnload-dir% - expands to the download directory specified on the parent <file-source> tag.
- %tools-dir% - expands to the tools directory specified on the parent <file-source> tag.
- %cfgpath% - expands to the directory where the LDF resides (or will reside in the case of –x).
  extract-dir Specifies the location where extracted files are placed. If not specified, extracted files go to "file-repo" (of parent <file-source> element) by default.
If set to value %dwnload-dir% then the "dwnload-dir" attribute of the parent <file-source> element is used. Any valid path on the local system can be used.
  copy If not present or set to "true", the file will be copied from "srcpath". If set to false, it will not.
Useful if file was copied to "dwnload-dir" through some other means. The file will still be processed according to the "type" (i.e. CAB files will be extracted, Zip files unzipped, etc).
<shortcuts>   Child of: <pkg-files>. Contains shortcut definitions.
<shortcut>   Child of: <shortcuts>. Defines a file shortcut to be created in the layer.
  name Name of the file including extension (i.e. “Internet Explorer 6.lnk”). This needs to match the name of the file defined as a <dest-file> tag.
  target-file File name of the link's target. Must be variablized path (i.e. [_B_]PROGRAMFILES[_E_]).
  target-args Command line arguments passed to link's target.
  link-file File name of the actual link file being created. Must be variablized path.
  desc Description of the linked item.
  show-mode ShowWindow() constant for the link's target.
  curr-dir Working directory of the active link. Must be variablized path.
  icon-file File name of the icon file used for the link. File must exist in the layer and path must be variablized.
  icon-index Index of the icon in the icon file. Index of icon within “icon-file”.
<created-files>   Child of: <pkg-files>. Contains <created-file> tags.
<created-file>   Child of: <created-files>. Defines a file to be created. Content of file must be placed inside the <created-file> tags. No content will create a zero-byte file.
Content should be wrapped in CDATA section.
  dest-path Path in the layer to create the file. Must use variablized path.
  encoding Defines the encoding to use when saving the file. Supported Values [Ansi | Unicode | Utf-8].
  sublayer Sub-layer in which to create the file.
  name The name of the file to be created. Must match the name of the file defined as a <dest-file> tag.
<pkg-folders>   Child of: <pkg-config>. Element that contains all folder definitions for the specified Layer.
<folders>   Child of: <pkg-folders>. Element that contains all folder definitions for the specified Layer.
<dest-folder>   Child of: <folders>.
Direct child of the <folders> element whose content defines the full path to a single folder path within the specified layer.
  sublayer Specifies the sub-layer to which this folder belongs.
<pkg-registry>   Child of: <pkg-config>. Direct child of the <pkg-config> element that contains all registry definitions for the specified Layer.
<reg-entries>   Child of: <pkg-registry>. Direct child of the <pkg-registry> element that contains all registry definitions for the specified Layer.
<reg-entry>   Child of: <reg-entries>. Direct child of the <reg-entries> element that contains all registry definitions for the specified Layer.
The content contained within <reg-entry> tags is "regedit.exe" textual format and wrapped within a "CDATA" section.
 Note: if swvldf.exe -x <file> -e is specified the registry content is embedded within the <reg-entry> tag.
  sublayer Defines the sub-layer to which the registry entries will be applied when creating the layer.
<reg-imports>   Child of: <pkg-registry>.  Contains <reg-import> tags.
<reg-import>   Child of: <reg-imports>. Direct child of the <reg-imports> element that contains all registry definitions for the specified Layer.
 Note: if swvldf.exe -e <file> is specified without the -d flag, then registry content for the specified is exported to the   file specified by the regfile attribute.
  sublayer Specifies the sublayer to which the registry entries belong.
  regfile specifies an external reg file that contains registry entry definitions for the specified sublayer. The reg file    must be in "regedit.exe" textual format.
<pkg-settings>   Child of: <pkg-config>. Direct child of the <pkg-config> element that contains all Layer Metadata definitions.
<settings>   Child of: <pkg-settings>. Direct child of the <pkg-settigns> element that contains all Layer Metadata definitions.
All elements contained within the <settings> each specify a layer setting. The element name matches the Layer setting defined within the layer metadata.
If the setting is multi-valued then a parent tag with the setting name with  "-entries" appended is created and all values are contained as individual values.

0 Favorited
0 Files

Tags and Keywords


12-07-2011 12:47 AM

Can anybody explian

how to edit registries. after creating LDF.

I tried to edit registry and then again create apackage it gives me an error "6041 (Missing destination layer attribute.)"

can any body help on this. also gives same error when i created a LDF file and then without change i try to create a layer. Error does not occurs if i use -s switch.

12-06-2010 01:04 PM

Hi is it possible to add in IE Favourites and local proxy settings into either the ldf file or into the layer and save these for all users that use the layer on the pc?

it's okay after a bit of testing i managed it 



09-30-2010 03:56 PM

Thanks for all the documentation - but I am erroring with a 6025 error - Not sure where to add the conn-str value so it pick up my ie settings. is it inside the ie8-winxp.ldf?


Thanks in advance

05-12-2010 02:18 PM

No, this is not the same as the "commonit" solution. Based on the first paragraph from the website  the significant difference is that the commonit virtual browser solution executes on a server and appearantly uses some type of "remote desktop protocol" to relay only the desktop to workspace of the user.
The SWV solution executes natively on the Windows Operating System so it does not require additional server infrastructure, however, it does provide the ability to isolate changes made to the system while browsing from damaging the user's system. A simply reset is required to revert the virtual browser state back to "pristine".
Hope this helps.

05-03-2010 05:01 AM

Is this tool same as If not what are the functional/architectural differences, could you pls highlight those?

04-19-2010 06:45 PM

No limitations come to mind. The most important thing to learn is the format of the LDF files. It is quite possible for a virtualized application layer to be created improperly or to fail if the LDF file is malformed or has missing information. A complete review of the documentation and tutorial is strongly recommended before individuals begin using the tool.

If you are creating your own LDF I recommend the following points:
  • For best results, I always create and test a virtual application layer very thoroughly before exporting the definition.
  • When trying to create a new virtual application layer, I create the <file-sources> tags and test the LDF with JUST the <file-sources> tags (-i with -s specified) to make sure the file repository is created properly.

Hope this helps.

04-07-2010 10:58 AM

Are there any limitations to using this tool? Is there any "got yahs" that we should be aware of?

Related Entries and Links

No Related Resource entered.