CLI Sequencer - Creating New Package

My name is Victor Dubinsky and I am a Test Engineer at Microsoft working on Sequencer. Once of my areas of expertise is Command Line Interface of Sequencer. I would like to discuss a topic that should be interesting to administrators who create virtual packages and would love to automate their packaging process. Not everyone realizes that Sequencer has a Command-Line Interface (CLI) that allows unattended sequencing process. This blog will provide more details on what Sequencer CLI is capable of and how to use it. Sequencer CLI, as GUI Sequencer, is able to create a new package, upgrade the contents of the application in the existing package via Package Upgrade, and perform minor edits on the properties of the package.

Some of you who are not familiar with Sequencer CLI might ask how one can access command-line interface. You can learn more about CLI Sequencer following this link: https://technet.microsoft.com/en-us/library/cc843632.aspx , or if you have Sequencer installed on your machine, CLI is available as well. First, open a new command-window with Administrative rights. Change directory to the location where Sequencer is installed. Now, type:

“sftsequencer /?” or “sftsequencer /Help”

This command will display help information on what commands are available and any arguments that these commands take. The command should return the following:

clip_image002

There are some basic conventions:

1. All arguments begin with forward slash (“/”)

2. All arguments need to be separated by space. If the value of an argument has spaces or any other special characters, then please include entire value in the quotation marks.

3. If an argument takes a value, then there is a colon (“:”) after the name of the argument. The value should be typed right after colon. There are no spaces on either sides of colon.

4. If an argument does not have square brackets around it, then this is a mandatory argument for this particular command. If an argument has square brackets around it ([/MSI]), then this is an optional argument.

5. In the Help information, anything that is shown to the right side of the colon is for description purposes only.

6. If you see the same argument in more than one command, then this argument has exactly the same meaning and the same behavior in all the commands it appears in.

The above rules will most likely eliminate most of the general questions. Now, I would like to go into details on each of the arguments. I will explain unique arguments for each of the three commands and then will cover the ones that are generic to two or more commands. Throughout the process I will be cross-referencing back to the GUI fields that correspond to the CLI arguments.

I begin with creating a package. Here is the signature for the command that creates a new package:

clip_image004

The most important argument while creating a new package is “/InstallPackage” . This is also the argument that generated most of the questions. This argument takes the absolute path to the script that installs the application. However, I would like to refer to the value of this argument as the script that performs all the steps necessary to generate a successful package. The script/executable/installer file that you should pass to this argument consists of the automated steps that you perform during monitoring phase in GUI Sequencer. This is the place where your automation creativity will serve you the most. If you have several files that you need to run during your installation process, then simply place them in a batch file and pass the batch file to the argument. Anything that you can script in any way you like in this file will be executed during monitoring and will be included in the package. If you will end up having one major script that calls subscripts, then I suggest copying all the subscripts prior to the beginning of the sequencing process. This way, those files will not end up in the package. Try to launch newly installed applications as some of them install components on the first launch. This is probably the hardest step as some of the applications will require launch phase to be automated via UI automation tools. However, others might be automated via application object scripting. Again, the main point is that anything you perform during Monitoring stage with GUI sequencer should be placed in the automated scripts, but not more than that.

“/InstallPath” argument is the absolute path to the package root. It is the absolute path to the folder that you select right after you click “Begin Monitoring” in GUI Sequencer. For example, if I want to install to Q-Drive with the package root of “MyApp.001”, then the value I would provide to this argument is “Q:\MyApp.001”. Please note that because I am using backslash, it is safer to include the value inside the quotation marks.

“/OutputFile” argument takes the absolute path of the .SPRJ file. This .SPRJ file is where you want the new package to be saved. This is the same path that you enter on the first SAVE of package in GUI Sequencer. All the files (.SFT, .OSD, and others) will be saved in the same folder as the .SPRJ file.

“/Default” argument is an optional argument that allows you to provide customized .SPRJ file that will be used as a template during the package creation. Interesting information that can be specified in this file are exclusion items (located in the main Sequencer GUI under Tools à Options à Exclusion Items), parse items (located in the main Sequencer GUI under Tools à Options àParse Items), and other package settings, including default OSD XML that will be applied to every OSD file in the package. If you would like to experiment on what other information you might be interested tospecifie with “/Default” parameter, simply open any existing .SPRJ file from any of the existing packages. From my personal experience, I use “/Default” argument for the apps that require some of the exclusion items to be removed. This way, when I create a package and remove some exclusion items, any files placed in the directories that are usually excluded by default, will end up in the package, and no manual Sequencer adjustments are needed. If in your environment you remove some of the exclusion items for every single virtual package, then it might be a good idea to generate a default.SPRJ file that would have these exclusion items removed and pass this file to every new package that you create using CLI Sequencer. Some refer to the .SPRJ file that is passed to /Default argument as a .SPRJ Template. Indeed, once defined it is used to generate various packages using one .SPRJ file as the template.

“/BlockSize” is an optional argument that lets you specify the size in Kilobytes (KB) of each block of data that the package will be divided into. Available values should include numbers only. This is an optional argument. If omitted, then 32 KB will be used as the default value for version 4.5.

“/FullLoad” is an optional argument that specifies how much of the package needs to be loaded into cache before the application starts. CLI Sequencer has only two options – all or nothing. If the argument is specified, then 100% of the package will be placed to Primary Feature Block; or in GUI words, Launch Size will be equal to the total size of the package. If the argument is omitted, then Primary Feature Block is 0% of the package. Please note, that there are no customization options for Primary Feature Block in CLI Sequencer. Unlike GUI Sequencer, there is no way to specify Launch Size to be 40%, 55%, or any other number other than 0% or 100%.

“/PackageName” is an optional argument that sets the package name. If the name has spaces or other special characters, then it is a good idea to place it in the quotation marks. PackageName argument has the same meaning in CLI and GUI Sequencer. If an optional “/MSI” argument is provided, then PackageName will be the base name of the .MSI file (i.e. If PackageName value is “MyPackage”, then .MSI file created will be named “MyPackage.MSI”).

“/MSI” is an optional argument that will generate .MSI file with the package. As I mentioned in the previous paragraph, the value of the “PackageName” argument will be the base for .MSI file. This argument has the same functionality as the “Generate Microsoft Windows Installer (.MSI) Package” check box in GUI Sequencer. If the argument is omitted, then no .MSI file will be generated.

“/Compress” is an optional argument that signals the Sequencer to compress the package. If argument is provided, then the .SFT file will be compressed. Compression rates depend on the content of the package and vary. If the argument is omitted, then no compression will be applied. If the resultant uncompressed .SFT file is expected to be more than 4 GB, then it is highly recommended to use this argument. This argument has the same functionality as “Compress Package” in GUI Sequencer.

Here is an example of a CLI command that installs Adobe Reader 8 into “Q:\AdobeR8.VIS”. I create a package with package name of “Adobe Reader 8” and save it to “C:\Installer\AdobeReader8_Vista” folder. I also generate “Adobe Reader 8.MSI” file. I am installing batch file that has installation command for Adobe Reader 8.

clip_image006

I would like to stop at this point, as there is already a lot of information to process. If there are any questions about the information provided in this blog, please post your questions. Also, I would like to hear from the readers if there are any specific Sequencer CLI scenarios they would like to read about; or if they are any issues or ambiguity that prevents them from using CLI I would like to hear about it.

In my next blogs, I will explain the use of “/Open” and “/Upgrade” commands.

If you would like to experiment more on your own, please feel free to use the following links:

About Using the Sequencer Command Line

https://technet.microsoft.com/en-us/library/cc843632.aspx

How to Manage Virtual Applications Using the Command Line

https://technet.microsoft.com/en-us/library/cc843836.aspx

Application Virtualization Sequencer Command Line

https://technet.microsoft.com/en-us/library/cc817094.aspx

 

Regards,

Victor Dubinsky | Software Development Engineer in Test